2011/12/15 Mathias Fröhlich wrote: > 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.
For the global weather 3D clouds it is typically between 5 and 15 sprites per cloud. We perform some sprite-culling to avoid creating sprites that are too close together. For Local weather it's sometimes as low as 1 sprite per cloud. >> > 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. I made the changes you suggested last night so that there is a single geometry per cloud instead of one per sprite. That should have reduced the number of draws by a factor of 10. The code isn't ready to be checked in (I've still got to sort the geometry), but so far it hasn't made a significant difference to the frame-rate on my system. However, I've got a fairly big graphics card and get fairly high frame-rates, so it may help more for other people. It certainly doesn't make things any worse, and the code changes are smaller than I had feared, so I expect to get this change checked in for 2.6.0. >> (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? No. At that level my machine ran out of memory. I've got an Impostor for each top level LoD node, which typically contains the clouds in a 10kmx10km area, so we end up with ~18 Impostors. Still no performance gain from this either. I've made it configurable using properties, so once it's checked in people can experiment to see if varying the LoD size, and hence number of impostors, helps. Again, the code changes were remarkably small, so I expect to have this ready in time for 2.6.0 > 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 ... Very good point. So we might not be culling the clouds properly? I can easily put in some code to check this. I _think_ I've got the bounding boxes set up correctly and a sensible LoD tree, but this is something I should check. > I hope that I really guide into the right direction. Please keep suggesting ideas. I'm a bit time-limited right now, so it may take me some time to write the code to test them, but I'm "all ears" :) -Stuart ------------------------------------------------------------------------------ 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
