Re: [osg-users] Cull-Traversal Performance
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 1 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
Re: [osg-users] Cull-Traversal Performance
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 1 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
Re: [osg-users] Cull-Traversal Performance
Hi Sean, On Fri, Oct 31, 2008 at 2:16 PM, Sean Spicer [EMAIL PROTECTED] wrote: 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. The where on earth is it paradox with vertex shaders.. Probably the easiest way to solve would be to manually create an osg::KdTree for where the geometry would be if it had been transformed and then attach this KdTree to the Drawable where the vertex shader is playing games. This would speed intersections as well as solve the where on earth is it. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cull-Traversal Performance
Thanks. Is there a primmer on osg::KdTree anywhere? sean On Fri, Oct 31, 2008 at 9:37 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Sean, On Fri, Oct 31, 2008 at 2:16 PM, Sean Spicer [EMAIL PROTECTED] wrote: 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. The where on earth is it paradox with vertex shaders.. Probably the easiest way to solve would be to manually create an osg::KdTree for where the geometry would be if it had been transformed and then attach this KdTree to the Drawable where the vertex shader is playing games. This would speed intersections as well as solve the where on earth is it. 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
Re: [osg-users] Cull-Traversal Performance
On Fri, Oct 31, 2008 at 3:28 PM, Sean Spicer [EMAIL PROTECTED] wrote: Thanks. Is there a primmer on osg::KdTree anywhere? I'm afraid the source code and mailing lists discussions is all have right now. The KdTree data structure is actually quite simple, as is the algorithm that build/intersects so I expect you'll be able to review the source code and work out what's going on ;-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Cull-Traversal Performance
Hi Folks, First off, let me say that it's good to be back on the list - it has been awhile ;-) I'm trying to tune a scene-graph representing a relatively-large model. I'm seeing what I think are abnormally long cull-traversal times. The SG looks as follows: (State is constant across the entire scene) [Group] x 1 | [Switch] x 1 | [MatrixTransform] x 100 | [Geode] x 1 | [Geometry] x 100 There are approx 10K Geometry Drawables in the overall scene. The cull traversal for this scene graph is approx 10ms on a 2.5GHz Core2Duo processor. If I change the SG to the following: [Group] x 1 | [Switch] x 1 | [MatrixTransform] x 100 | [Switch] x 1 | +-+ | | [Geode] x 1 [MatrixTransform] x 100 | | [Geometry] x 100 [Geode] x 1 | [Geometry] x 1 and I turn on the new branch, the cull traversal jumps to 80ms. If I eliminate the single Geometry node below the new geode (so that the new branch is still there, but doesn't draw anything, cull-traversal falls to 40ms. Can anyone help explain what is going on here? These cull-traversal times seem long relative to the complexity of the scene and the speed of the processor - I'm trying to hit a 60Hz frame-rate, and even 10ms for the cull is just not going to cut it. For better or worse, there isn't a good way to simplify the complexity of the scene. cheers, sean ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
