Re: [osg-users] cull traversal
Just looked at the code .. So it is _viewer->renderingTraversals(); calling renderer->cull(); on the Cameras Is there any way to know when this cull is completed? On Sun, Mar 20, 2016 at 12:52 PM, Trajce Nikolov NICK < trajce.nikolov.n...@gmail.com> wrote: > Hi community, > > any clue when the cull traversal is being dispatched in this decomposed > viewer frame calls? > > _viewer->advance(); > _viewer->eventTraversal(); > _viewer->updateTraversal(); > _viewer->renderingTraversals(); > > Thanks a bunch as always! > > Nick > > -- > trajce nikolov nick > -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cull traversal
HI Nick, The osg::Stats object can record different times for various parts of the frame, a subset of these are displayed by the StatsHandler when you enable it. If you need a callback for the end of cull traversal then there isn't any specific built in for this, you could subclass from osgViewer::Renderer and implement your own wrapper for the cull traversal to do what you want. Robert. On 20 March 2016 at 17:04, Trajce Nikolov NICK < trajce.nikolov.n...@gmail.com> wrote: > Just looked at the code .. So it is > > _viewer->renderingTraversals(); > > calling > > renderer->cull(); > > on the Cameras > > Is there any way to know when this cull is completed? > > On Sun, Mar 20, 2016 at 12:52 PM, Trajce Nikolov NICK < > trajce.nikolov.n...@gmail.com> wrote: > >> Hi community, >> >> any clue when the cull traversal is being dispatched in this decomposed >> viewer frame calls? >> >> _viewer->advance(); >> _viewer->eventTraversal(); >> _viewer->updateTraversal(); >> _viewer->renderingTraversals(); >> >> Thanks a bunch as always! >> >> Nick >> >> -- >> trajce nikolov nick >> > > > > -- > trajce nikolov nick > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cull traversal
Hi Robert, > If you need a callback for the end of cull traversal then there isn't any specific built in for this, you could subclass from osgViewer::Renderer and implement your own wrapper for the cull traversal to do what you want. I though of this. And it is the proper way I think. I did it in a simpler way by adding a node at the end of the scenegraph and set a cullcallback and it works Thanks anyway :-) Cheers, Nick On Sun, Mar 20, 2016 at 8:44 PM, Robert Osfield wrote: > HI Nick, > > The osg::Stats object can record different times for various parts of the > frame, a subset of these are displayed by the StatsHandler when you enable > it. > > If you need a callback for the end of cull traversal then there isn't any > specific built in for this, you could subclass from osgViewer::Renderer and > implement your own wrapper for the cull traversal to do what you want. > > Robert. > > On 20 March 2016 at 17:04, Trajce Nikolov NICK < > trajce.nikolov.n...@gmail.com> wrote: > >> Just looked at the code .. So it is >> >> _viewer->renderingTraversals(); >> >> calling >> >> renderer->cull(); >> >> on the Cameras >> >> Is there any way to know when this cull is completed? >> >> On Sun, Mar 20, 2016 at 12:52 PM, Trajce Nikolov NICK < >> trajce.nikolov.n...@gmail.com> wrote: >> >>> Hi community, >>> >>> any clue when the cull traversal is being dispatched in this decomposed >>> viewer frame calls? >>> >>> _viewer->advance(); >>> _viewer->eventTraversal(); >>> _viewer->updateTraversal(); >>> _viewer->renderingTraversals(); >>> >>> Thanks a bunch as always! >>> >>> Nick >>> >>> -- >>> trajce nikolov nick >>> >> >> >> >> -- >> trajce nikolov nick >> >> ___ >> osg-users mailing list >> osg-users@lists.openscenegraph.org >> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >> >> > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cull traversal
> I did it in a simpler way by adding a node at the end of the scenegraph and > set a cullcallback and it works Yes, that should work. You could also set a cull callback on the root node, and in the callback do this: traverse(node, nv); // cull scene root // end of cull traversal -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=66569#66569 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] cull traversal
Heh :-) .. That is even simplier .. Thanks Jannik! Nick On Sun, Mar 20, 2016 at 9:43 PM, Jannik Heller wrote: > > I did it in a simpler way by adding a node at the end of the scenegraph > and set a cullcallback and it works > > Yes, that should work. You could also set a cull callback on the root > node, and in the callback do this: > > traverse(node, nv); // cull scene root > > // end of cull traversal > > -- > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=66569#66569 > > > > > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > -- trajce nikolov nick ___ 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, 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
