please clarify <triangles> and <p>

I’ve read collada 1.4 spec about <input>, <triangles> and

But i still can figure how to construct triangle from <input> and

I made simple cube in Blender and exported it into .dae
I expect 12 triangles, and i’m sure they are there because i can see there is <source> for normals with count=36, so for each triangle there is normal.

<source id="Cube_001-Position">
					<float_array count="24" id="Cube_001-Position-array">-2.03054 -1.96333 1.97919 -2.03054 1.99505 1.97919 1.92784 1.99505 1.97919 1.92784 -1.96333 1.97919 -2.03054 -1.96333 -1.97919 -2.03054 1.99506 -1.97919 1.92784 1.99505 -1.97919 1.92784 -1.96333 -1.97919</float_array>
						<accessor count="8" source="#Cube_001-Position-array" stride="3">
							<param type="float" name="X"></param>
							<param type="float" name="Y"></param>
							<param type="float" name="Z"></param>

<source id="Cube_001-Normals">
					<float_array count="36" id="Cube_001-Normals-array">0.00000 1.00000 0.00000 0.00000 1.00000 0.00000 -1.00000 0.00000 -0.00000 -1.00000 0.00000 -0.00000 -0.00000 -1.00000 -0.00000 -0.00000 -1.00000 0.00000 1.00000 0.00000 -0.00000 1.00000 -0.00000 0.00000 0.00000 0.00000 1.00000 0.00000 0.00000 1.00000 -0.00000 -0.00000 -1.00000 0.00000 0.00000 -1.00000</float_array>
						<accessor count="12" source="#Cube_001-Normals-array" stride="3">
							<param type="float" name="X"></param>
							<param type="float" name="Y"></param>
							<param type="float" name="Z"></param>

<triangles count="12">
					<input offset="0" semantic="VERTEX" source="#Cube_001-Vertex"/>
					<input offset="1" semantic="NORMAL" source="#Cube_001-Normals"/>

4 0 0 0 7 0 0 1 3 1 7 1 2 2 6 2 3 2 6 3 7 3 3 3 1 4 5 4 2 4 5 5 6 5 2 5 0 6 4 6 1 6 4 7 5 7 1 7 4 8 7 8 6 8 4 9 6 9 5 9 0 10 1 10 3 10 1 11 2 11 3 11</p>

Could please somebody explain me how to reconstruct vertices from

and <input>s.
Thanks in advance. :roll: :roll: :roll:

Hi, the offset in the normals input should be 0, just like the vertices. This is a common mistake as it is natural to assume that the normals data is offset, but in this case the indices list is applied to both the vertex and normal data starting at the zero index. The indices for the first triangle should use (4,0,0) for the vertices and (4,0,0) for the normals. Using an offset of 1 for the normals would start the indices at 1 and result in using indices (0,0,0). I hope this helps.

But why have 3 indices for 1 normal vector?
Isn’t 1 vertex enough?

I don’t think Lonesled’s information is correct.

Look at the “offset” attribute of each <input> in <triangles>. The “vertices” (which just contain position info in this example) are offset 0 and the normals are offset 1. This means that the first value in the

is a position, the second value is a normal, and that makes one complete “index”. The third value is a position again, and the fourth value is a normal. The fifth value is another position, and the sixth value is a normal, and that completes the first triangle. Repeat for the other 11 triangles.

The key thing that may be confusing is that Collada allows different indices per stream (I call them “non-unified indices”). That is, a single logical “index” can refer to (e.g.) the 10th position and the 3rd normal. Graphics APIs like OpenGL and Direct3D only support unified indices, where each index is a single value specifying where to look in both the position and normal streams. Non-unified indices are more flexible and allow a more compact data representation. For example, using non-unified indices, a cube can be described with 8 positions and 6 normals, but with unified indices you need 24 positions and 24 normals.

Dealing with non-unified indices is one of the trickier aspects of writing a Collada importer, since most Collada exporters write data using non-unified indices, and most graphics APIs don’t support them. You need to transform the data to unified index form. This code is tricky to write, but fortunately it’s already been done for you. The confusingly-named “deindexer” conditioner in the Collada Refinery converts a Collada document to unified index form.

Thanks for replies!
sthomas is right i think, i was able to reconstruct cube and monkey :smiley:
But i still don’t understand why for each vertex i have 1 normal! I should have 1 normal for 3 vertices(in case of triangles). what for there is 1 normal for 1 vertex.
Please, could somebody explain.
Thanks again for help!

Nevermind please, 1 normal for 1 vertex is good to have :slight_smile:

Could somebody clarify “set” attribute in <input> tag,

<input offset="0" semantic="VERTEX" source="#LOD3spShape-lib-vertices"/>
<input offset="1" semantic="NORMAL" source="#LOD3spShape-lib-normals"/>
<input offset="2" semantic="TEXCOORD" source="#LOD3spShape-lib-map1" set="0"/>

Collada 1.4.1 spec. says “Which inputs should be grouped together as a single set.”, but “grouped” in what way?
Please help, or you won’t see Final Fantasy 19! :smiley:

Yeah it’s a little confusing. You can have multiple sets of texture coordinates in a <mesh>, and you can have multiple textures in an <effect>. The set attribute plays a role in matching up the textures in the <effect> with the texture coordinates in a <mesh>, which happens in <instance_material>.

  <input offset="0" semantic="TEXCOORD" source="#texCoords1" set="0"/>
  <input offset="1" semantic="TEXCOORD" source="#texCoords2" set="1"/>
    <texture texture="sampler1" texcoord="diffuseCoords"/>
    <texture texture="sampler2" texcoord="specularCoords"/>
  <instance_geometry ...>
        <instance_material ...>
          <bind_vertex_input semantic="diffuseCoords" input_semantic="TEXCOORD" input_set="0"/>
          <bind_vertex_input semantic="specularCoords" input_semantic="TEXCOORD" input_set="1"/>

To retain as much flexibility as possible, material properties are bound when a geometry element is instantiated, not when it’s defined. As shown in the example above, the “set” attribute is used to bind a texture to a particular set of texture coordinates in <bind_vertex_input>.

For additional references, take a look at this thread and the section on texture mapping in the release notes.

Please help, or you won’t see Final Fantasy 19! Very Happy
Noooo! haha :slight_smile:

Are you a Square-Enix employee?

Oh, i think i get it. set attribute has nothing to do with changing value of texture coordinates, i mean they are supposed to be used (in say…OpenGL glTexCoord2f) as they come from source for texture coords?

Backing up a bit, I was incorrect on the “offset” in the

array, so thanks for clearing this up for me. I was getting it confused with the “offset” in the accessor. We have been using an exporter that produces unified indices and had completely missed non-unified!

Oh i’m stuck with this duck(COLLADA Overview - The Khronos Group Inc) :evil:
Vertices and normals play well, but not textures.
I checked, texture is not corrupted.
Here is how i create trianles, normals and texcoords(nvm cocoa :P):

DAEModelTexCoordsReconstructed is mutable array there texture coordinates are stored
A lot of stuff is hardcoded, it’s because i’m just trying it out.
Please point out if You can see some fundamental mistake.
Big thanks for earlier help.

I can’t find anything obviously wrong with your code. One thing that might help is to make a test model with a single textured triangle and manually inspect all the texture coordinates before you send them to OpenGL.

Ok, thanks.
I’ll ask if somebody could write a small app to render duck.
It i find what was wrong i’ll inform about that.

The number of vertex is always bigger or equal than the number of any other attribute stream right?

It is OK, 8 positions and 6 normals, but our guy have 8 positions and 12 normals. And I don`t understand what does you explain? Could you write a simple pseudo code about convertation? And when I use indecies , I also need just 8 positions and 6 normals for a cube (not 24 positions and 24 normals).

A cube has eight unique positions and six face normals where each face is a quad. Each position belongs to three faces making a total of 24 unique vertices (8 positions x 3 face normals). If your data has more then six unique normals then at least one of the faces is not a flat (shaded) quad.

Since you have 12 normals it might be a low resolution sphere as the number implies there are two normals per face.