I've made a case study converting the high quality water shader (my favourite shader effect :-) ) to lightfield rendering in the last two days (see some pics in the forum here
http://www.flightgear.org/forums/viewtopic.php?f=47&t=14755&start=150#p155110 sunrises with water reflection look awesome - but the water shader is probably the only thing which eats more performance than the lightfields...). The water shader slider (if on or above 4) is now honoured even when lightfield shading are on. Since someone (FredB?) promoted the lightfield to technique 5, water now has to use 4 - are we running into any limitataions with these numbers, or can we simply shift everything back if needed? I know that Vivian and Emilian had the plan to separate fog and light computations from the shaders and have them in general functions to be called by all shaders. While this is very elegant and maintenance friendly, I've come across a few issues in converting the water shader which aren't really trivial for that approach: 1) The water shader doesn't actually use the full amount of light information, it just uses the diffuse channel and assigns that rgb value to both ambient and specular light while diffuse scattering isn't computed at all. A general light function returning ambient, diffuse and specular would waste ~2/3 of its computation time here. 2) The precise implementation matters a lot - calling the light where it is used (in the fragment shader) is significantly slower than calling it in the vertex shader (water vertices are sparse...) and passing it as a varying vec3 to the fragment shader. So, if one generalizes light, one has to do it in such a way that diffuse, specular and ambient are separate functions and implement it in a clever way. But then 3) Light and fog lighting computations share a lot of stuff - the whole relative geometry between eye, sun and vertex altitude determining the light at low sun has to be solved once in a dedicated do-it-all shader. If the light function is generalized, somehow lots of vectors and parameters have to be either passed or re-computed, which presumably slows things down (I'm not sure how a general include framework would look like and whether parameters would need to be passed inside the function call or as varying from the vertex shader...) 4) I spent just 1/3 of my time getting the shader working, then 2/3 removing double tasks. The water shader does a lot of things already which the fog and light computations need later, so I can use what's already there instead of re-compute it, which speeds things up noticeably - something which is difficult to anticipate when writing a general function. 5) Last, water being water being always flat and hence never able to shadow the fog allows to drop some computations without loss of accuracy which again speeds things up - which a general fog function could never do. So to me it seems we can have either maintenance-friendly shaders or fast shaders. Given the rather staggering framerate impact of the water shader, personally I prefer a fast shader - I can live with having to spend an hour updating light computations across several files, but I can't live with a framerate of 5 fps. Can we get some other opinions on that question? I've also looked at the environment interface of the water shader and changed it drastically in the lightfield version. In my view, determining the cloud coverage on a per-fragment basis by passing 5 uniforms into the shader and evaluating them in the fragment shader is bad design. Things which are constants in the whole scene per frame need to be determined outside the shader and passed as a single uniform. Doing so gains me ~20% more performance in my test case. I've started to set up an interface in environment/surface/ which is populated with the relevant environment at the ground beneath the aircraft (average wind, current wind, ground light intensity,...) and started using that from the lightfield shaders. I would hope that we can eventually gather all shader/environment crosstalk there. Question: Currently basic weather is not properly supported by the framework because I've pulled many computations outside the shaders to be passed as uniforms. Are people interested in keeping Basic Weather and lightfield shading compatible? If yes, let me know and I can help setting this up, it's not difficult, it just requires Basic Weather to compute a few things which used to be in the shaders. If no, please also let me know then I don't bother trying to set up reasonable defaults. Question II: I would ask that the rendering GUI is modified. The label of the skydome shader should be changed into something like 'Advanced atmospheric light model' with an added warning '(this will disable some shaders)'. The Rayleigh, Mie and density selection panel is obsolete for the user (the weather system sets these based on its atmosphere layer model) and should go to the 'Debug' section. This would make clear to the user what is going on when enabling the framework. Can we do this change? Question III: (unrelated): I have ~ 2 weeks of good coding time ahead of me (the kids are on vacation with the grandparents) - one plan is to get the snow effect into the lightfield framework, but I was mainly hoping for Torsten to get the configurable rain ready - I have some very interesting plans what to do with this... Torsten - what is the current status? Cheers, * Thorsten ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
