Page 1 of 3 123 LastLast
Results 1 to 10 of 28

Thread: Mesh's <vertices> and primitives relationship clarification

  1. #1

    Post Mesh's <vertices> and primitives relationship clarification

    Sorry I guess this thread will be duplicated of some other but I tried to search and coulnd't find or I can't use the forum's search correctly (I dont like it) :/

    <mesh> element has <vertices> and mesh primitives e.g <polylist> 's least one input must specify semantic="VERTEX" (according to specs 1.5)
    I think POSITIONS could be located inside <polylist> directly but okay, it is not my confusion:

    https://www.khronos.org/collada/publ...1/msg00014.php

    According to specs <mesh> can contains multiple of primitives:

    Geometric primitives, which assemble values from the inputs into vertex attribute data. Can be any combination of the following in any order: <lines> <linestrips> <polygons> <polylist> <triangles> <trifans> <tristrips>
    Only one <vertices> element is allowed inside <mesh> and primitives' input's souce (semantic="VERTEX") is id of <vertices> element.
    So, How can multiple primitives have different <vertices>, different positions, accessors... then? If <mesh> has only one primitive e.g. <polylist> it is ok, but what about multiple primitives

    1.5 XSD also says:
    The mesh element must contain one vertices element.
    Maybe single source can contains all positions of all primitives with different offsets but to get an offset we need to access different accessors, am I wrong? What to do?

  2. #2
    There is a statement inside PDF 1.5:

    In a situation where you want to share index data, that is, to optimize the index data, and still have distinct set attributes, you can move the <input> element from the <vertices> element into the primitive element(s) and reuse the offset attribute value of the input with VERTEX semantic:

    <vertices>
    <input semantic="POSITION"/>
    <input semantic="TEXCOORD"/>
    <input semantic="NORMAL"/>
    </vertices>
    <polygons>
    <input semantic="VERTEX" offset="0"/>
    ...

    <vertices>
    <input semantic="POSITION"/>
    </vertices>
    <polygons>
    <input semantic="VERTEX" offset="0"/>
    <input semantic="TEXCOORD" offset="0" set="1"/>
    <input semantic="NORMAL" offset="0" set="4"/>
    ...
    So we can move some inputs from <vertex> to primitives' scope, then can we move POSITION too? it would solve my problem,
    then we could leave <vertices></vertices> empty and move all POSITIONS to different primitives like :

    <polygons>
    <input semantic="VERTEX" offset="0"/> <!-- just for keep spec implementation valid -->
    <input semantic="POSITIONS" offset="0" />
    <input semantic="NORMAL" offset="1"" />
    <input semantic="TEXCOORD" offset="2" />

    Would this be valid?

  3. #3
    Spec says:
    Mesh-vertices must have at least one <input> (unshared) element with a semantic attribute whose value is POSITION.
    So I think this means that I can't leave <vertices> empty, also different positions would make different meshes right?

    Can I assume that a <mesh> can only contain single position source with single <input semantic="POSITION".. and the input must be in <vertices>, it makes sense then

  4. #4
    Senior Member
    Join Date
    Mar 2016
    Posts
    106
    The limitations on <vertex> seem to have to do with <morph> based animations. A "vertex" is a special semantic that combines all of the elements into a logical package. I worked with this somewhat when I developed a trial loader earlier in the year. I'm just now getting to apply the newly rewritten COLLADA-DOM library to that loader.

    Unfortunately it's hard to say anything authoritative about these things because we software developers can't afford to commit things to memory: we just have to relearn everything as it's required to implement something. All I can offer is my foggy old impressions, and the possibility that I might find myself retracing that code soon as I begin work testing a geometry loader.

    PS: This isn't really the COLLADA forum. There's another locked forum somewhere around here that existed when collada.org was a website. It was moved here to khronos.org and archived long after COLLADA discussion petered out. This is a new forum, that was offered after the transition/shuttering of collada.org.
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)
    https://sourceforge.net/p/collada-do...ussion/531263/

  5. #5
    So currently I assume this: POSITION can only and must (for mesh) exists in <vertex> until someone clarify this, after finished implementation, I'll back to investigate this

    It seems three.js also do this way (I don't say it is correct impl nor not):

    https://github.com/mrdoob/three.js/b...oader.js#L2830

    Unfortunately it's hard to say anything authoritative about these things because we software developers can't afford to commit things to memory: we just have to relearn everything as it's required to implement something. All I can offer is my foggy old impressions, and the possibility that I might find myself retracing that code soon as I begin work testing a geometry loader.
    Please let me know if you discovered what is the correct way to implement POSITION semantic or is my assumption correct or not...

  6. #6
    Senior Member
    Join Date
    Mar 2016
    Posts
    106
    I think <vertices> is POSITION+. I have the polylist referring to VERTEX. I think that means that's the POSITION source, + anything else built into the vertices. Because <morph> needs (or wants) all of the attributes bound to a vertex, it can only blend the associated attributes. The other attributes can exist, but do not take part in blending. Anyway, this is the basic view I am confident. There may be an alternative way; there may not.

    EDITED: BTW, disregard what I said about there being two forums. I'm pretty sure that was the case only earlier this year. But now it's plain that this forum goes back to the beginning. I'm either imagining things, or the two forums had their databases merged lately. (Or possibly it was just two boards that someone decided to merge.)
    Last edited by Mick P.; 12-01-2016 at 02:28 AM.
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)
    https://sourceforge.net/p/collada-do...ussion/531263/

  7. #7
    I think <vertices> is POSITION+. I have the polylist referring to VERTEX. I think that means that's the POSITION source, + anything else built into the vertices.
    Thanks, so I can still assume that unlike other semantics, POSITION semantic is only part of <vertices> element.

    Because <morph> needs (or wants) all of the attributes bound to a vertex, it can only blend the associated attributes. The other attributes can exist, but do not take part in blending. Anyway, this is the basic view I am confident. There may be an alternative way; there may not.
    One question/confusion:

    if mesh has different normal sources then how to blend these normals? Specs says that morph only blends normals inside <vertices>,

    Am I right for this: all sources inside <vertices> must have same index I mean in <p> </p> element if VERTEX offset=0 and <vertices> have more than one sources e.g normals, textures... then we can assume that position index=0, normal index=0 tex index = 0... an so on?

    if it is true then we can't add extra reference of primitives' inputs' sources to vertices to blend/morph? Because <vertices> inputs are <input> (unshared) and does not has offset attrib if we want to blend then we must join all sources, indexes to one (interleaved)?
    Last edited by recp; 12-01-2016 at 04:58 AM. Reason: typo

  8. #8
    Senior Member
    Join Date
    Mar 2016
    Posts
    106
    I don't know. I say "POSITION+." There may be other ways, but they'd not work with blending, because the weights must be assigned to a "vertex."

    On the second point, I'm pretty sure you can assign attributes via separate indices, and they will affect the image, but will not be blended by the morph-weight equations. I think I made a post around here, and there is more in the bug tracker that address some of these limitations. I would think of COLLADA as only expressive enough to describe relatively primitive video games. You can draw a straight line to it from the PlayStation's old hierarchical-model-data library.

    The weights system needs to be more flexible, but there's no rationale to push for a new version of COLLADA if there is not sound technology undergirding it. I think there are much more pressing issues with the current standard. To use COLLADA you have to scale back your ambition for certain. But in 3-D we've long gotten away from fundamentals, and no one has the faintest what the hell they're doing, so I think that can be a healthy attitude.
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)
    https://sourceforge.net/p/collada-do...ussion/531263/

  9. #9
    <p> element stores multiple indexes, but I'm trying to convert it to single-index to send OpenGL, I've some trouble :/

    For instance this looks nice:
    Code :
    <triangles count="286" material="Material1">
      <input offset="0" semantic="VERTEX"  />
      <input offset="1" semantic="NORMAL" />
      <p>1 0      2 0      1 0      3 1</p>
    </triangles>

    but this??
    Code :
    <triangles count="286" material="Material1">
      <input offset="0" semantic="VERTEX" />
      <input offset="1" semantic="NORMAL" />
      <p>1 0      2 0      1 1      1 1      1 3      1 0</p>
    </triangles>

    Position 1 used many times (this seems good) but position 1 needs to be duplicated for 1 1 and 1 3, am I right? Because they are not same vertex since they used different normals

    I don't think there is any restriction about this in specs so I think it must be fixed when parsing but finding positions to be duplicated is very costly :/
    Any suggestions? Mick?

  10. #10
    Finally I've purchased COLLADA book and found some answers for my first question:

    The “POSITION” semantic is strongly correlated with the identity of individual mesh vertices and the <vertices> element.

    Arnaud, Remi; Barnes, Mark C.. COLLADA: Sailing the Gulf of 3D Digital Content Creation (Page 54). CRC Press. Kindle Edition.


    “VERTEX”—Vertex attribute data principally containing the position of each vertex. This semantic is used to reference the <vertices> element. This is an indirection into the global definition of the mesh vertex attribute data described previously. Recall that the “POSITION” semantic cannot be used within a primitive collation element.

    Arnaud, Remi; Barnes, Mark C.. COLLADA: Sailing the Gulf of 3D Digital Content Creation (Page 55). CRC Press. Kindle Edition.

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Proudly hosted by Digital Ocean