Sampler and Inputs question

Hi,

I am currently evaluating Collada for our internal animation asset database format.

I’ve come across an issue with the input vs InputLocal tag specification.
Following the Collada specification 1.4.1, a sampler should have a number of input children. From the spec examples:
<sampler id=“group1_translate-anim-samplerY”>
<input semantic=“INPUT” source="#group1_translate-anim-inputY"/>
<input semantic=“OUTPUT” source="#group1_translate-anim-outputY"/>
<input semantic=“IN_TANGENT” source="#group1_translate-anim-intanY"/>
<input semantic=“OUT_TANGENT” source="#group1_translate-anim-outtanY"/>
<input semantic=“INTERPOLATION” source="#group1_translate-anim-interpY"/>
</sampler>

But if I want to use the clean:


domSampler* oSampler = (domSampler*)curAnim->createAndPlace(COLLADA_ELEMENT_SAMPLER);
domInputLocal* oInputInput = (domInputLocal*)oSampler->createAndPlace(COLLADA_ELEMENT_INPUTLOCAL);

oInputInput is NULL just after creation.

To make it work I have to use:


domInputLocal* oInputInput = (domInputLocal*)oSampler->createAndPlace("input");

This is not a big problem, but I thought that using constants instead of strings would make my code easier to read and less error-prone.

And I didn’t find any reference to InputLocal in the 1.4.1 specification document…

If anyone could shed some light on this (small) mystery…

Thank you!

Aloys


Character Software TD
Animal Logic

Eww Hungarian notation, run! Ha I kid :lol:

Take a look at this thread.

Thanks Thomas!

I know, those o in from of my objects are so boring… :?

This thread explains the absence of COLLADA_ELEMENT_INPUT.
But it doesn’t explain why I have to create a domInputLocal and not a domInput…
Is the existence of the local inputs a legacy thing or is it hidden somewhere in the specification?

Cheers,

Aloys

The InputLocal and InputLocalOffset are found in the schema. The heart of Collada is a W3C schema that defines what a Collada document is. The specification document can be viewed as an easily-digestible form of the schema, with some extra explanatory documentation thrown in. In fact I think the bulk of the specification is auto-generated from the schema, but I might be wrong about that.

In the schema you have an InputLocal, InputLocalOffset, and InputGlobal types. Each type allows for slightly different contents and attributes, which is why they’re distinct types. For example InputLocalOffset has an offset attribute, but the other two input types don’t. Whenever these types are used in the schema they’re assigned the name “input”, just to make things simpler I assume. In the Collada document you see the name of the element (“input”) but the actual type of the element is one of InputLocal, InputLocalOffset, or InputGlobal, depending on where it’s located.

So, to answer your question, the reason you have a domInputLocal class instead of a domInput class is because each of the three input types have different contents and attributes so they need to map to three distinct C++ classes.

But that doesn’t really answer why there is no string constant for “input” in domConstants.h.

It makes more sense now.
I’m used to look at .h files to get the most up-to-date documentation, and I will do the same for .xsd files from now on.
Anyhow, the documentation should reflect that.

Thanks again!

Aloys