Manipulating a free camera

I have a camera class in my code which stores two 4x4 matrices. One for the view matrix and one for the projection matrix. Originally, I had two floats in the class for pitch and yaw and these were updated based on keyboard and mouse input. Then on update I would do something like this to set the view matrix:

Matrix33 xRot = Matrix33::CreateRotationX(m_pitch);
Matrix33 yRot = Matrix33::CreateRotationY(m_yaw);

Matrix33 rot = xRot * yRot;

const Vector3& rUp = rot.GetColumn1();
const Vector3& rForward = rot.GetColumn2();

m_viewMatrix = Matrix44::CreateLookAt(m_position, m_position + rForward, rUp);

However, I'm now wanting to add roll to the equation but I know that if I carry on using this method I'm going to run into gimbal lock. I do have a function in my maths library to rotate about an arbitrary axis. The function definition is:

static Matrix33 CreateRotation(const Vector3 &rAxis, const float rad);

But I'm not sure, based on pitch/yaw/roll how to create the arbitrary axis to rotate around. This got me thinking that perhaps pitch/yaw/roll isn't the best way to be doing it so I thought I'd ask on here about what might be the best way? I don't even have to use CreateLookAt(), it just seemed easier at the time :)

I don't have a quaternion class yet but I could add one if that would be the best way. I think ideally I'd rather do it with just matrices for now, though.

Any help would be much appreciated.

Your arbitrary axis for the static method of rotation around an arbitrary axis are as follows:

Vector3& pitchAxis = rot.GetColumn0();
Vector3& yawAxis = rot.GetColumn1();
Vector3& rollAxis = rot.GetColumn2();

Now, if on a partcular frame, you wanted to pitch 0.01 radians, yaw 0.25 radians, and roll 0.03 radians, you could do it like this:

Vector3& arbitraryAxis = (pitchAxis * 0.01f) + (yawAxis * 0.25) + (rollAxis * 0.03);

rot = arbRotation * rot;

Notice you no longer keep track of overall rotation angles of the camera any more (whew!), simply determine how much you want to YPR each frame and apply it.

• Concerning re-orthonormalzing a matrix. I don't believe it is as big of an issue as some may think. I have run something like the above for over 15 hours at 60 times per second without seeing any noticeable distortion or skewing... It is there it just stays so small it isn't visibly noticeable... floating point error takes ages to add up to something significant, unless some operation mathematically compounds the error each time, then it explodes fast. The above example is safe from that. Oct 7 '11 at 17:53
• This sounds about right for what I need, cheers. I'll give it a try when I get home later. Presumably using this method I wouldn't need to use CreateLookAt() because I'd just be multiplying the view matrix by the rotation matrix generated each frame? Oct 8 '11 at 12:12
• yes, that would be correct. You might want to initialize it with a createLookAt before the game loop starts just to place it where you want it. Oct 8 '11 at 12:39
• Yep, this works brilliantly, thanks. What I actually ended up doing was adding a CreateRotation(float pitch, float yaw, float roll) function to my matrix class and in there I calculate the axes for each ie: Vector3 xAxis = Vector3::UNIT_VECTOR_X * pitch; then calculated the arbitrary axis and rads as you suggested and called my CreateRotate(arbAxis, rads) etc. Oct 9 '11 at 14:14
• @ Steve H re precision: it all depends on the matrices - you are right that for small, local-ish transforms rounding errors are essentially a non-issue. However, for more generic transforms which use large-ish values (e.g. > 100k decimal) it can be easy to introduce rounding problems from multiplying those large numbers by small values as part of rotation. It only takes some 50 muls by values near zero or one to utterly destroy an appropriately sized float's precision. + Well done on the answer, pretty much exactly the same as mine but worded better with a clear example. :) Oct 10 '11 at 17:17

One way around this problem to allow the view matrix to be kept from frame to frame instead of yaw, pitch and roll.

The idea behind doing this is that you can multiply the matrix by rotations around each of the three axes encoded in the 3x3 "rotation" part of the transform matrix to change yaw, pitch or roll incrementally. Because you continually apply small rotations using the ever changing local axes you will avoid gimbal lock - the camera won't suddenly flip upside down because the changes to the "up" vector part of the view matrix is always changing smoothly in small increments.

There are drawbacks however - you may need to orthonormalise the matrix to prevent distortion from the accumulation of rounding errors. At very low frame rates you might get unexpected results depending on the order in which you do the three rotations (e.g. if you get a single frame with such a big change in orientation that you still get gimbal lock).

• So you mean alternate which axis I rotate each frame but only actually rotate one of them? That seems a bit messy. Oct 7 '11 at 16:28
• No. This is not what I mean at all. I mean rotate by all axes each frame - but the axes local to the camera instead of the world space axes. This is exactly the part of this which eliminates the gimbal lock problem described. Oct 10 '11 at 17:15
• In fact the answer above describes exactly what I describe just much better, with clearer language and a concrete example. Oct 10 '11 at 17:17