I’m working on a COLLADA mesh importer that uses the latest COLLADA DOM, and found the way the
elements are accessed rather unintuitive. It appears that the stride of the
elements array can basically be taken to be the maximum offset plus one. Here’s a code snippet that computes the index stride.
unsigned int maxOffset = 0;
for (size_t i = 0; i != numInputArrays; ++i)
{
unsigned int offset = inputArray[i]->getOffset();
if (offset > maxOffset)
{
maxOffset = offset;
}
}
unsigned int indexStride = maxOffset + 1;
Is this the way to go, or am I missing something? It seems that I can leave out input arrays that use an offset smaller than maxOffset in my DAE file. The maxOffset cannot be left out. This all seems kinda clumsy to me. For instance, why does the
elements array can basically be taken to be the maximum offset plus one. … Is this the way to go, or am I missing something?
I compute it the same way. To be honest I’m not sure why they decided against adding a stride attribute.
I think we didn’t use a stride attribute because it can be easily calculated.
Doing a max integer algorith on attribute values isn’t a big deal. But having inconsistencies between what the max offset is and what is specified in stride would be a big deal. We then have to specify how to deal with the ambiguity, so we decided to not even allow a chance for ambiguity.
If having these kind of inconsistencies is considered harmful, then why does a polylist element have a “count” attribute? You can get the number of polygons from the vcount element as well.
It simply seems awkward to me to have to rely on the max offset in order to properly extract the
list, but I guess this is the wrong place for such a discussion. Anyhow, it’s indeed not a big deal. Thanks for giving me some insight into the design of COLLADA.