Please refer to the box xml sample for this discussion.
Notice that the all the vertex floating point data. The node that stores this represents it as a list of 24 floats. the “<technique>” nodes (adjacent to the “<array>”) are provided for how to interpret this data. The semantic (what the data is used for) is stored ouside the “<source>” node.
The data is clearly 8 elements in R3. So why no use arrays of float3s? Float3 is alreay defined in the schema. No one would ever interpret this as 12 elements of type float2.
Going further, it would be nice to allow arrays of more arbitrary structures. i.e. elements in the cartesian product of position space, texture space, normal space, color space. This is not the same as sharing indexes with multiple sources, but instead it is actual interleaved data.
<array name=“myvertexbuffer” type=“float3 float3 byte4” semantic=“Position Normal Color” count=“n”>
x y z nx ny nz 0xrrggbbaa,
x y z nx ny nz 0xrrggbbaa,
</array>
For some people this is what they want their vertex buffer to look like. By being able to represent this data within collada will make it trivial to convert back and forth from xml (text) to C vertex classes (binary). The mapping is obvious.
Right now you may be able to interleave your positions and normals into on big array of floats using an accessor trick, but you wouldn’t be able to get the non-float color in there as well using the current schema.
You dont store bitmap data within a collada file (nor within an html file). Instead people use references like
I propose allowing the same with other arrays such as:
<array name=“myPositionData” type=“float3” src=“filename”/>
This way, application developers can continue to use the collada data model when working with binary data.