Gah! Right to Left Handed Conversion Driving Me Crazy

Started by
27 comments, last by Leo_E_49 18 years, 6 months ago
Hi,

I'm not a math wizzard, so I can't explain how I came up with the following code (it was pure hack : try something, see if it works, etc. ^^) But I've been using it for more than half a year now, and it works.

Here's a piece of code I use in my exporter :

// transform each vertexfor (unsigned int v = 0; v < m_VertexList.GetNum(); v++){   m_VertexList[v].position.x  = -m_VertexList[v].position.x;   m_VertexList[v].normal.x    = -m_VertexList[v].normal.x;}// ...// extract the transformations from the transformtransform.getRotation(eulerRotation);transform.getScale(scale);translation  = transform.translation(MSpace::kWorld);// convert it to left handed :// - negate translation along X// - negate rotations around Y and Ztranslation.x	= -translation.x;eulerRotation.y	= -eulerRotation.y;eulerRotation.z	= -eulerRotation.z;// rebuild a transformtion matrix from the modified transformationsMTransformationMatrix transformationMatrix;transformationMatrix = transformationMatrix.identity;transformationMatrix.rotateBy(eulerRotation, MSpace::kWorld);transformationMatrix.setScale(scale, MSpace::kObject);transformationMatrix.setTranslation(translation, MSpace::kWorld);


It's the same as you do. I think that when we switch from right to left handed systems, the rotation orders change. So we should invert all rotations. BUT we also have to invert 1 axis. So, inverting this axis and inverting the rotation around it would give the same rotation. That's why, if we invert X, we only need to invert rotations around Y and Z.
I'm pretty sur that if we add to invert the Y axis (for example), we would have to invert rotations around X and Z.

That's the only explanation I can find with the pieces of math I still remember from my studies ^^
Advertisement
Euler angle rotation is not commutative. Also, they rotate clockwise (left handed) or anti-clockwise (right handed) depending on the handedness of the coordinate system.

Also, to my understanding, Euler angles work by a rotation first around the x then the y then the z axes. Currently doing this with a right handed model on a left handed system, you're actually doing rotations around x, then z, then y.

So theoretically, in order for this to work, first you should swap your y and z axes to convert the coordinate system (i.e. swap your y and z components of the Euler angle set).

Thereby rotations will be applied in x, y and z in correct order.

Now, only slightly more difficult, negate the angle of each subset in the Euler angle set you're using.

-X, -Y, -Z

reason being that you have to convert from rotating anti-clockwise to clockwise.

I hope this works, I'm a little rusty with Euler angles and I've never actually used them in a game or programmed them or converted them from right handed to left handed. This is more or less a guess and my doing some working in the past 5 minutes off the top of my head.
Quote:It's the same as you do. I think that when we switch from right to left handed systems, the rotation orders change. So we should invert all rotations. BUT we also have to invert 1 axis. So, inverting this axis and inverting the rotation around it would give the same rotation. That's why, if we invert X, we only need to invert rotations around Y and Z.
I'm pretty sur that if we add to invert the Y axis (for example), we would have to invert rotations around X and Z.

Thanks. This makes a lot of sense and I think that's what is going on here. However, I still can't get my head around what is going on when I instead swap the Y and Z axis.

Quote:So theoretically, in order for this to work, first you should swap your y and z axes to convert the coordinate system (i.e. swap your y and z components of the Euler angle set).

Thereby rotations will be applied in x, y and z in correct order.

Now, only slightly more difficult, negate the angle of each subset in the Euler angle set you're using.

-X, -Y, -Z

reason being that you have to convert from rotating anti-clockwise to clockwise.

I tried this, but still no luck and the animations are still mangled. I tried a few combinations of negating different axis, but still no joy.
Question, are you negating the angles or their sines and cosines? There's a BIG difference between the two.
Quote:Original post by Leo_E_49
Question, are you negating the angles or their sines and cosines? There's a BIG difference between the two.


I am negating the angles, ie the euler values.
Is there any chance you could change the animation system to use quaternions? There are a bunch of other advantages to this representation as well. In my Max exporter I just convert the quaternions by converting to axis angle, then applying the same axis swap (y <-> z) then converting back to a quaternion. This probably isn't the best way but it works and makes sense.
Quote:Original post by d00fus
Is there any chance you could change the animation system to use quaternions? There are a bunch of other advantages to this representation as well. In my Max exporter I just convert the quaternions by converting to axis angle, then applying the same axis swap (y <-> z) then converting back to a quaternion. This probably isn't the best way but it works and makes sense.


I am currently exporting as euler angles and then converting the eulers into quaternions in my engine. The reason I went with eulers is because it makes the export file more readable and easier to find errors.

I could go with quaternions (I originally was using quaternions but changed to eulers), but I am thinking I will still have the same problem and it will just make it worse because the quaternions are pretty unreadable and I will end up with less of a clue than I have now (pretty much why I changed to eulers in the first place! :P).
Would you mind showing us your actual code? It might make things a little easier.
Quote:Original post by Leo_E_49
Now, only slightly more difficult, negate the angle of each subset in the Euler angle set you're using.

-X, -Y, -Z


Actully come to think of it... Why do you need to swap the Y and Z axes for rotations? Translations yes, but rotations, this is confusing me. :S

This concept supports your results from negating X and Y components. All you should have to do is negate the Z component too. Why it popped into my head that you have to swap the Y and Z axes for rotations I don't know. :(
Quote:Actully come to think of it... Why do you need to swap the Y and Z axes for rotations? Translations yes, but rotations, this is confusing me. :S


Yeah, it's confusing me too. I know that it doesn't work if I just leave them as is, so swapping the Y and Z for vertices definitely affects the rotations somehow.

This topic is closed to new replies.

Advertisement