On Sunday 22 April 2012 11:02:46 Renk Thorsten wrote: > 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. > > Have a nice Sunday! > > Cheers, > > * Thorsten All the sine stuff happens in the fragment shader, so performance is directly related to the amount of screen pixels covered by water, not on the amount of vertices. Maybe just testing the pixel depth against the fog distance might bring some performance in fogged scenarios, where you won't compute the sine waves beyond visible range, for the few pixels that fall into that category.
------------------------------------------------------------------------------ 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
