Hi Kristofer,
On 8 January 2014 11:50, Kristofer Tingdahl <[email protected]>wrote: > Dear Robert: > >> >> >> I see that your implementation overrides accept() rather than the usual >> traverse() to avoid a similar issue. Rather that use the ModelViewMatrix() >> I believe the code should instead use the same as the orignal callback - >> calling computeLocalToWorld() on the NodePath obtained from the >> NodeVisitor. Such a change would make it possible to apply the update in a >> configurable way, so the user could set whether they want it to be updated >> in the update, event or cull traversals. >> > > I have no problems with doing it the original way, the reason I did not > comment on it in my original reply was that I saw the updates and traversal > hookups as the real issue. > > >> >> Updating using dragger callbacks would just handle the dragger updates, >> if one is doing this then the application developer would need to wire up >> the callback themselves as the AntiSquish node itself doesn't now anything >> about the rest of the scene graph or manipulators. >> > > I agree that dragger callbacks won't do. What is needed (in my view) is a > cheap way of determining if there is a recalculation needed at all. Having > a dirty-count on the Transforms (or MatrixTransforms) would be an option, > as one could traverse the node-path and get a count of all the dirty-counts > along the way, and see if anything has changed. > > One could then implement this cheaply on all traversals, and then only > update the state/node, not the object itself. > > But for that, I need to change the MatrixTransform to have a dirty-count, > and that is affecting one of the most basic classes of OSG, so I want some > level of approval before investing in a solution based on that. > A dirty count on a MatrixTransform, would probably need to be done on the Transform base class. I'm not sure that it's really essential as your are the first person to request it since the inception of the OSG. There would be other uses of such a dirty count but again don't think the gain from having it warrants changing a core API and all subclasses from it to keep it in sync. The cost of accumulating the transforms along a NodePath won't be high so I'd be inclined to simply do it on every new frame. If the costs doesn't turn out to be prohibitively high then I think we'd need to look at alternatives like uses a dirty count or other update mechanism. Robert.
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
