Khronos Public Bugzilla
Bug 218 - bind_kinematics_model is too weak
Summary: bind_kinematics_model is too weak
Status: NEW
Alias: None
Product: COLLADA
Classification: Unclassified
Component: Schema (show other bugs)
Version: 1.5.0
Hardware: PC Linux
: P3 normal
Target Milestone: ---
Assignee: Fabrice Robinet
QA Contact: COLLADA Work Group email alias
Depends on:
Reported: 2009-10-08 12:10 PDT by Marty Vona
Modified: 2014-01-07 10:23 PST (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Marty Vona 2009-10-08 12:10:11 PDT
My best interpretation of the current 1.5 kinematics spec is that

1) bind_kinematics_model can be considered to embed (in the mathematical sense of embedding within a metric space) a particular kinematics model graph instance into the coordinate frame of a particular node in a particular visual scene instance (I am reading between the lines, because the current text of the spec for bind_kinematics_model says only "for calculation the position is important")

2) bind_joint_axis can be considered to define an equality relationship whereby the state of a particular visual scene node subtransform instance is bound to the state of a particular joint axis instance

and I see no further way to specify any other relationships between the kinematics model and the visual scene.

In particular, it does not appear possible to unambiguously specify that particular visual scene node instances correspond in any way to particular kinematics model link instances.  One might hope that such a node-to-link correspondence could be inferred at least in the case that the visual scene node tree topology has a one-to-one correspondence with the kinematics model link tree topology.  But such inference is not unambiguous in general for two reasons: (1) even if the two trees are topologically isomorphic, there may be more than one matching (this can even be true if the spatial embedding of the trees in their initial poses are also matchable, i.e. if they are geometrically in addition to topologically isomorphic); and (2) even if there is only one topological matching, it may be invalidated by bind_joint_axis, which can easily be used to bind kinematic joint axes to subtransforms in visual scene nodes other than the node implied by the topological matching.

Further, it is entirely possible to use bind_joint_axis to connect more than one visual scene node subtransform to a single kinematic joint axis (this is demonstrated in the OWL example "simple.dae").  (It also seems possible to bind_joint_axis a single node subtransform to multiple joint axes, or to bind different axes of a single joint to subtransforms of different nodes...)

If it is indeed impossible to unambiguously establish a correspondence between visual scene nodes and kinematic links, then the whole kinematics system in collada 1.5 would seem to be of very limited utility.  I understand that a kinematics model can be useful even without any connection to a visual scene.  But if you do want such a connection, the current bind_kinematics_model doesn't help very much.

Yes, a set of bind_joint_axis does establish a relationship such that the pose of the bound node subtransforms could be driven from the pose of the kinematics model (and even vice-versa).  But that does not mean that the two topological models necessarily have the same metric embedding, i.e., even if all bind_joint_axis equality relationships are respected, the spatial poses of the node coordinate frames in the visual model do not have to have any particular relationship to the spatial poses of the links in the kinematic model.  This makes it impossible in general to infer anything about the effect on the kinematics model of any change in the pose of the visual model other than direct modification of specifically bound subtransforms.

For example, it does not seem possible to implment click-and-drag inverse kinematics, where the user clicks and drags the geometry attached to a visual node, and the kinematics model is (a) correspondingly updated and (b) constrains the motion of the visual model.

In fact, in its current form, it is hard to understand what purpose the metric embedding (which I infer given the near nonexistent documentation) of bind_kinematics_model could serve.  Such an embedding could be construed to give a correspondence between the coordinate frame of the bound visual node and e.g. the root link of the bound kinematics model, but the above issues still make it impossible in general to unambiguously correspond any other visual node to any other kinematics link.