PDA

View Full Version : Problems with normal vectors in ASE-files



07-04-2001, 03:48 AM
Hello!

I'm having problems reading vertex normals from ASE-files. The normals for some of the objects are pointing in the wrong direction. I have noticed that the affected objects have different values for TM_ROTAXIS and TM_ROTANGLE.
For example, an object with correct normal vectors have the following values:
TM_ROTAXIS 0.0 0.0 0.0
TM_ROTANGLE 0.0

..while an object with faulty normals may look like this:
TM_ROTAXIS -0.577 -0.577 -0.577
TM_ROTANGLE 2.094

I guess i can use this information to rotate the normals to their correct angles, however I'm not sure on how to do this.

Anyone knows anything about this? Some guidance would be greatly appreciated!

Thanks, Per

DFrey
07-04-2001, 06:10 AM
You could easily convert the axis-angle pair into a rotation matrix and use that rotation matrix to rotate the normals. Though I'm not certain you really need to do that. I recall a few other posts to this board where people were having problems just like you. And I don't remember anything about an axis-angle being discussed, and I've never used the ASE format myself so I'm uncertain what really needs to be done. So you might want to search the forum for those old threads because I do remember someone posted who was familiar with the problem and knew how to deal with it.

DFrey
07-04-2001, 06:16 AM
I did a quick search and here is one of those old threads. http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/001665.html

07-04-2001, 10:06 AM
Hello again!

Now I have tried both making a rotation matrix out of the TM_ROTAXIS/ANGLE data and using the method explained in the thread you pointed me to. Both methods fixed most of my problems, but unfortunately none of them seem to work 100%. One method solves some of the normal problems, while failing to calculate some other normals that the other method does fine, and vice versa.

The problem is related to how the objects are rotated in 3dsmax. For example, some object might export just fine, but if I rotate it say, 90 degrees (in 3dsmax) the normals end up pointing in wrong directions. (which I can correct by switching method (above), resulting in other objects getting incorrect normals.. ) :-/

Can there be a way to combine the information in TM_ROTAXIS/ANGLE and the TM_ROWx to make it work for every possible object? Or have I made a mistake in my code? Has anyone got any more experience regarding this issue?

Thanks in advance,
Per

rIO
07-06-2001, 06:26 AM
Dunno if I remember the right way but... haven't ASE normals inverted Z-Y values ??

Bha, I'm getting older and older, can't remember everything... :P


rIO.sK

07-07-2001, 01:32 AM
[QUOTE]Originally posted by rIO:
[B]Dunno if I remember the right way but... haven't ASE normals inverted Z-Y values ??

Yes, that's true. But I have already converted the values to the OGL coordinate system, so the problem is not related to that. However, I have been experimenting a bit more and found that making a rotation matrix out of the TM_ROTAXIS & TM_ROTANGLE is less likely to produce errors than the method described here: http://www.opengl.org/discussion_boards/ubb/Forum2/HTML/001665.html

I have never seen anyone else mentioning this, so I might as well explain how I do it.. Making a rotation matrix out of Euler values is rather complicated (at least I think so..) so I use some opengl commands to do the job:

Put the TM_ROTAXIS values in rotx, roty & rotz.
Put TM_ROTANGLE in rotAngle;

GLfloat mat[16];

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glRotatef (rotAngle*180/3.14159, rotx, roty, rotz);
glGetFloatv (GL_MODELVIEW_MATRIX, mat);

Now, you have the rotation matrix stored in the array mat.

Multiply each (vertex)normal vector (v) with mat like this:

n.x = v.x * mat[0] + v.y * mat[1] + v.z * mat[2];
n.y = v.x * mat[4] + v.y * mat[5] + v.z * mat[6];
n.z = v.x * mat[8] + v.y * mat[9] + v.z * mat[10];

...and you've got the new, correct, normal vector (n). Don't forget to normalize the normal vector afterwards.

Of course you shouldn't do this in real-time. Pre-calulate instead.

Comments are welcome!

/ Per