Robert, interesting. Thank you for the detailed explanation. Looking at the osgforest shader-path, one challenge that I see is that if one needs to be able to "pick" the geometry, then the SG doesn't know about where it is in space to run an interesector. Any thoughts on a strategy to overcome this? I was thinking about "hidden" geometry, but the intersector wouldn't see it.
cheers, sean On Fri, Oct 31, 2008 at 4:31 AM, Robert Osfield <[EMAIL PROTECTED]>wrote: > Hi Sean, > > Welcome back :-) > > Transforms are relatively expensive, as the transforms need to be > tracked as well as the view frustum needing to be transformed into the > local coords below the transform for culling performance. You two > subgraphs have 100 vs 10,000 transforms per frame, 100 won't take the > cull traversal much at all, but 10,000 will. > > Second up having lots of separate osg::Geometry, even when a small > number of shared many times, requires lots of work in cull in doing > the actual cull test and more critically creating all the RenderLeaf > back end data structure required to represent the Geometry instance > with its final combination of modelview, projection and state. > > So as a general rule, keep the number of transforms down, by applying > the transforms to the subgraphs and copying the geometry if required, > and keep the the number of separate geometries down by combining > smaller geometries into bigger groups. > > Since you culls do look rather high even with the small scene set up, > while it's a bit of long shot, make sure that you do all your tests in > release/optimized build. > > Another area you could look at at inspiration is the osgforest example > - it provides a range of implementations of forests that you can step > between, in the svn/trunk version of the OSG I've added in the > StatsHandler to show the relative costs of cull/draw and GPU. You > run the osgforest example with a command line option to set the number > of trees for instance: > > osgforest --trees 10000 > > This will give you an indication of the how each of the techniques > might work in your instance. In particular the shader path would > probably be most applicable. > > Other items you could look at is the use the multi-threaded use of > osgViewer, as the DrawThreadPerContext would certainly help hide the > cost of your long cull. > > Finally we have had some check-in's since OSG-2.6 include > optimizations in Matrix that reduce the overhead associated with > Transforms. So try out the SVN/trunk or 2.7.x developer releases. > > Robert. > _______________________________________________ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- Sean Spicer Executive Vice President & Chief Technology Officer Aqumin (www.aqumin.com) Office....+1.281.466.4848 Mobile...+1.713.447.2706 Fax.......+1.281.466.4849
_______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
