what happens to id's for instantiated nodes?

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.


<node id="visual1" name="mug1" sid="visual1">
  <translate sid="translate">1 0 0</translate>
  <rotate sid="rotate">1 0 0 89.99999999999999</rotate>
  <node id="v1.node0" sid="node0">
	<translate>0 0 0</translate>
	<rotate>1 0 0 0</rotate>
	<instance_geometry url="#g1_link0_geom0">
	  <bind_material>
		<technique_common>
		  <instance_material symbol="mat0" target="#g1_link0_geom0_mat"/>
		</technique_common>
	  </bind_material>
	</instance_geometry>
         <node id="v1.node1" sid="node1"/>
  </node>
</node>
<node id="visual2" name="mug2" sid="visual2">
  <translate sid="translate">0 1 0</translate>
  <rotate sid="rotate">1 0 0 89.99999999999999</rotate>
  <instance_node url="#v1.node0" sid="node0"/>
</node>

everything is fine up until we need to uniquely reference the nodes in the second body, which is necessary for physics:


<instance_physics_model url="#pmodel1" sid="pmodel1_inst" parent="#visual1">
  <instance_rigid_body body="rigid0" sid="rigid0" target="#v1.node0"/>
</instance_physics_model>
<instance_physics_model url="#pmodel2" sid="pmodel2_inst" parent="#visual2">
  <instance_rigid_body body="rigid0" sid="rigid0" target="???????????"/>
</instance_physics_model>

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.

thank you,

for now i’ll be using <extra> tags to define a suffix for all the ids:


  <node name="body1">
    <translate>1 0 0</translate>
    <instance_node url="#somenode">
      <extra type="idsuffix" name=".b1"/>
    </instance_node>
  </node>
  <node name="body2">
    <translate>1 0 0</translate>
    <instance_node url="#somenode">
      <extra type="idsuffix" name=".b2"/>
    </instance_node>
  </node>

it’s not part of the spec, but it looks like there are no other options…

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.

My example was perhaps too simplified, so I apologize for that. My question was, how are nodes inside the instantiated hierarchy instanced?

In the example above we have:


<node id="visual1" name="mug1" sid="visual1">
  <node id="v1.node1" sid="node1"/>
  </node>
</node>

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”

Hi,

In my opinion you don’t need extra information. You can just place a node with an id around your instance_node.


<node id="visual1" name="mug1" sid="visual1">
  <translate sid="translate">1 0 0</translate>
  <rotate sid="rotate">1 0 0 89.99999999999999</rotate>
  <node id="v1.node0" sid="node0">
   <translate>0 0 0</translate>
   <rotate>1 0 0 0</rotate>
   <instance_geometry url="#g1_link0_geom0">
     <bind_material>
      <technique_common>
        <instance_material symbol="mat0" target="#g1_link0_geom0_mat"/>
      </technique_common>
     </bind_material>
   </instance_geometry>
         <node id="v1.node1" sid="node1"/>
  </node>
</node>
<node id="visual2" name="mug2" sid="visual2">
  <translate sid="translate">0 1 0</translate>
  <rotate sid="rotate">1 0 0 89.99999999999999</rotate>
  <node id="v2.node0">
    <instance_node url="#v1.node0" sid="node0"/>
  </node>
</node>

And then:


<instance_physics_model url="#pmodel1" sid="pmodel1_inst" parent="#visual1">
  <instance_rigid_body body="rigid0" sid="rigid0" target="#v1.node0"/>
</instance_physics_model>
<instance_physics_model url="#pmodel2" sid="pmodel2_inst" parent="#visual2">
  <instance_rigid_body body="rigid0" sid="rigid0" target=#v2.node0"/>
</instance_physics_model>

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.

Regards

Steffen

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?

To your second question:

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.

Regards

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.

in either case, i’ve written down the “idsuffix” extra tag usage in our custom robotics profile here:

http://openrave.org/docs/latest_stable/ … xtensions/