collada kinematics 1.5 test files

There is another question regarding SID referencing. What if we have:


<dummy id="a">
  <dummy sid="b">
    <dummy sid="c">
    </dummy>
  </dummy>
</dummy>

Then is it possible to reference ‘c’ using ref=“a/c”? Or will it never resolve if “b” is in the middle.

The reason I ask is because on one of the examples given, the “param.kinematicsmodel.obj.kinmodel.0” SID is referenced without the entire path:


	<library_kinematics_scenes id="libkinscenes">
		<kinematics_scene id="libkinscenes.kinScene">
			<instance_articulated_system url="#obj.kinematicssystem.1" sid="inst_kinsystem.0">
				<newparam sid="libkinscenes.kinScene_libkinscenes.kinScene_inst_kinmodel.0">
					<SIDREF>param.kinematicsmodel.obj.kinmodel.0</SIDREF>
				</newparam>

...

	<library_articulated_systems>
		<articulated_system id="obj.kinematicssystem.1">
			<kinematics>
				<instance_kinematics_model url="#kinmodel.0" sid="inst_obj.kinmodel.0">
					<newparam sid="param.kinematicsmodel.obj.kinmodel.0">
						<SIDREF>obj.kinematicssystem.1/inst_obj.kinmodel.0</SIDREF>
					</newparam>

hi marcus,

We updated the models and exporter again, please confirm that there are no more problems with these files:

http://openrave.programmingvision.com/i … ollada.tgz

http://openrave.programmingvision.com/i … ollada.tgz

thank you,

A <param> references a <newparam> specifically while a <SIDREF> can refer to anything with an sid attribute.

… because the designers of this part of the spec wanted maximum flexibility to match the configurations of real-world factory robots and other kinematic systems (i.e. video games). I agree it’s a bit redundant but also it’s intended to be “future proof”.

The collada-dom project is inactive. If you want developer access to fix bugs you are finding there let me know and I can provide that for you.

Strictly speaking yes. The dom has code to work around dialects of effect content, exported by early tools, that failed to export full sid reference syntax. The first part of an sid reference is always supposed to start with an id or “.”, as per the spec.

Yes. Sid references can have sparse paths. In your example “a/b/c” and “a/c” are both valid and resolve unambiguously to the same element. Sid resolution is a breadth-first traversal starting either at the id or the parent element scope ("./").

That looks like an error in export to me.

Also, because of the location of elements, use of an <SIDREF> and <param ref="""> necessitates use of the full sid reference syntax starting with an id value, since the parent element scope is effectively empty.

I think this probably needs to be addressed by a spec note since I’m seeing examples that are abusing the notion of parent scope ("./") to include grand-parent scopes as well. E.g. content is expecting software to keep expanding the search scope upward and outward looking for the sid in question.

Hi marcus, thanks for the replies.

Yes, I would like collada-dom developer access to fix bugs (sourceforge id is rdiankov). What is the testing process of putting in fixes?

What COLLADA library would you recommend to use now if not collada-dom?

Also, because of the location of elements, use of an <SIDREF> and <param ref="""> necessitates use of the full sid reference syntax starting with an id value, since the parent element scope is effectively empty.

I think this probably needs to be addressed by a spec note since I’m seeing examples that are abusing the notion of parent scope ("./") to include grand-parent scopes as well. E.g. content is expecting software to keep expanding the search scope upward and outward looking for the sid in question.

All the examples you have sent thus far abuse this, which has lead to a lot of confusion. If you can re-send good clean examples, then we can at least guarantee that the exporters follow them, with the readers prioritizing the correct syntax over hacks.

Granted. Most of the DOM code is generated from the schema by a script. There are hand written utilities and patches (like the sid resolver) that are supposed to follow the specification.

OpenCOLLADA is maintained by the folks at Netallied who helped design the 1.5 specification, so it supports 1.5 pretty well and I believe that they are working towards conformance (1.4 first then 1.5).

Huh, I haven’t sent examples, just been looking at your uploads with the spec in mind. Sorry I don’t have 1.5 documents that I can share.