Hi Janna,
On 8 March 2013 15:32, Janna Terde <[email protected]> wrote:
> Thank you for the quick reply!
>
> What I am trying to do is to modify the scene graph (for example modify the
> transformation matrix of the node or uniform of the node).
> I've tried doing it in the cull callback or camera pre draw callback but it
> seems at this point it is already too late.
>
> For example, I have a scene graph with the node in it. I would like to modify
> the transformation matrix of that node and this transformation matrix needs
> to be computed based on the camera, per view.
>
> I've tried to use cull callback or camera pre-draw callback to compute
> transformation matrix and set it for the node. It seems that at this point
> when I set transformation for the node in the cull callback of the first
> camera it will actually affect the second view (second camera). As if I would
> be setting it in a post-draw callback.
> Also not sure how thread-safe is that.
With a transform that is dynamically changing it's state there will be
threading issues, it might not be an issue about the application
crashing, rather just that objects can end up in the wrong place
because different threads are all contending for control over the same
data.
A custom osg::Transform could avoid this issue by not storing any
state locally but simply computing the matrix on the fly. When
creating your MyTransform class you'd need to override the following
Transform methods:
virtual bool computeLocalToWorldMatrix(Matrix&
matrix,NodeVisitor*) const;
virtual bool computeWorldToLocalMatrix(Matrix&
matrix,NodeVisitor*) const;
Have a look at how the other Transform subclasses manage these methods
to see it's done - look at osg::MatrixTransform,
osg::PositionAttitudeTransform and osg::AutoTransform. The matrix in
the above method is the modelview matrix that you'll need to modify
and the NodeVisitor* will be the visitor that is calling the compute
method, a dynamic_cast<osgUtil::CullVisitor*> will allow you to get
access to the CullVisitor's state. Using this approach you can
dynamically compute the required modelview matrix and avoid any
threading issue.
The only part that will need some kind of state setting would be for
the bounding volume of the MyTransform class as it's position/size in
space will be moving around so you'll need to decide whether to simply
disable culling for this node and not set the bounding volume, or
compute a bounding volume that will encompass all the possible
positions/sizes to prevent it from being culled prematurely.
Robert.
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
