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 ------------------------------------------------------------------------------ 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
