Implementing Models with many Triangle Instances

The models i’m exporting are already compiled into a binary format and it is like this:

  • Triangle Set 1 (200)
  • Triangle Set 2 (50)
  • Triangle Set 3 (4)
  • Triangle Set 4 …
  • Triangle Set 5 …
  • All Positions lumped into one array (254 positions)
  • All UV’s lumped into one array
  • All Normals lumped into one array

The Triangle positions are offset by the previous set, so Triangle Set 2 is offset by 200 for instance and the next 50 values in the array are the positions.

I havn’t dealt with a COLLADA document yet that has had separated triangles (or indexes) before. I know I could just merge the Triangles into one array and modify the integers accordingly but they are logically separated.

In COLLADA if I was to keep the indexes separate, how do I implement this? Would you suggest I create a different geometry library for each Triangle set and separate its own positions from the array, or keep the array as one and implement separate triangle submeshes? I’m not sure how to do either. Thanks for any advise in advance, Thank you :slight_smile:

If you want to group your indices of triangles sets desparately and want to share the same POS, NOR, UV array, then you should put your multiple triangles in your mesh.


<mesh>
   <source>   ...   your position array here ... </source>
   <source>   ...   your normal array here ... </source>
   <source>   ...   your uv array here ... </source>
   ...
   <triangles material="Set_1"> ... indices here ...  </triangles>
   <triangles material="Set_2"> ... indices here ...  </triangles>
   <triangles material="Set_3"> ... indices here ...  </triangles>
   ...
</mesh>

You would want to do separate geometry for separate triangles if you don’t want to share the POS/NOR/UV arrays.
Another word, if you want to do transform on your triangles meshes and you want to move them all at the same time (like they were attached), then they should all in the same geometry/mesh.
If you want to move (transfrom) some sets of you triangles and not the rest, then you will have to group them in separate geoemtry/mesh.

Again uclahklaw, thanks :slight_smile:

I’m still a little unclear of the best method to export these particular models since there are many indexes working off the same geometries. I’ll define it to make my explanation easier.

Positions (XYZ) contains 254 points.

Index Buffer 1 contains 200 vertices (positions 0 -> 199)
Index Buffer 2 contains 24 vertices (positions 200->23). Note the positions are referenced by 0 ->23 even though they are offset by the previous index size. (200)
Index Buffer 3 contains 30 vertices (positions 224-254). References by 0->30. Similar to index buffer 2 the positions are offset by the previous index sizes (200+24).

This was done this way to work with the engine they were exported for. My question is, should I just add the offset of the previous indexes to the following index in my exporter, or is it possible to offset the index so it reads the values from the appropriate position? ie. index 2 is offset by 200 and reads positions 200-223 as actually 0-23.


<mesh>
   <source>   ...   your 254 position array here ... </source>
   <source>   ...   your normal array here ... </source>
   <source>   ...   your uv array here ... </source>
   ...
   <triangles material="Set_1" count=200> ... indices here 0 -> 199 ...  </triangles>
   <triangles material="Set_2" count=24 > ... indices here 200->223 ...  </triangles>
   <triangles material="Set_3" count=30 > ... indices here 224->254 ...  </triangles>
</mesh>

You should just add the offset. If your index buffers use or share the same position, you can use the same index in your <triangles>.

If your index buffers don’t use or share the same position, then they can potentially be in separate meshes.

For example,
If your index buffers are a man, a hat, and a gun, and they don’t share vertex position, then they should be in different mesh.

If your index buffers are a body, a head, and a horn, and they share vertex position,
then they should be in the same mesh.

Herbert

Now I get it, thanks 8)