Re: [osg-users] Making Node::dirtyBound() virtual
Hi Paul, dirtyBound() is something that can be called multiple times, but will only set a flag so is quite cheap. The computeBounds() will just be called on demand and therefore should only be called once per frame. computeBounds() is the place where I would stick my changes, its virtual for a good reason. Robert. On 7/3/07, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- Would you object strongly to making dirtyBound() a virtual function? In my custom node, I need to catch when the bounding box changes and make some modifications to the scene graph as a result. Currently, I'm overriding computeBounds() to do this. But because computeBounds() is const, I have to cast away const in order to perform non-const operations like modifying scene graph data. It turns out this doesn't work anyway, because thread collisions occur in multithread situations. Dirtying the bounding box seems to be an inherently non-const operation. Yet there doesn't appear to be a way for code to act on that change in a non-const way. Changing the declaration of dirtyBound() to virtual would allow custom Nodes to take non-const action on the bounding box change. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com 303 859 9466 ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/ ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Making Node::dirtyBound() virtual
dirtyBound() is something that can be called multiple times, but will only set a flag so is quite cheap. I see what you mean when you say dirtyBound() could be called multiple times per frame, so my idea of overriding it wouldn't produce a very efficient solution. The computeBounds() will just be called on demand and therefore should only be called once per frame. computeBounds() is the place where I would stick my changes, its virtual for a good reason. Okay, but because computeBounds() is const, I have to cast away const in order to perform operations on the scene graph within this function. Furthermore, when I do this, I see crashes in multidisplay environments, probably due to a thread collision caused by modifying the scene graph in one thread while another accesses the same part of the scene graph. Taking a look at CullVisitor, it's not clear to me how you ensure that computeBounds() is only called once per frame in multidisplay environments (where multiple cull traversals would be running concurrently). Can you explain how this is handled? -Paul ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
Re: [osg-users] Making Node::dirtyBound() virtual
Hi Paul, On 7/3/07, Paul Martz [EMAIL PROTECTED] wrote: Okay, but because computeBounds() is const, I have to cast away const in order to perform operations on the scene graph within this function. Casting away const'ness is should be see as advanced usage, some that most usage models won't require, but if you know what your are doing and that it won't break any threading then you'll be OK to just go ahead and cast away constness. Furthermore, when I do this, I see crashes in multidisplay environments, probably due to a thread collision caused by modifying the scene graph in one thread while another accesses the same part of the scene graph. Well you'll need to write the code so its thread safe... one way around this is to stick a viewer-getSceneData()-getBound() before the call to renderingTraversals(); Crude way of forcing a single threading computeBound() but effective. Taking a look at CullVisitor, it's not clear to me how you ensure that computeBounds() is only called once per frame in multidisplay environments (where multiple cull traversals would be running concurrently). Can you explain how this is handled? The computeBounds() themselves just compute a bounding volume they don't actually modify anything. The getBound itself does the modification of the cached bounding volume, and can do so virtual of the _boundingBox/_boundingSphere being mutable. The getBound does try to make the serialize the access to the bounding volume variable, rather it lets multiple threads go and do the compute and lets them all apply their values - they will all compute the same values anyway so there isn't any danger in this. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
RE: [osg-users] Making Node::dirtyBound() virtual
Understood. Very enlightening. Okay, back to the drawing board. I ought to be able to come up with a solution now that I have this info. Thanks. -Paul Hi Paul, On 7/3/07, Paul Martz [EMAIL PROTECTED] wrote: Okay, but because computeBounds() is const, I have to cast away const in order to perform operations on the scene graph within this function. Casting away const'ness is should be see as advanced usage, some that most usage models won't require, but if you know what your are doing and that it won't break any threading then you'll be OK to just go ahead and cast away constness. Furthermore, when I do this, I see crashes in multidisplay environments, probably due to a thread collision caused by modifying the scene graph in one thread while another accesses the same part of the scene graph. Well you'll need to write the code so its thread safe... one way around this is to stick a viewer-getSceneData()-getBound() before the call to renderingTraversals(); Crude way of forcing a single threading computeBound() but effective. Taking a look at CullVisitor, it's not clear to me how you ensure that computeBounds() is only called once per frame in multidisplay environments (where multiple cull traversals would be running concurrently). Can you explain how this is handled? The computeBounds() themselves just compute a bounding volume they don't actually modify anything. The getBound itself does the modification of the cached bounding volume, and can do so virtual of the _boundingBox/_boundingSphere being mutable. The getBound does try to make the serialize the access to the bounding volume variable, rather it lets multiple threads go and do the compute and lets them all apply their values - they will all compute the same values anyway so there isn't any danger in this. Robert. ___ osg-users mailing list osg-users@openscenegraph.net http://openscenegraph.net/mailman/listinfo/osg-users http://www.openscenegraph.org/
