On Mon, Dec 5, 2011 at 8:26 AM, Thorsten Renk wrote: > Since according to the newsletter Stuart's current ongoing quest is to get > better performance for 3d clouds, here are some of my observation:
Thanks very much for the observations. Lots of food for thought :) As an FYI, the investigations I've been doing haven't born much fruit. In fact, I've been thinking that my "quest" is a bit like that of the Holy Grail - something you never actually attain :) I had come to the conclusion that the only way to get a signficant increase in performance would be move to using Impostors. That's a big change, particularly as the OSG implimentation appears to be broken/bit-rotted. I've been strenuously avoiding having to think about implementing it myself, but I may have to just bite the bullet. Either way, it isn't going to happen for 2.6.0! > * I've noticed that when I use the relatively lowres Altocumulus texture > sheet (3x3 on one sheet) I can basically use a ridiculous number of > sprites without performance deterioration, whereas when I use the hires > Cumulus sheets (1x2 plus 1x3) the number of sprites I can show before > performance takes a nosedive goes down substantially. That's very interesting information indeed. I will do some like-for-like experiments One contributing factor may be differences in the amount of transparency in the different textures. > * There seems still to be stuff computed in the shaders per vertex that is > actually an uniform per frame - eyepos for instance. I wonder if the > computations could be speeded up significantly by consequently pulling > all things that are really uniforms out of the shaders. I'll take a look. Vector and matrix calculations should be very efficient in the GPU, and we're "only" performing these per-vertex rather than per-fragment, so there may not be much benefit. > * We're likewise fond of computing stuff per frame that changes more like > per minute. The orientation of faraway clouds doesn't have to be computed > per frame, because it can't change much per frame. If there'd be a way to > store the value used last time, then (based on a distance criterion), one > could assign clouds into n task groups and recompute a task group only > every nth frame and use the last stored value otherwise. Back when I > rotated clouds from Nasal, this did work and improved performance by a > factor 5 or 6 - not sure how much it could do with a Shader setup, not > sure how to do it technically, but my guess is that it would speed things > up. We already use this technique for sorting the sprites within the cloud, by using a heuristic that if the sprites were already sorted the previous time we checked, they probably still are. We could do something similar for calculating the eyepoint outside of the shader, but as pointed out above, I'm not sure this is the main perf limitation. -Stuart ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
