It occurred to me yesterday that there seems to be a major misunderstanding in the way Atmospheric Light Scattering (ALS) is perceived by different people. So in order to avoid future misunderstandings, let me try to clarify my side once again.
Vivian: > Do we need to go down this road? We are breaking more and > more for minimal gains. Did we ever restore the wake effect on the Carrier > with Atmospheric Light Scattering? Emilian (a while ago): > I have nothing about the core of the Advanced weather engine, I have an issue > of how you interact with it, and how it interacts with other parts of the > whole system... and in my view this is broken. > I also have nothing against the idea of the atmospheric scattering, I have an > issue with how it's done, which is suboptimal in my view... and again of how > you can interact with it/ how it affects other systems, and how it's affected > by > other systems. The common theme here is the perception that something is broken, which is naturally not my perception. For instance, the fact that ALS doesn't have a wake shader effect indicates its brokenness the same way as the fact that the default rendering doesn't have procedural texturing working - which is to say, not at all. Vivian might correct me, but I think I finally understand where that notion comes from. I think it comes from the view that ALS is in essence just another way to compute fog and light for what the default rendering scheme does, and from this perspective, any effect that doesn't work is indeed broken. The original plan was indeed to implement things as just different fog and light, there is still the parameter 'fog-type' in the effects which would support such an implementation, and there was a 6 months window during which Emilian and Vivian had the opportunity to implement it that way. As this didn't happen (for whatever reason) I decided to ask for some help and Fred kindly told me how to implement it as a different rendering framework (i.e. loading a whole different effect rather than a different fog shader only). So, from where I stand, that decision is done and it is now a different rendering framework, which means clean slate, all effects have to be written from scratch, with all the pros and cons to that (which we might debate endlessly). So since this window of opportunity to start from scratch happened, I took the opportunity to address a few things I saw as shortcomings in the default rendering framework we had. Just to give a few examples: * Environment interfacing: Emilian's view that the way ALS and Advanced Weather interact with the rest is broken is... bold. Just to give an example for how he addressed the interface, for instance the water shader needs to know the amount of reflected light at the water surface in order to compute reflection. Emilian's and Vivian's version of the water sine shader solves this by passing the cloud layer configuration settings of Basic Weather to the shader and then compute in the fragment shader from that the amount of light. This means that a) Advanced Weather has no chance (even conceptually) of ever passing the correct information to the shader since it doesn't use the Basic Weather config properties to create clouds and my understanding is that it is even impossible to write these properties without actually generating visible clouds interfering with what Advanced Weather does, and that b) a quantity which changes in Basic Weather once a few minutes (when a new METAR comes in) is computed about 60 million times each second. I may not be a rendering wizard, but this doesn't sound like the way to implement an environment interface to me. My supposedly broken interface references a single property 'light reaching the ground' for the same purpose. That property isn't native to the weather system, it can be set by hand with the browser without affecting anything else but the shader or be computed by any weather system currently running, i.e. shader control parameters are explicitly and always separated from native weather system parameters. This means the computation can be done if and only if needed, and the interface doesn't prefer one weather system over the other. * Consistency I've witnessed quite a few forum discussions with people complaining that they didn't think selecting higher quality shader settings would give them higher quality visuals (usually this was about the crop and forest overlay texture effects which some like and some don't - I have my opinion which is irrelevant here). Likewise, snow and fog were not always consistent across landclasses (I believe this is fixed now). Starting from scratch offered the opportunity to organize quality settings with a clear idea in mind, using a consistently selected set of effects. Now, consistent doesn't necessarily mean superior, it just says it's all my idea of visual quality, not a mixture of different ideas. But then again, I might argue that after all I won the screenshot contest, so if anyone here has something like an 'official' stamp for widely shared visual quality judgements, that'd probably be me then. * Toolkit Together with the regional texturing, giving an easy and xml-configurable way to users to change the scenery appearance is something which I consider very important, as it lowers the entry barrier tremendously for everyone who wants to work with scenery. I have never seen so many people play with scenery before than in the recent months. Personally I think in terms of configurability, having a terrain ubershader completely driven from materials.xml is much superior to having to write effects for individual landclasses. Again, this might not be everyone's idea of how things are supposed to be, but since it doesn't interfere with the previous way of doing things - a surprisingly simple solution for everyone who doesn't like the idea is to not use it. So, to summarize my position: Atmospheric Light Scattering is a different rendering framework with its very own set of effects (which some people consider better, others worse than the default). It is not a different way to draw fog and compute light for the default rendering framework. I think the way it interfaces with environment in terms of neutral control properties and computations done outside the shader is very reasonable, and if someone considers calling the interface 'broken' in the future, I would kindly ask for concrete evidence, or I will dismiss such statements immediately as obviously unfounded. The set of effects which ALS provides doesn't default to all effects in the default rendering framework, it defaults to the choice I consider being most interesting plus whatever others contribute because they consider it interesting. I don't see it as my duty to provide every effect which is in the default framework, just the same way as I don't see it as anyone's duty to implement every of my new effects in default. I certainly listen to what people would like to have, but I don't feel under obligation to deliver for every wish. Having the model ubershader available is obviously a legitimate wish of modellers, but asking that it does exactly what its counterpart does and should never get any new options is not. So if the definition of 'broken' is 'doesn't work as in the default framework' then I would suggest to revise the definition - it's not supposed to work the same way, because I see merit in doing it differently. We can argue about how a proper interface should look like, or how users should get access to terrain shaders, but please on the basic of actual arguments. Anyone how thinks it really should be implemented as just additional fog and light is also free to grab my code and do so, it's all GPL. Hopefully these comments help to provide realistic expectations and reduce frustration on both sides. Best, * 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
