Results 1 to 8 of 8

Thread: A few questions about <input> and sets

  1. #1
    parmus
    Guest

    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:

    Code :
    <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 <vertices>, but is this correct?

    Second question: Inputs defined in the geometry specification can be grouped into "sets", while inputs in <vertices> can not. So are inputs in <vertices> 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:
    Code :
    <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

  2. #2
    Junior Member
    Join Date
    Mar 2005
    Location
    Netherlands
    Posts
    8

    Re: A few questions about <input> and sets

    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
    Gino van den Bergen
    www.dtecta.com

  3. #3
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: A few questions about <input> and sets

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

  4. #4
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: A few questions about <input> and sets

    Quote Originally Posted by gino
    Two years gone and no satisfactory answer.
    It's been answered many times in other posts but anyway thanks for bringing it to the top again.
    Quote Originally Posted by gino
    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.).
    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.
    Quote Originally Posted by gino
    Now, we have to repeat the same <input> blocks if multiple primitive sets are used.
    You would have to anyway because the attribute sets generally depend on the primitive to begin with.
    Quote Originally Posted by gino
    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?
    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.

  5. #5
    Junior Member
    Join Date
    Mar 2005
    Location
    Netherlands
    Posts
    8

    Re: A few questions about <input> and sets

    Quote Originally Posted by marcus
    Quote Originally Posted by gino
    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.).
    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.
    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:
    Code :
    <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"/>
    Gino van den Bergen
    www.dtecta.com

  6. #6
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: A few questions about <input> and sets

    You're welcome.

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

  7. #7
    Junior Member
    Join Date
    Jun 2011
    Posts
    7

    Re: A few questions about <input> and sets

    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.

  8. #8
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: A few questions about <input> and sets

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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •