On Friday 13 April 2012 07:05:40 Renk Thorsten wrote: > > 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. See below*. > 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 Not when the varying number is limited. So you gain a bit of speed, but you lose a lot of compatibility.(think ATi/intel, or OSS drivers for nVidia)
> > 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...) No it doesn't, it's not a separate shader, it's a separate function in the same shader (think of it as equivalent the #include system). At compile time the two files are concatenated resulting in a single shader. > 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. (*)No it's not bad design, it's a conscious hack around the state that the environment interface was in when the shader was developed. And it's an attempt to make it work with both sytems. IIRC there was a request posted on this same ML at that time that the environment properties be extended, and unified between weather models, but there was no action take on that. So Vivian (and I in the transition shader) had to work with what was available. > 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. It would be good to make it Weather system agnostic from the effect/shader side of things, don't you think? > > Cheers, > > * Thorsten Regards, Emilian ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/flightgear-devel
