Re: [osg-users] Setting CullVisitor
Hi Tim, On Tue, Nov 10, 2009 at 5:23 PM, Tim Moore timo...@redhat.com wrote: If you want to customize culling for a node that is a subclass of osg::Geode, you pretty much need to write your own cull visitor and override CullVisitor::apply(Geode); the low-level code that puts geometry into the render graph is contained in that function and is called after the traverse() function of the node class. osg::Geode is presently a bit of special case as it's the leaf node, all is not lost, you still have different techniques that can help avoid needing to subclassing CullVisitor. First up, the osg::Drawable have their own cull callback so if you want to change the culling on a Geode's drawables then you can place the cull callback on them. Another approach you can take is to subclass from osg::Node and mirror the osg::Geode behavour of managing it's own Drawables, and then in a custom traverse method you do the culling as your desire and adding the Drawables into the CullVisitor directly. Both of these approaches have the advantage that they work on any viewer, and you don't have to grapple with the overriding the default CullVisitor. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Paul,
Why do I have multiple SceneViews?
There are always two SceneViews if you're using multithreading - they're
used on alternating frames as you've seen. Just set your CullVisitor for
both, or a separate instance of your CullVisitor for each instance.
Whenever I've had to change something on SceneView instances, I had to
do it on both instances. I expect if your CullVisitor has some local
state, you'd have to use two separate instances, one for each SceneView,
so that threading works correctly and doesn't try to modify data that's
being read in another thread.
I need my own CullVisitor because I've defined my own node type that needs
special cull handling.
You could just override the traverse() method of your node type, that's
how I normally do it. It keeps changes local to the overridden node
class instead of propagating changes to other parts of the app.
void traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
// ...
}
osg::Node::traverse(nv); // call base class version.
// (replace Node by whatever the base class of your overridden
// node type is)
}
Hope this helps,
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Thanks for the quick response...
Did this:
render-getSceneView(0)-setCullVisitor(cv);
render-getSceneView(1)-setCullVisitor(cv);
and now I'm getting:
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Paul P.
- Original Message
From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tue, November 10, 2009 8:57:38 AM
Subject: Re: [osg-users] Setting CullVisitor
Hi Paul,
Why do I have multiple SceneViews?
There are always two SceneViews if you're using multithreading - they're used
on alternating frames as you've seen. Just set your CullVisitor for both, or a
separate instance of your CullVisitor for each instance.
Whenever I've had to change something on SceneView instances, I had to do it on
both instances. I expect if your CullVisitor has some local state, you'd have
to use two separate instances, one for each SceneView, so that threading works
correctly and doesn't try to modify data that's being read in another thread.
I need my own CullVisitor because I've defined my own node type that needs
special cull handling.
You could just override the traverse() method of your node type, that's how I
normally do it. It keeps changes local to the overridden node class instead of
propagating changes to other parts of the app.
void traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
// ...
}
osg::Node::traverse(nv); // call base class version.
// (replace Node by whatever the base class of your overridden
// node type is)
}
Hope this helps,
J-S
-- __
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
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] Setting CullVisitor
Hi Paul,
I think there is a better way to set your own visitor, maybe doing:
osgUtil::CullVisitor::prototype()=new MyVisitor();
if you do this before realize() (or run()), then the viewer uses the
prototype of the cull visitor.
Rafa.
On Tue, Nov 10, 2009 at 3:23 PM, paul1...@yahoo.com wrote:
Thanks for the quick response...
Did this:
render-getSceneView(0)-setCullVisitor(cv);
render-getSceneView(1)-setCullVisitor(cv);
and now I'm getting:
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Warning:createOrReuseRenderLeaf() skipping multiply refrenced entry.
Paul P.
- Original Message
From: Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com
To: OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sent: Tue, November 10, 2009 8:57:38 AM
Subject: Re: [osg-users] Setting CullVisitor
Hi Paul,
Why do I have multiple SceneViews?
There are always two SceneViews if you're using multithreading - they're used
on alternating frames as you've seen. Just set your CullVisitor for both, or
a separate instance of your CullVisitor for each instance.
Whenever I've had to change something on SceneView instances, I had to do it
on both instances. I expect if your CullVisitor has some local state, you'd
have to use two separate instances, one for each SceneView, so that threading
works correctly and doesn't try to modify data that's being read in another
thread.
I need my own CullVisitor because I've defined my own node type that needs
special cull handling.
You could just override the traverse() method of your node type, that's how I
normally do it. It keeps changes local to the overridden node class instead
of propagating changes to other parts of the app.
void traverse(osg::NodeVisitor nv)
{
if (nv.getVisitorType() == osg::NodeVisitor::CULL_VISITOR)
{
osgUtil::CullVisitor* cv =
dynamic_castosgUtil::CullVisitor*(nv);
// ...
}
osg::Node::traverse(nv); // call base class version.
// (replace Node by whatever the base class of your overridden
// node type is)
}
Hope this helps,
J-S
-- __
Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
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
--
Rafael Gaitán Linares
Instituto de Automática e Informática Industrial http://www.ai2.upv.es
Ciudad Politécnica de la Innovación
Universidad Politécnica de Valencia
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Jean-Sébastien Guay wrote: I need my own CullVisitor because I've defined my own node type that needs special cull handling. You could just override the traverse() method of your node type, that's how I normally do it. It keeps changes local to the overridden node class instead of propagating changes to other parts of the app. J-S is right. If you're developing a Node that requires special handling during the cull traversal, writing a custom CullVisitor is overkill. You should just override traverse() in your custom node. If you ever submit your node for inclusion in OSG, you can migrate the cull handling code into osgUtil::CullVisitor at the time you make the submission. This is what I did when I developed OcclusionQueryNode. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Paul, I know I risk making the thread diverge into unrelated concerns, but I wanted to ask: If you ever submit your node for inclusion in OSG, you can migrate the cull handling code into osgUtil::CullVisitor at the time you make the submission. This is what I did when I developed OcclusionQueryNode. Are there advantages to modifying CullVisitor rather than overriding traverse(), other than one dynamic_cast per frame per node? I think if that's the only advantage, I'd personally prefer keeping all the code related to the node type local to the type itself, even if that node type were to be included into OSG. But that's a coding style concern, I just want to know what you think about this and if there's something I have missed. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
On 11/10/2009 06:07 PM, Paul Martz wrote: Jean-Sébastien Guay wrote: I know I risk making the thread diverge into unrelated concerns, but I wanted to ask: No actually, I think this is the right direction for this thread to take. :-) Are there advantages to modifying CullVisitor rather than overriding traverse(), other than one dynamic_cast per frame per node? I think if that's the only advantage, I'd personally prefer keeping all the code related to the node type local to the type itself, even if that node type were to be included into OSG. Not sure. When I looked into this for OcclusionQueryNode, I was just following the existing coding pattern for core OSG nodes. Most of them had the bulk of their cull traversal functionality in the CullVisitor::apply() for that particular node type, and did not override the traverse() member function. -Paul If you want to customize culling for a node that is a subclass of osg::Geode, you pretty much need to write your own cull visitor and override CullVisitor::apply(Geode); the low-level code that puts geometry into the render graph is contained in that function and is called after the traverse() function of the node class. Tim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Jean-Sébastien Guay wrote on Tuesday, November 10, 2009 10:55 AM: Are there advantages to modifying CullVisitor rather than overriding traverse(), other than one dynamic_cast per frame per node? I think if that's the only advantage, I'd personally prefer keeping all the code related to the node type local to the type itself, even if that node type were to be included into OSG. But that's a coding style concern, I just want to know what you think about this and if there's something I have missed. From experience, I can say that one dynamic_cast per frame per node can really add up to hurt performance :) -- Bryan Thrall FlightSafety International bryan.thr...@flightsafety.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Setting CullVisitor
Hi Bryan, From experience, I can say that one dynamic_cast per frame per node can really add up to hurt performance :) Depends how many nodes. For example, for osgOcean::OceanScene, you should generally have only one in your whole scene. So in that case, one dynamic_cast per frame per node == one dynamic_cast per frame Of course, I wouldn't advocate doing one dynamic_cast per frame in a node that's going to be used all over the place, hundreds of thousands of times in the scene... :-) J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
