Results 1 to 5 of 5

Thread: Question on offsets and <p> elements.

  1. #1
    Junior Member
    Join Date
    Mar 2005
    Location
    Netherlands
    Posts
    8

    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.
    Code :
        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
    Gino van den Bergen
    www.dtecta.com

  2. #2
    Senior Member
    Join Date
    Jan 2006
    Location
    Foster City, CA
    Posts
    540
    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.

  3. #3
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    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

  4. #4
    Junior Member
    Join Date
    Mar 2005
    Location
    Netherlands
    Posts
    8
    Quote Originally Posted by alorino
    ...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.

    Gino
    Gino van den Bergen
    www.dtecta.com

  5. #5
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •