Hi Kristofer, I've looked at the current implementation and had a think about your thoughts and original proposed fix, but as yet have no clear idea on the best solution.
The existing implementation has a flaw in that it won't capture the updates to any transforms above it in the scene graph if they are done after the update callback is called, potentially one could end up with a setting that is one frame out if the parents transforms are modified after the AntiSquish node is updated. 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. 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. Perhaps if the update mechanism is made configurable one could disable the default and set up a callback oneself. One disadvantage of the automatic updates in update or cull is that potentially it could be out of sync for different traversals, so if did an intersection traversal it could end up using a different transform value than cull traversal. The Dragger callback approach would potentially avoid this, but on the first frame it could still end up out. Robert. On 8 January 2014 07:55, Kristofer Tingdahl <[email protected]>wrote: > Dear Robert, > > Thanks for the input! There are multiple routes ahead: > > > 1. Assuming that the scaling is isotropic above the dragger, all > squishing comes from the dragger itself. One could then make the AntiSquish > aware of the Dragger and attach itself to the draggers change-callback. The > re-calculation of the squish would only occur when the dragger changed its > shape. One problem may be that the dragger may change through setMatrix(), > and there will be no callback. One possible solution would be to change the > MatrixTransform in such a way that it uses a dirty-count rather than the > _inverseDirty boolean. The AntiSquish could then check the getDirtyCount() > of the dragger, and adapt if need be. > 2. One could compute the squish every time, and only apply it to the > node-visitor/state, hence not change the object itself (which would then > inherit osg::Group rather than MatrixTransform). The problem (may) be in > caching, as for the majority of the times, there will be no re-calculation > needed. On the contrary, there will not be 100k draggers in the scene, so > perhaps no one cares. > > Do you have any preferences among these routes, or do you see a better one? > > _______________________________________________ > osg-submissions mailing list > [email protected] > > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > >
_______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
