2012/4/22 Renk Thorsten <thorsten.i.r...@jyu.fi>: > > 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
Thorsten, After having read this long post, I had mixed feelings. Posts that start by something like "First of all, I find that you are all doing a great job" are, in most cases, intended to tell the exact opposite. And indeed, at first, it looks like you are trying to prove you are more skilled and experienced than most people of the ML are. As far as I am concerned I am no expert in quantum physics so you are most certainly more skilled and smarter than I am and ever will be. After some further thoughts and knowing the contributions you made to FG, it seems that there is another message behind your post. It looks like you are trying to submit some changes to the code of FG, changes that are technically sound but that some people are resisting. You probably hit the human factor. According to this post, the strategy you chose is to exhibit your professional skills and your immense experience on similar subjects. You are thus relying on the authoritative argument. Unfortunately, this strategy is generally doomed to failure. In most cases, the reason is that the authoritative argument is hurting egos : it implicitly claims you are an expert while (some?) others are not. Once egos are involved, a discussion can no longer take place at the technical level. No matter how good your technical arguments are. People will resist your proposal because, in their minds, it would mean otherwise that they acknowledge you are an expert while they are not. Furthermore, asking the whole ML to act as witnesses of your authoritative argument will lead nowhere. For the simple reason that most people are indeed no expert in the field of quantum physics, sine waves, shaders and whatnot. So they cannot approve or disapprove your claims. All I can suggest you is to drop the authoritative argument and try to stick to the technical facts. And if, at the end of the day, your change is not included in FG, will it be that terrible ? Good luck. Bertrand. ------------------------------------------------------------------------------ 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
