Thorsten > > 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. >
The gentleman doth protest too much, methinks. (And at too great a length). If something exists and works in the default scheme, but is missing or does not work in a child scheme then that child scheme is broken or we might say that there is a regression. That might or might not matter in the short term, but longer term it needs fixing. In addition, if we add something in the child scheme which proves to be useful, then it should be our ambition to back-port that to the parent. If there is any call for it, I think the grain stuff could be back-ported without too much difficulty. That said - I don't see why an Atmospheric Light Scattering scheme should have embedded in it some ac modelling stuff. That serves to diverge the schemes. And it makes it look like ALS is your private sandbox. I know that isn't the case, but you can see why there are those like Henri who fear it is: "Grain effect - good idea. Oh, that means I have to chuck out something - Rainbow effect will do. I'll put that back later somehow. Oh look - that's a good new interesting idea - I'll do that instead." OK, I exaggerate - but you can see how it might be interpreted. There is no doubt in my mind that ALS breaks the bow-wave and rainbow effects. Well, I hope so - because I just pushed a fix for the latter. Emilian pointed me at http://developer.download.nvidia.com/GPU_Programming_Guide/GPU_Programming_G uide_G80.pdf para 3.5.3. The solution was obvious - combine the Fresnel and Rainbow look-up textures into 1 texture. A few trivial changes - job done. Of more interest, we could, and probably should, do something similar for almost any complex math function. Blender has suitable tools to generate such textures - but I won't pretend that I understand that in any depth. There are some other tips and suggestions for efficient shader programming: well worth some study I would say. I haven't looked at the bow-wave - but I suspect it's more than a few minutes' work. Don't compare the FDMs: JSBSim, Yasim, and UIUC with the rendering schemes - they are intended to fulfil different roles. While there is some overlap, they are not alternatives in the same way the ALS and Rembrandt are (and shouldn't be) - we do want to see ALS and Rembrandt converging long term. We don't want nice atmospheric effects and no shadows/lights and vice versa. Judging from Tim Moore's recent post this might be doable. "Wrong direction" - don't know: if Emilian were still around you could ask him. Many of the problems here are caused by a poor command of English and consequential mutual misunderstandings. It is much to everyone's credit that they even try to contribute to the discussion. For example, I can see Henri's concerns, I suspect they are based on a misunderstanding, and they are badly expressed leading to more misunderstanding: a little more consideration would not come amiss. Enough, too long already Vivian ------------------------------------------------------------------------------ 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
