3

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?

TylerH
  • 20,799
  • 66
  • 75
  • 101
Jamie Syme
  • 528
  • 2
  • 6
  • 10

2 Answers2

4

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.

Crashworks
  • 40,496
  • 12
  • 101
  • 170
  • Don't quaternions suffer from the same problem described in my question? Or is this problem only relevant because I am persisting on using Euler angles? At the moment, I am leaning towards storing the Euler angles independently, and hoping for the best. – Jamie Syme May 29 '12 at 14:39
  • @JamieSyme Rotations on local axes are inherently sensitive to order. Turning ninety degrees to the left and then looking thirty degrees upwards is different from looking thirty degrees upwards then turning ninety degrees to the left (try it with a model plane). Where quaternions help you is that there's only ever one rotation in the stack -- you don't store pitch/yaw/roll seperately, it's only ever just one axis and angle. But that isn't a natural way to think about player movement, which is why most people prefer Euler angles there. Just be consistent about the order in which you apply them. – Crashworks May 29 '12 at 20:54
  • Okay, I think I understand now. I will just store my angles as Euler angles since they will be easier to understand for the time being. If I ever happen to run into gimbal lock, I will try to adopt a 'quaternion' rotation approach, or something similar, and put away my Euler angles. Thanks :) – Jamie Syme May 30 '12 at 01:38
  • @JamieSyme You can still use Euler angles for modifying a rotation (if you really want), nothing prevents you from rotating along three coordinate axes one after the other, but you should really think about another representation for storing rotations and computing with them. And matrices or quaternions are the most natural ones (at least for the computer if not for us humans, but we don't want to compute with them, anyway). – Christian Rau May 30 '12 at 08:20
2

I don't know how other people usually do this, but I generally just store the angles, and then reconstruct a matrix if necessary.

You are right that if you had one matrix and kept multiplying something onto it, you would end up messing things up. But again, I don't think this is the route you probably want to take.

I don't know what sort of graphics system you want to be using, but with OpenGL, you don't even have to worry about the matrix representation (unless you're doing something super performance-critical), and can simply use some calls to glRotate and the like.

Xymostech
  • 9,710
  • 3
  • 34
  • 44
  • Thank you for your response! This is actually the approach I'm choosing to take (storing the angles and constructing a matrix if needed). The reason I chose Crashworks's answer is because of the alternate approaches suggested, but I still very much appreciate your answer :) – Jamie Syme May 30 '12 at 01:41