I am trying to write my first game, and want to create a simple airplane / flight type of game. I have been brushing up on my vector math but am getting stuck. At this point I'm just working out some pseudocode so I can just get an airplane flying around the world. Here's the basic idea of what I am trying to do:

My airplane will start out flying level and I will be able to start with up, right, and forward/heading vectors. On each frame the plane will move along the forward vector to its new position. If the user inputs up/down the pitch will be affected by "n" degrees, and the same for left/right and the roll affecting the up vector. I am planning ahead for yaw, though I haven't worked out the user control yet.

So I am trying to figure out how I update the up/right/forward vectors based on the degree of rotation. I have found lots of information about how to calculate the axis or the angle of rotation. Perhaps I am going about this in a harder way than necessary, but I know how I want to use these vectors and am sure it will work once I figure out how to calculate the new vectors.

I am using Opengl (Android) and want to use the gluLookat function. It simply accepts values of eyeX, eyeY, eyeZ, centerX, centerY, centerZ, upX, upY, upZ. Obviously I will need a new up vector here for each frame, and of course my airplane will not always be aligned with the world up vector. Calculating the other values I have solved, based on knowing the updated vector.

I will simplify my question to just one rotation. I have a forward, right, and up vector. I receive input to move pitch up and I know the number of degrees. My rotation axis is the right vector. Given the rotation axis and amount of rotation (in degrees), how do I find the new up & foward vectors?

The 3 vectors together build up the basis of a rotation matrix. Using e.g. column vectors and the 4th component for the homogeneous coefficients, the first 3 column vectors of a rotation matrix are just the vectors you're looking for. So applying a (delta) rotation matrix onto a (orientation) rotation matrix will yield in another (orientation) rotation matrix where you can simply pick the resulting vectors from. In fact the whole thing is nothing else but rotating the current state of vectors to yield in the next state of vectors.

With a rotation axis and angle you have all parameters of the so-called axis/angle rotation representation. The internet (e.g. euclideanspace.com) tells about conversion, e.g. to a rotation matrix.

I will need to brush up on my matrices before I get going. Several of the sites that I found were leading me toward using rotation matrices and I guess I just was avoiding them. The opengl documentation is what has made me shy away from using matrices. I suppose I can setup a class for the matrix math similar to the one I am using for my 3d vectors.

So if I setup a rotation matrix do you know if I can just apply it to my code with an opengl call? I was looking at glMultimatrix and it seems like that may work. Or would it be better to just compute the matrices and extract the vectors, then use them in my code as I was already intending?

Well, I will get in some studying and probably test out both ways. I will report back if I have any serious struggles. Thanks again for your help.

So if I setup a rotation matrix do you know if I can just apply it to my code with an opengl call? I was looking at glMultimatrix and it seems like that may work. Or would it be better to just compute the matrices and extract the vectors, then use them in my code as I was already intending?

Provided it's arranged in memory the way OpenGL expects (that is, the data occupies a contiguous block of 16 elements and the elements of each basis vector appear consecutively), you can upload the matrix directly using glLoadMatrix*() or glMultMatrix*().

Well, I got the matrices figured out and was able to build some basic rotation matrices. I built one for each axis and they work when I call glMultimatrixf. I am still running into the same problem which is where my original question lies. Basically, if I were to say pitch up/down to start, everything works fine because my rotations are around the x axis. However, if I try to then roll, I rotate around the z axis. But the z axis is no longer the roll axis/vector, it is still the world z axis. From lots of reading I believe this is gimbal lock, which I understand to an extent.

So how do I update the actual forward/up/right vectors and rotate around them. I'm sure I can figure out the math behind it, once I know the right steps to take. Also, the matrices I used for rotation seem to be locked to rotate around the world axes. It seems I should be using a matrix that would rotate around an arbitrary axis. I'm just not sure if this would be the right solution, or if more is needed to update the vectors.

Here is a bit of the code I am using that I think should work. Maybe someone can tell what I am doing wrong. At this time I am just trying to draw my airplane, pop/push the matrix. Then rotate, draw the ground and sky. This way my airplane stays in the center and the world moves around. I have two matrices. One called mOrientMatrix, which stores the current orientation. The other is mArbRotMatrix, which is a rotation matrix for an arbitrary axis. The void setRotPitch() rotates by the angle (pitch/yaw) around the current vectors from the mOrientMatrix. Then the mOrientMatrix is updated with the values produced.

If I only make one rotation, the code works as expected. However, as soon as I make a second rotation the axis is incorrect. (For whichever comes last in the code, pitch or roll)

I got it working now! There were two main problems with the code above. First the pitch/roll values were not needed to be added on every input. They should be =0.01f or =0 dependent on input. (not +=0.01f) The second problem was that I was making the mOrientMatrix = mArbRotMatrix, when I should have been multiplying them together. Though I had tried this, I finally realized that I had transposed my matrix multiplication, therefore getting incorrect values in return. Coupled with the first problem any time I tried a multiplied matrix I was getting very strange rotations. Once I fixed both of these everything fell into place. I actually ended up removing the two rotation on arbitrary axes, and used on combined matrix for rotation on x,y,z axes. I added a translation matrix and got that working as well. Finally I am able to fly around my world, even straight through the ground. I guess I am ready for some collision detection.

I got it working now! There were two main problems with the code above. First the pitch/roll values were not needed to be added on every input. They should be =0.01f or =0 dependent on input. (not +=0.01f) The second problem was that I was making the mOrientMatrix = mArbRotMatrix, when I should have been multiplying them together. Though I had tried this, I finally realized that I had transposed my matrix multiplication, therefore getting incorrect values in return. Coupled with the first problem any time I tried a multiplied matrix I was getting very strange rotations. Once I fixed both of these everything fell into place. I actually ended up removing the two rotation on arbitrary axes, and used on combined matrix for rotation on x,y,z axes. I added a translation matrix and got that working as well. Finally I am able to fly around my world, even straight through the ground. I guess I am ready for some collision detection.

Thanks again for the pointing me in the right direction!

Coolness, I'm glad you got it to work!

I have a tremendous favor to ask you... Could you post the code that made it work? I'm stuck on the same thing for my own game and I can't figure out how to get the rotations to work correctly. Right now I'm getting your 'very strange rotations' (I've been stuck on that for a week), and I'm doing the yaw/pitch/roll arbitrary axis matrices while multiplying all the matrices together. Thanks for the info!

Nevermind about posting your code, I just got it to work. Thanks for the explanation, it really helped out! It's pretty cool how things go together when one thing is changed, heh! I had a few numbers completely wrong (treated a column matrix like a row matrix - ooooops!) but once I played around with it, it all worked out. Thanks for sharing your success!

Well, I thought everything was working right, hopefully you are not running in to this same problem I now have. Hopefully someone is still listening. Everything looks fine except for the speed. I am using a constant value for speed, but of course I want to be able to change the speed. Even with the constant speed, after about 30 seconds I notice speed building up. After about 1 minute it gets really fast and soon its uncontrollable. Maybe I still don't have something quite right.

Here is some code-

At the end of the onDrawFrame I call this sequence to create a newRotMatrix, which is called with glMultMatrixf(newRotmatrix, 0) just before I draw the ground and sky.

The resulting values of my mTranslatematrix give constant values based on the speed. However, when they are combined with the current orientation they multiply slowly, but exponentially.. I logged the value of each, just to make sure I wasn't imagining something, and found the [12],[13],[14] values for the transform matrix to be constant with the speed. The values of the newRotMatrix do increase over time as I was seeing in the application. Everything I have read is telling me to do it this way, and I can't find anything on the web with a similar problem. I'll keep trying but so far everything I change makes something else stop working right.

I heard from some of the other math experts (I'm definitely not one of them, lol!) that floating-point imprecision can cause that to happen. The trick is to re-orthogonalize the rotation matrix. I'm using a different sized matrix (3x3 matrix), but you should be able to modify the below code and get it to work in your project:

If you plug in this code and notice nothing except your speed errors are gone, then it worked! If the visuals go all over the place, I probably got a couple of matrix elements inverted or something like that and some simple tweaking should get it to work (I translated from my own variables to something more understandable before posting the code). Anyway, I was told that this code doesn't have to be executed on every frame, so you can make a call to this code every now and then (every ten frames?) or perform some low-cost calculations to see if an axis has gone out of tolerance.

Hope that helps! I'm still pretty new to this, so please let me know if it works!

EDIT: I plugged in this code after I updated the old orientation matrix with the new values, just before I put things on the screen.

Thanks HobbyDude! I will try this when I get home. Before I left I tried removing the addition of mTranslateMatrix[12],13,14 in my setTranslateMatrix(). It seems to have slowed the speed increase, but not eliminated it. Hopefully combined with the code above I will get rid of it. I also read that this could happen and the need to reorthagonlize is not necessary on every frame, maybe every hundred or so. Some basic code can check for the values being within a tolerance. If you are within tolerance, then don't do it to save some computation time.
Thanks again, I'll update with my results later.

I will need to sit down and rewrite the reortho myself. For now it seems that my change to setTranslateMatrix() did the trick.

The new code would look like mTranslateMatrix[12] = (float) (x * dist);

The same for [13] & [14], with y,z values. (All other values are just from the identity matrix). I believe the addition I thought needed to be there is actually happening when I multiply the matrix by the current orientation.

The re-orthoganalize code doesn't work if I just plug it in. I think you may be using row major matrices, while mine are column major (openGL). I tried some simple adjustments but no luck. Like I said I'll just rewrite it, its just a matter of multiplication order and matrix order and I'm sure it'll go easier if i do it by hand myself.

Please notice that inaccuracies ever occur when concatenating enough transformations. You may consider to switch from concatenating rotation matrices to concatenating quaternions. The are less prone to failure accumulation and their re-orthonormalization (yes, just that) is much more simple. However, it comes with the costs to do a conversion.

Just to clarify: Rotation matrices need not only be "re-orthogonalized" (i.e. their vectors need to be enforced to be pairwise orthogonal) but "re-orthonormalized" (i.e. they also need to be enforced to have unit length). Only a orthonormal matrix is guaranteed to be a pure rotation matrix. The code snippet actually does a re-orthonormalization (AFAIS), and I just wanted to clarify that the term used for it is not exact.

...The re-orthoganalize code doesn't work if I just plug it in. I think you may be using row major matrices, while mine are column major (openGL). I tried some simple adjustments but no luck. Like I said I'll just rewrite it, its just a matter of multiplication order and matrix order and I'm sure it'll go easier if i do it by hand myself....

Also for clarification: "Row major" and "column major" are terms to describe how the elements of the 2D matrix are arranged when stored in linear (i.e. 1D) memory. Hence you probably mean "row vector use" (e.g. D3D, like in v * M) or "column vector use" (e.g. OpenGL, like in M * v) instead, what plays a role how the terms of a matrix product are to be arranged.