Hi, I'm hoping someone can help - I'm calculating a scaling value in my cull traversal using the pixelSize() function. I then set my scaling matrix in the update traversal.
The problem with this is that the scale calculated is always one frame out when it get's applied - so there's a noticeable jerkiness on zooming in.
If I update my matrix in the cull traversal, zooming is smooth, however I understand that this is a dangerous thing to do.
On Tue, Oct 5, 2010 at 1:25 PM, paul graham <pd...@hotmail.com> wrote: > Hi, I'm hoping someone can help - I'm calculating a scaling value in my cull traversal using the pixelSize() function. I then set my scaling matrix in the update traversal.
> The problem with this is that the scale calculated is always one frame out when it get's applied - so there's a noticeable jerkiness on zooming in.
> If I update my matrix in the cull traversal, zooming is smooth, however I understand that this is a dangerous thing to do.
In general I would recommend users modify the scene graph outwith the cull and draw traversals as this ensures the most flexible and robustness w.r.t any threading and multi-context work that you may wish to do.
However, as long as your aware of the potential pitfalls it can be safe to modify the scene graph during cull, and it's also possible to compute data on the fly dynamically in cull and avoid any need to modify the scene graph.
In you case you are modify the scene graph in a way that at worst might lead to a matrix getting the wrong values if you have multiple cull traversals per frame, but it won't lead to a crashes as you aren't creating or destroying data or leading to any changes that might cause a serious threading issue.
If you do have multiple viewer cameras then you will have multiple cull traversals and multiple possible settings for your scaling and in this case you might want to consider one camera the dominate one, or multi-buffering the scaling, or doing the transform completely on the fly in cull.
> On Tue, Oct 5, 2010 at 1:25 PM, paul graham <pd...@hotmail.com> wrote: > > Hi, I'm hoping someone can help - I'm calculating a scaling value in my > cull traversal using the pixelSize() function. I then set my scaling matrix > in the update traversal.
> > The problem with this is that the scale calculated is always one frame > out when it get's applied - so there's a noticeable jerkiness on zooming > in.
> > If I update my matrix in the cull traversal, zooming is smooth, however I > understand that this is a dangerous thing to do.
> In general I would recommend users modify the scene graph outwith the > cull and draw traversals as this ensures the most flexible and > robustness w.r.t any threading and multi-context work that you may > wish to do.
> However, as long as your aware of the potential pitfalls it can be > safe to modify the scene graph during cull, and it's also possible to > compute data on the fly dynamically in cull and avoid any need to > modify the scene graph.
> In your cull traversal you can push a matrix on the ModelView stack,
traverse the subgraph, and then pop the matrix without modifying the scene graph at all. Take a look at osgUtil::CullVisitor::apply(Transform&) to see how this is done. You do need to be careful that the bounding volume of the node is set so that the node will be culled properly.
> In your cull traversal you can push a matrix on the ModelView stack, traverse > the subgraph, and then pop the matrix without modifying the scene graph at all. > Take a look at osgUtil::CullVisitor::apply(Transform&) to see how this is done. > You do need to be careful that the bounding volume of the node is set so that > the node will be culled properly.
This is the way to go.
Note that if you're using a custom node that derives from Transform, you can compute the necessary matrix inside the computeLocalToWorld() function, which gets called during cull to obtain the matrix. Thus each individual cull thread obtains its own matrix without ever modifying the scene graph.
