getMeter() function

Have you tried it ?

I’m experiencing pbs…

I want to get the scale by doing this :

/* Unit */
if(thisAsset->getUnit() != NULL)
	unit = (f32) thisAsset->getUnit()->getMeter();
	unit = 1.0f;	

But I get bad values like 3.5E10-37
I don’t understand because when I check the source code of the DOM it’s quite simple.


I am unsure of exactly why you are getting the problem you are but this is what I found out as I looked into it.

getMeter() returns a domFloat, which is actually a c++ double. When casting it to a float you sometimes get some error. The file I tested this on used meter=“0.01” and the value I got after the cast was 0.009999999998.
But tests with the value of 0.0 or 1.0 there was no inaccuracy.

I really don’t know why you are getting such an odd value.


Apparently, the object is badly initialized. If I put a setMeter(1.0f) just before the getMeter() I get a good value.

It’s weird !

I don’t know what to tell you. I cannot recreate this issue you are having.

If the <unit> element is not in the document being loaded you would get NULL in that check. If the <unit> is specified but the “meter” attribute is ommitted the default value should be set to 1.0. If the “meter” attribute is specified then it should read it without any problems. I tested all 3 of these cases and they all worked correctly.

This is all auto-generated code from the schema. It gets handled in a generic manner. If this didn’t work here then there would be the same problem everywhere.

I’m sorry I don’t know how to help you any further but if you figure out exactly what is causing this I would be interested in hearing about it.

Well, I just work on this problem again. The solution I found is to invert

	xsNMTOKEN attrName;


domFloat attrMeter;

It’s not the ultimate solution but it’s work for now.

What do you mean by “invert”? Did you change the order of declarations in the header file?

Andy this implies there might be a memory overrun on attrName. Better check its initialization.

Yes, that what I did.

When I debug the value is good, it’s just that the function doesn’t return the good value. Ther is a shift of 4 bytes I think when I look in the in the assemblor code.

As it works now, I’m not sure i want to spend hours to find a solution.

Its just a pointer to a string. That wouldn’t overrun any other memory,
unless the reflection is wrong and the compiler is generating the wrong offset and storing the pointer in the wrong place.

jairbubbles, what OS are you running? and anything else not typical on your system? are you running a 64bit OS?


I’m running Win XP SP2, using VS 2003 on a 32 bit system. Quite an usual system…

This happens to be the difference in size between a C float and double. Andy perhaps there is an offset bug in the daeMeta for this field?

I finally found the solution. It was an alignment problem. I forced a 4 bytes struct alignment in the collada project and it’s ok now.

Well the struct should not be 4 byte aligned if it contains a double. I think this is a bug in the DOM metadata that needs to be fixed.