Re: [osg-users] cull traversal

[Trajce Nikolov NICK]

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

[Jannik Heller]

>  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

[Trajce Nikolov NICK]

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

[Robert Osfield]

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

[Trajce Nikolov NICK]

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] cull traversal

[Trajce Nikolov NICK]

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
___
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 Osfield]

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

[Sean Spicer]

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

[Robert Osfield]

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

[Sean Spicer]

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

[Robert Osfield]

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

[Sean Spicer]

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