I wasn’t suggesting more types of elements. In general I was suggesting 2 things. One that for example
<Array size=“5” type=“xs:float”>
1.0 2.0 3.0 4.0 5.0
Be changed or at least optionally be allowed to be something like
<Array size=“5” type=“xs:float” binary=“true”>
Where “$%%$$#”%"#$!$"$%$%&"" is the binary representation of those 5 floats in some format specified by Collada. Most likely the standard PC float format in PC byte order since that’s the most likely place for this data to be used.
Because while parsing 5 ascii representations of floats and converting them real floats is not a big deal, parsing 5 million of them is. If the format allowed this binary option and all the exporters supported it either by default or by option then when parcing an array, since I know the size “5” and I know the binary representation of the type because it would be specified in the Collada spec then once I hit <![CDATA[ I would instantly know exactly how many bytes to read out of the file and I could load it directly into memory and use it instantly.
Given that polygon counts are going to up at least an order of magnitude for the next gen I think it would be a good idea to, if possible, optimize this format, while it’s still possible, to be better aimed and large data sets.
This wouldn’t scarifice any usefulness or genericness as far as I can see but it would make it possible to use the data faster and bring conversion times down.
The other thing I was suggesting is to try to avoid, where possible, massively repeating elements. The spec already does this as far as I can tell, I was just pointing it out because I wasn’t sure if that was intentional or just luck
For example IF the vertex format was something like
<vert>1 2 3</vert>
<vert>3 2 1</vert>
<vert>5 5 6</vert>
That would end up being hugely expensive to parse and most XML parsers would choke on it once the files sizes got really large since every single vertex would be stored in a separate element structure in the internal parse tree.