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:


        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:


	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. :evil:

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

Vermeer

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 8)

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

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

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 ?

Great idea Remi. I’m starting a new thread to gather suggestions on things to cover.

  • Vermeer -