Le mercredi 24 avril 2013 06:58:41 Renk Thorsten a écrit : > 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 Hello Renk, I don't use to talk within this devel-mail. However your approach is questionable. I can understand you are working on an other FlightGear "variant" for yourself. You call it Atmospheric Light Scattering, you could call it Renk ALS :) It is not the Atmospheric Light Scattering, we want. Referring to your explanation, and some other talks you had with Emilian ( who unfortunately gave up ), you are ignoring the flightgear users community interest. It is not the Atmospheric Light Scattering, we want. We want, so far, a consistent flightgear system, any features should be compatible each other, and not breaking each other. What about Rembrandt ? To reproduce the reality, isn't it the main tool which gives the best effect ? Won't the effort should done on that side ? I hope that the next Flightgear version will offer a consistent system and not several independents systems ( including your Flightgear) which won't be compatible each other. Thank Henri ------------------------------------------------------------------------------ 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
