Thorsten wrote > -----Original Message----- > From: Renk mailto:thorsten.i.r...@jyu.fi] > Sent: 22 April 2012 12:03 > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Water shader issues > > > After the last related discussion, I've really been thinking a while if I should > bring this up again or not. I don't want to annoy people just for the sake of it, > I know open source development is often a thankless task in which one > frequently gets to hear more complaints about things not working than > thanks for things working, and all in all I perfer a pleasant atmosphere on the > mailing list, and critique of someone's code tends to lead to the opposite. > > But then, we had a performance discussion, and I had my share of criticism > about my use of Nasal slowing things down, and in the end it's information > which is better transmitted than not. > > Let me nevertheless start off by thanking all the people who worked on the > shader codes I've been looking at - I learned a lot about how this is done and > what can be done by just taking things apart and putting it back together > again, I have often enjoyed the effects before starting to mess with shaders > myself, and I guess many others also do. > > I've been over the water sine wave shader again, seeing if I could make run it > faster. What I found reminded me of something I (mean-spirited as I am) did > to a PhD student starting to work for me. I asked him to write a code > evaluating a quantum mechanical scattering process. He did so using an > established general-purpose Monte Carlo integral solver. I wrote a code for > the same problem, we compared the results and they were the same, so we > did solve the same problem and had the same solution - just my code was > 100 times faster. Afterwards, he was ready to accept that he can learn from > me how to code physics properly. > > That miracle was accomplished by me telling the integral solver where > performance is needed and where not (technically, this involves using an a > priori suitably biased sampling distribution, which after the fact gets > corrected by conditional probability calculus - which can be proven to work, > but looks like black magic). To give a very simple simple example, if we want > to evaluate r^2 pi and know r^2 with an accuracy of 10%, it isn't really a good > strategy to spend an hour to calculate a billion digits of pi. It requires to > understand the problem and not use all-purpose, but specially designed > problem-solving strategies. > > The same accuracy statement is true of the shaders by the way - so far all I > have seen use the Blinn-Phong shading model, so it's completely useless to > aim for an accuracy beyond what that can deliver, because Blinn-Phong is > already an approximation which limits the precision that can be achieved. > > Now, it struck me that the water shader computes wave patterns and foam > on a meter-scale. It does so even for a pixel which is 120 km distant (and > which probably represents an area of 100x400 m or so). We first calculate a > very detailed wave pattern and foam for that pixel, then let the renderer > average everything out again to give the pixel a color. That didn't strike me as > a particularly efficient way to do things. > > I replaced the wave pattern in the distance by something that averages to > the same thing. That's not the average wave pattern (=a flat surface) > because reflected light intensity is a non-linear function of the surface > distortion, but noise with the right amplitude, leading to the same standard > deviation and the same average, gets the job done. I also asked not to > compute any foam beyond some other distance. As a result, the shader > performance jumped from 30 fps to 42 fps in a benchmark situation (ufo at > 30.000 ft looking at the horizon, 120 km visibility range). > > In general, how much performance one spends on distant stuff doesn't > influence the visuals drastically, because these pixels are more and more > fogged and more and more details are averaged out. But more than 80% of > the vertices in the scene are farther than half the visibility range, and a fair > share of pixels is, and that's the stuff you see from a typical cockpit > perspective. So in terms of performance, simplifying the rendering of distant > objects counts a lot. > > I have spent 30 minutes testing the visual impression of my changes in > different winds, in different light and from different altitudes, and I could not > spot any problem - the shader just ran faster. Despite this, it's possible that > there is a problematic situation somewhere. But the answer to this should > not be to revert the changes, the proper answer should be to code an > exception dealing with the particular problem. > > I did not get the impression that there was so far any attempt made to > optimize the performance of the water sine shader. It's difficult to compare > directly since I added the whole terrain haze and lightfield rendering, but I > suspect that if all I did (remove redundant operations, throw per-frame > constant computations out of the shader, do not use textures to sample > constant colors, do not interpolate the normal of water, do simplified > rendering for large distances,...) would be applied to the original water > shader, it could run twice as fast in many situations without any loss of visual > detail. > > I know that it's tempting to ignore me, because at the end of the day I still > don't really know a lot about how the technical aspects of 3d rendering work. > But on the other hand, once we're inside the shader, it's just an algorithm to > compute a physics problem. And this I know in all likelihood much better than > most people on this list. So do with the information what you like. >
I'm sure this is all very well and good - but what are we meant to be testing/doing/patching? Your last patch was all very good - except it only worked with advanced weather, so I was forced to abandon it. The water-sine shader is intended to work with both forms of weather, and so it is inevitably compromised. It would be good if the weathers could be harmonised. Vivian ------------------------------------------------------------------------------ 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
