A few questions about <input> and sets

Dear collective knowledge base of the forum

I have a few clarifying questions about Collada. As so many before me I’m struggling with the interpretation of the input-source-semantic-set part.

From the specs I know that there is two different kinds of <input>, one kind in the geometry specification (e.g. in <polylist>, <lines>, etc.) and one kind in the indirection <vertices>. Each kind can use the same semantics with two exceptions: POSITION can only be used in <vertices> and VERTEX can only be used in the geometry specification.

First question: which <input> takes precedence if the specific semantic exists in both <vertices> and in the geometry specification? The following example illustrates the problem with the NORMAL semantic:

 
<mesh> 
  <vertices id="vertices"> 
    <input semantic="POSITION" source="#....."/> 
    <input semantic="NORMAL" source="#....."/> 
  </vertices> 
  <polylist> 
    <input offset="0" semantic="VERTEX" source="#vertices"/> 
    <input offset="1" semantic="NORMAL" source="#...."> 
    <vcount>....</vcount> 
    

...</p> 
  </polylist> 
</mesh> 

Personally I would assume that the NORMALs from the geometry specification overrides the NORMALs from the , but is this correct?

Second question: Inputs defined in the geometry specification can be grouped into “sets”, while inputs in can not. So are inputs in implicitly in the first set? And if so, what is the first set? Set 0 or set 1? Or maybe it’s added to all sets, where it isn’t overridden by inputs in the geometry specification?
The following example illustrates the problem:

 
<mesh> 
  <vertices id="vertices"> 
    <input semantic="POSITION" source="#....."/> 
    <input semantic="NORMAL" source="#....."/> 
  </vertices> 
  <polylist> 
    <input offset="0" semantic="VERTEX" source="#vertices"/> 
    <input offset="1" semantic="TEXCOORD" source="#...." set="0"/> 
    <input offset="1" semantic="TEXCOORD" source="#...." set="1"/> 
    <input offset="2" semantic="NORMAL" source="#...." set="1"/> 
    <vcount>....</vcount> 
    

...</p> 
  </polylist> 
</mesh> 

Third question: for which sematics does the grouping in sets make sense? I assume it’s meaningless to have several sets of VERTEXs.

I hope you can help me with these questions. Thanks in advance.

EDIT: Changed title to avoid cut-off

Two years gone and no satisfactory answer.

Personally, I think that not having an “offset” and “set” attribute in <input> inside a <vertices> block is a missed opportunity. Commonly only a “POSITION” semantic is placed in the <vertices> block. Many tools ignore any other semantic in the <vertices> block, so apparently <vertices> was never meant to refer to anything other than “POSITION”, which kind of makes it unnecessary syntactic decoration. There would be proper use for it if only we could use the same <input> structures as in primitive sets (<triangles>, <tristrips>, etc.).
Now, we have to repeat the same <input> blocks if multiple primitive sets are used. What’s worse: How should a COLLADA loader handle multiple primitive sets that use different sources for the same “semantic” and “set” in the same mesh? In many graphics engines this would not be representable in a single mesh. The current suggested method of each primitive set having its own <input>-s seems unnecessary complex to me. Allowing <input> with an “offset” and “set” attribute in <vertices> would have made it cleaner for sure.

Gino

(0) POSITION can be used in either place, however it must be used in the <vertices> element.

(1) There is no precedence, all inputs apply. The distinction is between vertex attributes that are invariant to tessellation (i.e. from <vertices>) and those that depend on it (e.g. from <triangles>). The reason that <vertices> input elements do not have a set attribute is because it was thought that mesh vertex attributes would not form subsets. It’s probable that this limitation will be removed the next rev of the schemas.

(2) Inputs that don’t specify a set attribute can be bound together into an unnamed set distinct from other sets. The choice of values for the set attribute are up to the author of the content.

(3) The set attribute groups together values so that they can be passed coherently to shaders using the <bind_vertex_input> element. Any case where you have multiple sets of values for the same semantic you should use the set attribute to differentiate between them. E.g. you might have one each of (POSITION, NORMAL) and then two sets each of (TEXCOORD, TEXTANGENT). Since there is only one <vertices> element it cannot meaningfully participate in subsets.

It’s been answered many times in other posts but anyway thanks for bringing it to the top again.

It’s been talked about and the use-cases are now there to show that it would indeed make sense to allow sub-setting of mesh vertex attributes as is done with geometric primitive vertex attributes.

Tools that ignore inputs within the <vertices> element are broken and fail to support mesh vertex attributes fully.

You would have to anyway because the attribute sets generally depend on the primitive to begin with.

There’s nothing wrong or worse about it. All inputs are used at all times. There is no case of precedence or overriding of input semantics in the specification. The purpose of the offset attribute is to order the input elements as they are otherwise order independent. The purpose of the set attribute is to group coherent inputs together (as I said in my previous post).

Using these attributes correctly, enables authors to represent multi-resolution meshes with unbounded vertex attributes organized by geometric primitives.

If a document contains multiple inputs with the same semantic and set attribute valuess in the same scope, then that content is ambiguous and incoherent. That would be an error in the content.

Thanks for the clear answer and for shedding some light on what’s to come. The “set” attribute in unshared (<vertices>) inputs would certainly make sense. I see now that an “offset” in an unshared input makes no sense at all unless you can have multiple “VERTEX” semantics in the shared inputs of the primitive sets with matching offsets.

Do I understand it correctly that a shared input that has no “set” attribute should be treated different from an input that has set=“0”? So in theory you could have:


<input semantic="TEXCOORD" source="#texCoords1" offset="0"/>
<input semantic="TEXCOORD" source="#texCoords2" offset="0" set="0"/>
<input semantic="TEXCOORD" source="#texCoords3" offset="0" set="1"/>

You’re welcome.

Yes that’s correct interpretation of absence/presence of the set attribute.

Do I understand it correctly that a shared input that has no “set” attribute should be treated different from an input that has set=“0”? So in theory you could have:

I had the biggest problem this for a while assuming that no set was set to zero. Its funny how a small piece of information like this can help move your knowledge forward in a big way.

Right! The empty set is not the same (set) as the set that contains “0”… or “1”… or “42”.