Stuart wrote: > 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. >
Emilian and I noticed that the "local" cloud effect files are using render bin 10 - thus competing with all other transparent objects, while the "global" clouds use render bin 9 - the dedicated cloud bin. We have tried moving all the clouds to render-bin 9: Emilian reports a significant gain in performance but I see little change here. However, we are not aware of the reason for the use of different bins. We also note that you are back to using the .png textures with their black edges etc., rather than the .dds that we provided. Use of .dds textures should at least be no worse than .png and at best will provide a small performance advantage. Unfortunately, we are only scratching around the edges for improved performance using the existing technique, and really we need to try something a bit more radical. Vivian ------------------------------------------------------------------------------ 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
