Question on offsets and <p> elements.

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

construct does not have a “stride” attribute?

Cheers,

Gino

It appears that the stride of 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.

-Andy

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.

Gino

Because <polylist> design was contributed by Softimage and it includes a required count attribute.

Also because the

element is a high frequency element, unlike the <polylist> element, and so it does not have any attributes in order to minimize bloat.