> I'm not sure this is necessary. I think an opt-in checkbox would > suffice. After all FlightGear has been around for personal experiments > for a very long time. So why not this option.
I don't mind leaving it - the rational for deleting it is that the texture sheets take up space and download bandwidth and the shader instructions take up GPU registers for everyone - even those who are not interested. So, let me just try to explain better, because we do have a case study to see what's likely to happen next. Lauri introduced the skydome shader a while ago. That was controlled by Rayleigh, Mie and density sliders. I think these are pretty technical terms - I'm not sure the average user knows or is interested in what Rayleigh scattering is. So we have a new project with impressive graphics arriving on the scene. What was the reaction? The developer community largely supported it, someone coded a place in the GUI. What I did not hear are Mathias' remarks that all this is a very bad idea and Lauri should have done it differently. I did not hear that Rayleigh, Mie and density are complicated concepts and we need to simplify that because the user gets confused otherwise. I did not hear that cranking density all the way down or up it is completely possible to generate an airless Mars-sky or a super-dense greenish gas giant atmosphere and that we need to prevent the user from moving the sliders that way. I did not hear that we shouldn't implement this because it produces glaring graphical artefacts due to the mismatch with the terrain shading. I did not hear that it doesn't work under any amount of heavier fog, because the skydome is never fogged. The user by and large community loved it. There are series of screenshots from the time where you can see that users happily accept playing with Rayleigh and Mie, accept looking at obvious mismatches with the terrain just to get the sky pictures. (Well, there was one rather critical voice - that was me. But since I believe in constructive criticism, I didn't point out the flaws before I had read up O'Neill's original article, concluded that he doesn't understand what he's really solving, re-derived the scheme from scratch by just solving the integrals analytically, and then concluded what was missing in order to make things realistic, and when I started pointing out the flaws, I could offer a clear path to correct them. As it turned out, I also ended up implementing it myself.) We may conclude that the user loves shiny and exciting graphical features, is willing to accept an un-intuitive GUI that can produce unrealistic outcome and is even willing to accept massive graphical artefacts under some conditions. The funny thing is - when I finally fixed the artefacts by writing the matching terrain shader, THEN everyone started complaining why effect XY didn't work any more when the skydome was on. It was irrelevant that the artefacts matching terrain and skydome were gone, but the fact that one could not longer have bumpmapped planes together with the skydome shader really bugged people. We may conclude that the user *really* loves shiny graphics, no matter the cost otherwise. (Btw, - could anyone tell Mathias what the end user wants? The user wants an ubershader - that's the single most requested feature I had to deal with in the last year...) Of course, the skydome shader is a non-trivial beast with lots of dynamics in, so once one changes from the isotropic default skydome to the dynamical beast, the minimal matching terrain shader suddenly uses 220 lines of light and fog code rather than just 2 lines. Pretty much anyone can tell you that if you make a system 100 times more complex, it's going to take some time to get it free of all trouble. At which point it's very helpful if the surrounding community realizes that simple fact and tries for some constructive input - which may be as simple as one or two more folks who explain forum users how the FG shader system works and why effects can't simply be switched on in a new framework and why this is not a bug, or helps by diagnosing flaws rather than just pointing at them. It turns out that in the event I was also able to remap the Rayleigh/Mie/density parameter space to a 2-parameter space covering all the situations relevant for the Earth atmosphere, ths preventing unrealistic input, handing one of the new parameters to the weather system and leaving the other under user control. In principle this implies we could have removed the Rayleigh/Mie/density control - but when I asked if that should be done, the decision was made here to keep it (!). So, what do I learn from that case study as it applied to a potential procedural season model? 1) Users are likely to love it, no matter if the GUI has three additional sliders or not. Enthusiastic forum responses seem to confirm that. 2) In the case of the skydome, I was able to get a heuristics throwing out the unrealistic input. Anders suggests to build a similar heuristics here. Realistically, who is going to do that? I've been thinking for the last 1 1/2 month about the problem, and I have concluded that I can't do it. So if anyone thinks it can be done, please give me a concrete sketch of how, or I will stick with my opinion. 3) Some amount of support from the devel community is essential if the project is complex. A complicated project has to be embraced and backed by a decision to do it. That doesn't mean everyone helps coding, but it does mean people help communicating to users why strange results occur, help providing ideas for the GUI, help out in small ways (for instance, 'gluon' gave me a better (rgb) triplet for the base color of the sky, which improved the results tremendously - it's not big in terms of coding, but costs lots of time and patience to get right). If there are competing ideas around (as in the case here discussing static season schemes, like Stuart's tree scheme would be) and there is at this point support for the static scheme, but not for the dynamic scheme, then it makes no sense to compete. 4) The current scheme allows obviously unrealistic input - I can select winter textures for Jamaica, and I will see the snow-covered Caribbean. This hasn't bothered anyone for years. Among the first things I get to hear about procedural seasons at at proof of concept stage is: It doesn't fit autumn as in the UK at full slider position. I'd perhaps think that even a semi-realistic autumn at any slider position is better than no autumn at all. Procedural snow by texture was in for a long time before I started working on it. It didn't bother anyone that trees didn't automatically adapt before, but one talk about procedural seasons start, this gets on the table. Rayleigh/Mie/density was actively kept in the GUI even given that we have a model which allows to remap them into intuitive parameters - but the prospect of having to adjust more than one seasonal slider is suddenly very scary and confusing for users. Given that, I predict a high probability that whatever goes wrong in the scheme, several people will immediately point out 'told you so, was a stupid idea to begin with, I've always said...' 5) What I do on my harddisk is my business. I don't have to worry about a fool-proof GUI, I don't have to deal with hardware incompatibilities, I don't have to explain for the nth time why X is not so easy, I only get to deal with users who specifically want the feature and are hence constructive. Given the alternatives, I'd say that 5) has a lot of appeal. Coming up with a procedural continuous season model is a complex task, everyone here knows my track record for dealing with complex environment models and can draw conclusions if I'm up to the task or not, there is an existing proof of concept, given my track record and the proof of concept the feedback was very negative, so my conclusion is that the project has insufficient support. I am specifically not looking forward to complaints along 'but in my region, trees turn yellow and not red' or 'shouldn't the trees be different as a function of altitude' or 'this is really bad because I need to reduce my tree density from 1.5 to 1.3 in order to get the same framerate as before. So, please feel free to use what is committed, please feel free to ask me if you want to have whatever I develop beyond that, but that's where it stops for me. I've fought twice to make real two rather complex projects a reality, in both cases the level of support up-front was higher than for the procedural season idea, I'm not going to do it a third time. Either you see the potential in it, or you don't, I'm not going to argue for days to make everyone else see it. Cheers, * Thorsten ------------------------------------------------------------------------------ The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials, tech docs, whitepapers, evaluation guides, and opinion stories. Check out the most recent posts - join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
