Results 1 to 6 of 6

Thread: Wrong Normals & TexCoords in COLLADA DOM

  1. #1
    Vermeer
    Guest

    Wrong Normals & TexCoords in COLLADA DOM

    Hi,

    I'm using COLLADA-DOM to parse a simple DAE file (the yellow duck model). I'm basing my implementation on the COLLADA-RT example. When I load the texture coordinates, the (s,t) values are correct (I've checked), but they are assigned to the wrong vertices. This of course produces weird results.

    I get a pointer to the proper source array using this code:

    Code :
            if ( szSemantic_input == "TEXCOORD" )
    	{
    	    domSource* source = (domSource*) (domElement*) inputs[i]->getSource().getElement();
    	    pTexCoordFA = source->getFloat_array();
    	    bTexture    = TRUE;
    	}

    Then, I use this code to copy the data to my polygonal mesh class:
    Code :
    	for ( j=0 ; j<npts ; j++ )
    	{
     
               ...
     
    	    if ( bTexture )
    	    {
    		pPolyMesh->SetTexCoords(    
                                             pTexCoordFA->getValue()[j*2],
    					    pTexCoordFA->getValue()[j*2+1],
    					     j+1 ); // UNIT-based access 
    	    }
    	}

    I've been trying to fix this for a couple of days and I think it is something real obvious or a bug in the COLLADA-DOM code.

    Anyone knows what's going on? The normals have the same problem.

    Vermeer

  2. #2
    Vermeer
    Guest
    OK, I've fixed it. The problem was that I was assuming that the TEXCOORD array had the same order as VERTEX. I rearranged the order based on the info storred under <triangles> and everything looks fine...almost

  3. #3
    Senior Member
    Join Date
    Aug 2005
    Location
    California
    Posts
    165
    If you ever run into problems like this in the future, take a look at the COLLADA RT source code. If the RT can load the document then it isn't a problem with the DOM. Now if the RT can't, then it's either not supported in the RT (more likely) or a problem with the DOM (less likely).

    I only ever see problems with the DOM with users implementing the more advanced COLLADA features. Since they are newer and use more advanced XML Schema features, and have been tested less (people are just starting to implement support for them) some of the DOM handling may be buggy. But it is still really stable. Those problems are few and far between.

    -Andy

  4. #4
    Vermeer
    Guest
    Actually, I *am* using Collada RT as an example implementation. The problem is that the code is very poorly documented, and I could not understand the need for the deindexer() function before I started loading textures and noticed the difference in source array size. Therefore I got rid of it (deindexer) since this extra step was allocating a full copy of the data set in memory.

    This whole indexing thing is not explainned in the book or in the documentation. Are we supposed to guess? Mayvbe this is a common thing in game programming (I'm a scientific/simulation guy).

    Collada RT is an exellent start but we need a seperate Collada 101 document that exlains all these little implementation pitfalls. This would save everyone a whole lot of time and make the exprerience more pleasant.

    Cheers,

    Vermeer

  5. #5
    Senior Member
    Join Date
    Jul 2004
    Location
    Santa Clara
    Posts
    356
    Quote Originally Posted by Vermeer
    we need a separate Collada 101 document that exlains all these little implementation pitfalls. This would save everyone a whole lot of time and make the experience more pleasant.
    This is an excellent idea, you could start writing up such a document, since you have first hand experience of what is missing, and post it in this forum ?

  6. #6
    Vermeer
    Guest
    Great idea Remi. I'm starting a new thread to gather suggestions on things to cover.

    - Vermeer -

Posting Permissions

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