we’re start to experiment with referencing of collada resources, and run into a huge problem when trying to bind <instance_rigid_body> to a target node
basically our visual node structure has two bodies. One is defined completely and the other is an instance that points to a previously defined node, but changes the position.
we have no idea what to put in the ??? place that uniquely identifies the visual hierarchy of the second body.
EDIT: This is a very simplified case. In our use case, we have entire human avatars whose visual hierarchy we want to instantiate. But because <instance_rigid_body> needs to target unique <node> elements of the visual hierarchy, we have no idea how to target the instantiated nodes deep in the human hierarchy.
please advise since this is an issue we can’t easily get around.
Per discussion with the WG, the way to overcome the fact that a instance node have no id, is to encapsulate it in a regular node (as a parent node).
Then you can access your instance node through its parent.
So you should not create an extra.
If we have an instance_node point to “visual1”, then “v1.node1” will get copied inside the new instance right? What happens to its “id”?" Now there will be two nodes with “v1.node1”
It is valid to use node elements not only for structuring but also to create addressable entry points. And that what the node is, because it has no transformations or a name.
sorry, i don’t think your solution addresses all the concerns.
some of our hierarchies are 30 levels deep. in order for us to reference a node whose id is 30 levels deep, according to you, we will have to recreate the entire hierarchy with <node> in order to change the id of that node to make it unique. if we have to recreate the hierarchy, wouldn’t this defeat the purpose of instance_node?
We had the same problems of understanding when creating the kinematics part. The only answer is that COLLADA is not an engine for kinematics or physics. COLLADA cannot not decide by resolving an instance_node what happens to inner ids. This is work for a tool. And a tool can decide by looking at hierarchical dependencies for example.
To your example:
The id remains the same. Perhaps in physics model we need to address nodes by sid path and not by an url in the future.
i see. if others share similar problems, then i think the collada spec needs revisions to provide a mechanism for IDs inside instantiated elements to be prefixed/suffixed.