Question

I am trying to create a simple matrix library in C++ that I will hopefully be able to use in game development afterwards.

I have the basic implementation done, but I have just realized a problem with storing only one matrix per object: the rotation order will get mixed up fairly quickly.

To the best of my knowledge: AB != BA

Therefore, if I am continually multiplying arbitrary rotations to my matrix, than the rotation will get mixed up, correct? In my case, I need to rotate globally on the Y axis, and locally on the X axis (and locally on the Z axis would be nice as well). These seem like the qualities of the average first person shooter. So by “mixed up”, I mean that if I go to rotate on the Y axis (or Z axis), then it will start rotating around the local X axis, instead of the intended axis (if that makes any sense).

So, these are the solutions I came up with:

1. Keep 3 Euler angles, and rebuild the matrix in the correct order when one angle changes
2. Keep 3 Matrices, one for each axis
3. Somehow destruct the matrix during multiplication, and reconstruct it properly afterwards (?)

Or am I worrying about nothing? Are my qualms false, and the order will somehow magically solve itself?

Answer 1

You are correct that the order of rotation matrices can be an issue here.

Especially if you use Euler angles, you can suffer from the issue of gimbal lock: let’s say your first rotation is +90° positive “pitch”, meaning you’re looking straight upward; then if the next rotation is +45° “roll”, then you’re still just looking straight up. But if you do the rotations in the opposite order, you end up looking somewhere different altogether. (see the Wikipedia link for an illustration that makes this clearer.)

One common answer in game development is what you’ve got in (1): store the Euler angles independently, and then build the rotation matrix out of all three of them at once every time you want to get the object’s orientation in world space.

Another common solution is to store rotation as an angle around a single axis, rather than as Euler angles. (That is often less convenient for animators and player motion.)

We also often use quaternions as a more efficient way of storing and combining rotations.

Each of the links above should take you to an article illustrating the relevant math. I also like Eric Lengyel’s Mathematics for 3D Game Programming and Computer Graphics book, which explains this whole subject very well.