unique-id madness in animations

Other Standards COLLADA
1

Hello,

I’m generating collada 1.4 animation from a simulator. I would like a single
collada file to hold several animations of the whole scene, as shown in the
example.

http://gist.github.com/610049#file_anim … rarchy.dae

The task of combining animations is made harder by the requirement to set
unique ids for source, sample, and arrays elements. Moreover, I can’t see the
reason for this requirement. Why could I not use scoped id?

I would like to know if there is a workaround and the rationale for this limitaition.

Any id[ea]?

2

Use an animation clip to group the animations together?

Sharable elements in the COLLADA schema have id attributes so that they can be referenced from other documents via URL (with fragment). The constraint that id values must be unique within the instance document comes from XML.

3

Hi Marcus,

first of all, thank you for your answer, I really appreciate the time you spend here.

Regarding the question, I’ll try to be more specific.

In of the following example


<animation id="anim0">
<animation>
	<source id="anim0-frame0-translate-input">
		<float_array count="5" id="anim0-frame0-translate-input-array">0 1 2 3 4</float_array>
		<technique_common>
			<accessor count="5" source="#anim0-frame0-translate-input-array" stride="1">
				<param name="TIME" type="float"/>
			</accessor>
		</technique_common>
	</source>
	<source id="anim0-frame0-translate-interpolation">
		<Name_array count="15" id="anim0-frame0-translate-interpolation-array">STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP </Name_array>
		<technique_common>
			<accessor count="5" source="#anim0-frame0-translate-interpolation-array" stride="3">
				<param name="X" type="Name"/>
				<param name="Y" type="Name"/>
				<param name="Z" type="Name"/>
			</accessor>
		</technique_common>
	</source>
	<source id="anim0-frame0-translate-output">
		<float_array count="15" id="anim0-frame0-translate-output-array"> 0 0 0 0 1 0 0 2 0 0 3 0 0 4 0</float_array>
		<technique_common>
			<accessor count="5" source="#anim0-frame0-translate-output-array" stride="3">
				<param name="X" type="float"/>
				<param name="Y" type="float"/>
				<param name="Z" type="float"/>
			</accessor>
		</technique_common>
	</source>
	<sampler id="anim0-frame0-translate-sampler">
		<input semantic="INPUT" source="#anim0-frame0-translate-input"/>
		<input semantic="OUTPUT" source="#anim0-frame0-translate-output"/>
		<input semantic="INTERPOLATION" source="#anim0-frame0-translate-interpolation"/>
	</sampler>
	<channel source="#anim0-frame0-translate-sampler" target="frame0/translate"/>
</animation>
</animation>



You see that all the id use the same prefix. When several animations are combined in a single file, there might be id collisions.
When this occurs, the id prefix needs to be updated everywhere.

I would have preferred something in this spirit
0 1 2 3 4 STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP STEP 0 0 0 0 1 0 0 2 0 0 3 0 0 4 0 


With this example, fixing an id collision involves changing a single id.


[quote="marcus"]
Use an animation clip to group the animations together?

[/quote]


I never used animation clips. But I think I would still have to manipulate global ids and ensure they are unique within the whole document. Isn't it?


[quote="marcus"]

Sharable elements in the COLLADA schema have id attributes so that they can be referenced from other documents via URL (with fragment).
The constraint that id values must be unique within the instance document comes from XML.
[/quote]

[/quote]

Ok. I just understood that fragments don't work with sid. Still, I'm curious about the concrete use case for this (referencing sources, arrays and samplers from other documents).
Don't you think target-like addressing would have been more appropriate?

(I eventually ordered the collada book, maybe this is discussed in the "design choices" section.)

Cheers
4

Thanks and you’re welcome :slight_smile:

COLLADA design encourages modular content. Notice that the top level document schema is just asset, libraries, and a default scene. With documents as the primary division, the ID attribute usage is needed. That is how the animation design grew out because we know that animation key frame data are quite often the largest blocks of data and so separation of that is encouraged (as with each of the library element types).

As with other parts of the schema, it’s certainly possible to allow both ID and SID attributes on elements to enable more flexibility in content structure. Adding that to data sources and animations would be an enhancement request against the schema and specification.

5

ok.

Thank you again for these explanations

– Sebastian