Hi Chris,
Rather than try and understand your approach it is probably best to say how
I'd tackle it.
First up I'd establish whether the hand API you are using generates
transforms for the finger joints relative to each each or relative to world
coordinates. If the matrices are relative then you'll want to mirror the
transform structure provided by the API with the scene graph with nested
Transfroms with the hand geometry elements placed under the appropriate
leaf Transform. If the matrices you get are relative to world coordinates
then use a flat group containing all the Transforms and then have the
individual bits of the geometry below the approach Transform.
Next up you'll want to pass your data from the hand API on each new frame
as part of the update traversal. There various ways you can do this:
1) Push the data to the scene graph in a single method that has a map
from the source matrix to the osg::MatrixTransform (or other transform
type) via an viewer Update Operation, or via a update NodeCallback attached
to the
root node of the hand.
2) Pull the data from the hand API via a series of update callbacks, each
attached to approach Transform.
Approach 2 is closest to your current method, the key difference is that
I'd create multiple callbacks each with set up with what matrix to pull
from the hand API, rather than have the callback work it out on the fly.
Using multiple callbacks will keep them simple and focus on the just the
task of pulling and applying the appropriate matrix. The memory cost of
the callbacks will be negligible - we are only talking about something like
32 matrices+ associated callback in total, pretty trivial.
If you are building the scene graph via C++ then I'd suggest you build the
scene graph structure and apply the callbacks with the appropriate wiring
as you build it rather than post process with a custom NodeVisitor.
If you are creating your scene graph in a modelling tool then you'll need
to using naming or scene graph structure to allow you to determine the
mapping. You current NodeVisitor uses this approach.
Setting the DataVariance on the Transform nodes will help tell the
osgUtil::Optimizer not to optimize away these Transforms as it does for
static Transform, but beyond this isn't used by the OSG. However, it is
still a good practice even if you don't use the osgUti::Optimizer.
And that's all there should be to it. If you are struggling to get things
working I would start simple such as controlling the whole hand with a
single matrix and steadily add the full implementation.
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
