Hi Vivian, > ALS is very impressive work, but things broken? Have you forgotten the > flag shader (now fixed), wake effect and rainbow effect? I don't have a > particular problem with these and hope that they will be fixed > eventually, although I note that do you seem to have raced on to other things > while > leaving the wake effect unfixed for some time. I rather fear that that's > just going to get lost in the noise and general excitement over the > latest bit of eye-candy.
That is what I tried to explain in length. My definition of broken is 'used to work, there was a change, now doesn't work'. What is yours? The wake effect used to work in default, and now still does. The wake effect never worked in ALS and now still doesn't. There's nothing broken here, you are talking about non-existing features and a feature request to implement them. Which is very different from breaking existing things. To give you the reverse example - procedural texturing works in ALS but not in Rembrandt - so does this imply it's broken in Rembrandt? Cloud shadows don't work in either Rembrandt or ALS - does that imply we've broken them? Nope - they never existed, and you can make a feature request to implement them. In the event, your feature request for the wake effect is noted, but not my top priority - I prefer to race on to the next bit of eye candy (as you put it) because the wake effect is a very localized effect, whereas I want to address some world-wide stuff which affects a few billion pixels more first. You're welcome to implement it yourself, and I'll be happy to assist you if that is needed. To call a non-existing feature with a feature request attached 'broken' generates a completely wrong impression and a sense of urgency which really isn't there. > I think a more general concern would be that we seem to be developing 3 > or 4 > different Flightgears, in which different things work or not as the case > might be: > > Rembrandt > > Basic weather/Advanced Weather > > Atmospheric Light Scattering (ALS) This may be a question of philosophy, but I don't think OpenSource fares badly with this approach in general. As a Linux user I get a choice between Gnome, KDE and a host of other desktop environments - and I rather like that, I can pick what suits me best. As an aircraft developer, I can pick JSBSim or YaSim, whatever suits me best. So why should we not offer different rendering approaches dependent on what the user wants to burn the framerate for? I don't see this at all as a problem, I rather see it as a huge opportunity. We can ship one rendering approach for the low end graphics cards and are then not restricted in what we offer for the high end. How exactly is that a bad thing? > As a developer I have only just finished making my models Rembrandt > compatible, and I don't know if I will ever be able to actually make use > Rembrandt facilities in all of them. You'll have noticed that the ALS ubershader (short of inserting the tangent, normal and binormal attribute for normal maps which I understand really _must_ be airplane-side) works out of the box without any action required in ALS. So there is no need to make your models ALS compatible, this is not a real problem, but a hypothetical one. The worst case by the way is not that the aircraft can't be flown as in Rembrandt, because you can't see out of the cockpit, the worst case is that your normal map doesn't work. > As I understand it, ALS will include modelling facilities which will not > work in the other flavours of FG. How is this meant to be used? Optionally. *sigh* When you and Emilian wrote the default ubershader, it provided new features. These were offered to the airplane developers as options - it was their choice to make use of them or not. Now ALS offers an ubershader which might get additional features. There are offered to airplane modellers as options. Just why is it okay if you do it, but problematic if I do it? Yes, they may not work in Rembrandt - and Rembrandt has AO, and bloom, and real internal light sources which do not work in other frameworks. So not every framework has the same visuals. Why is this a problem? > In an ideal world everything would work and be > compatible with everything else. I don't see how any progress could be made that way. I don't see how Rembrandt could have been made requiring that it must be completely compatible with existing technology and aircraft definitions. We used to characterize the atmosphere by a fog density and a fog color. It's beyond me how one could make ALS by requiring the same thing. JSBSIm has updates, they break some aircraft, developers fix it - somehow I miss all the complaints about this (and JSBSim updates actually have the potential to break aircraft in the sense of rendering them non-functional, not in the sense of bumpmapping not working). Just imagine computers were required to be able to run DOS nowadays... Just imagine modern Windows software were required to be able to run on DOS... > What are aircraft developers and/or users meant to make of this ? As I said above, that's a hypothetical issue. In reality, the aircraft and models rendered with the ubershader just work with ALS because the shader uses exactly the same configuration, so there's that. Aircraft not using the ubershader do not get nice effects, but then again, Emilian when he still was active in the forum was busy telling people that older effects are deprecated and they should be using the ubershader - so when exactly did this recommendation become bad? > As to Emilian's concerns, I don't really understand the technical > details, but I do know that he felt that his advice and expertise was being > ignored with the result that FG was headed in the wrong direction Well, there it goes again. The 'wrong direction' - what is that? Who gets to decide it? How can an optional feature push something into the wrong direction? What is the concrete problem we're talking about? You don't understand exactly... But somehow, there must be something to it, right? And so, a vague impression remains and we're back to rumormongering. > Perhaps you received contrary advice, or > considered that his advice wasn't of value, but we never had that debate > IIRC. The concrete advice I received from Emilian I usually followed up - either by following it and implementing it, or by doing some background reading, implementation testing and discarding it when I made up my mind that he wasn't right. The objections in the end seemed to be rather unspecified and general though - the 'wrong way' as you put it. > Oh - and btw the ALS still shows up a tear in the skydome that we have > had right from the beginning. Yes - it's not in the shader as far as I can test, which means I can't fix it. I suspect it's in the geometry, which is generated god knows where, I've posted two analyses here and in the forum, people know about it - so that's the limit of my expertise, sorry. I recognize that a fix is needed, but I'm unable to do it. > I thought perhaps it would be helpful if a native English speaker tried > to put things in perspective Yes - as I suspected, it's about (from my view) unrealistic expectations. You're somehow fine with the fact that we have JSBSim and YaSim (and possibly UIUC - does this still work?) to drive FDMs - so it's okay that FG is open here. So why are openness and choice suddenly bad when we come to rendering? Why do you expect that ALS must support the effects which default supports, but not that Rembrandt must support what ALS does? I don't see you arguing with Fred that Rembrandt broke procedural texturing - why's that? I didn't see you arguing with Fred that you had to make aircraft Rembrandt-compatible - now you're arguing with me that you might have to make aircraft ALS compatible despite the fact that you actually don't have to? I'm not getting this, it's not a consistent position. * Thorsten ------------------------------------------------------------------------------ Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel