Stuart, On Wednesday, December 14, 2011 15:49:22 Stuart Buchanan wrote: > 2011/12/14 Mathias Fröhlich wrote: > > But, the question is how many cloud drawables do we have? The render Bin > > sorting bottleneck - if we run into this - is O(log(n)*n) with the n= > > number depth sorted drawables. Which means we need to have a huge amount > > of cloud drawables that this effect dominates. > > As you've seen from the code, at present, we have a cloud drawable per > sprite, where there are multiple sprites per cloud, and >1000 clouds in a > typical Cu layer.
Than I assume 10 to 500 sprites in one cloud? Which makes about 10000 > draws for the clouds. That could explain the observations. Ok - thanks. > > Ok, looking into the Cloud drawable implementation, I believe that your > > almost first response is probably the easiest. Just without point > > sprites, just improoving what is currently done: > > Try to put that multiple draws into a single draw using array objects. > > Make sure that you still get a 'fast drawable'. YOu can verify this by > > asking the geometry if osg::Geometry::areFastPathsUsed() returns true. > > That is mostly: do not use any index arrays. The only indices which may > > be worthwhile are the indexed primitives sets. > > Sorting inside the drawable is then done by either redoing the arrays or > > probably better by using an indexed primitive set and reordering the > > indices. > > I will try this tonight. Thanks again for looking into this and > helping to point me > in the right direction. > > (BTW - I think I've managed to get Impostors working though I've still to > see any performance gain) Ok, if this helps this is fine. So the granularity is one cloud per imposter? For this approach, you need to know that setting up a new fbo for draw is not exactly cheap. It's not catastropic, but again don't do too often. Also each cloud probably uses one texture of some size which will occupy memory. Having >1000 of them is probably significant. Also drawing a cloud is than not only the draw, but also the texture change state change that needs to happen on every draw. This could still be a net win. But that's what I think is good to know to balance the orders of magnitude. May be it helps to have less individual clouds where each of them is drawn with a single draw? An idea that I had yesterday. Just a dumb question: Is it possible that we have some problem so that we have more clouds in the visible scene than we really expect there? That is is there a bug that makes some of them being drawn techically but not appear on the screen where they should be? Which could make draw so expensive by drawing more than we can see? So, just because experience shows that problems have often very simple reasons compared to the first ideas what could happen ... I hope that I really guide into the right direction. Greetings Mathias ------------------------------------------------------------------------------ 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
