collada kinematics 1.5 test files

[rdiankov]

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>

[rdiankov]

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,

[marcus]

@rdiankov

After re-reading the collada spec, it seems that we might have misunderstood param (reference). So it resolves as a regular SIDREF? If that’s the case, why does <bind> have both

<param> and <SIDREF> tags?

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”.

[marcus]

@rdiankov

By the way, we’re using collada-dom, and I’ve posted several bug reports about its SID referencing implementation…

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.

@rdiankov

Anyway, in the daeSidRef::resolve() method, there is this comment:
<code>
// Try to resolve as an effect-style sid ref by prepending “./” to the sid ref.
// If that fails, try resolving as an animation-style sid ref, where the first part is an ID.
result = resolveImpl(daeSidRef(string(“./”) + sidRef, refElt, profile));
if (!result.elt)
result = resolveImpl(*this);
</code>

Which implicitly first tests “./” before trying to resolve an ID. Are you saying that this is wrong?

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.

[marcus]

@rdiankov

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.

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 (“./”).

@rdiankov

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:

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.

[rdiankov]

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.

[marcus]

@rdiankov

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

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.

@rdiankov

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

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).

@rdiankov

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.

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.