I have a rotating object working which works via (pseudocode, not near my code atm)

I was thinking I initially could use glLoadMatrix(my_starting_orientation_matrix) instead of the latter glMultMatrix, but if I load a rotated matrix, then the following translations will be applied to the rotation won’t they ?

So for example, if I have an object that I want to rotate by 90 deg every draw (as its facing the wrong way), is it possible to start off with a loaded matrix that re-orientates itself always by 90 whatever, and not affect the translation that follows ?

So in my head I want to do…
glLoadMatrix (matrix_that_will_rotate_object_by_90) //starting orientation
glTranslate //where I’ve moved to
glRotate(x,y,z) //where I’ve just turned facing to

The glLoadMatrix then sends translations over the new rotation (which makes sense). Is it possible to avoid that ?

(just to clarify, after loading a matrix that does a rotation by 90, if I then translate down the z axis which works with a latter MatrixMult, it “looks” like it translates down the x axis if I do a former LoadMatrix)

you would have to do

or better yet, get rid of all that and generate your own matrix and upload with glLoadMatrix. There are a few nice matrix lib floating around.

The way matrices are applied is “backwards” if you want to think about it that way. Your vectors will be used as column vectors, so the matrix goes to the left of the vector when you multiply it.

When you chain transformations, they are multipled with the previous matrix but the effect is as if the transformations where done backwards. I… think it’s easier to just see it like this:

T1 * T2 * T3 * T4 * vector = transformed_vector

Where T1 to T4 are transformations. If you start with T1 and apply further transformations to the matrix (T2…T4), all you do is accumulate them until you actualy apply the transformation to the vector itself. So as you can see, it’s escencialy applying T4 first, then T3 and so on.

If you are educating yourself and not going through a time constrained project, I’d recomend you do your own matrix library and make it work. That way you’ll understand all this much better. Reinventing the wheel is normaly a waste of time, but fundamentals are important.

Hi V-Man and Ed. Many thanks for your replies. They both make perfect sense. I will certainly try that. I feel like an idiot, I always assume a load comes first :slight_smile:

For the matrices and learning them. I’m not sure I’m seeing the advantage. So would I…
Calculate physics movements…
calculate translations for object, store them in a matrix.
Calculate rotations for object, store them in a matrix.
Multiply them in correct order to get final matrix for object.
Later, render using loadMatrix ?

This feels that its more processing than not creating the matrices, and just doing a rotate/translate at render time. I certainly do see it will help me with understanding the whole process though, so I think I will have a bash.

I’m just trying to see if there is a reason to do it this way for optimising code, or if its more for understanding it ? Is it faster this way for some reason ? (Thats if I understand what you are meaning!)

Sorry. That doesn’t any sense at all. glLoadMatrix replaces the matrix.

Aha, thats what I’ve just found when testing. I thought it made sense when explained to me, but I think that would be if it was MultMatrix, which is the bit I already had working. I was wondering if it was possible with LoadMatrix and follow on from there with a translation.

So now I’m unsure again, if what I was trying to figure out is possible? I’ll do some digging on matrices in the meantime thanks.

Ofcourse it’s possible, but the problem is that the order in which you apply matrices is important because it determines what the rest of the operations you do mean.

Using a matrix transformation is changing the object’s coordinate system; the reference point and orientation. When you build the matrix of the transformation, you are just doing that: generating a reference frame. After you are done composing the matrix, it’s used to multiply (transform) the vectors and move their values from model space to world space (or whatever space, but thinking of world space as a general intermidiate space will help).

There’s two ways to read the matrix transformations that you have applied. Left to right or right to left. Even if you know that mathematicaly your transformations will be applied from right to left you can still read them left to right and understand what’s happening. The key here is to interprete them correctly.

Assume this chain:


Which would read like this:

R * T * vector = transformed_vector

  1. Interpretation from left to right:
    Think of each transformation as being applied to the object’s local axis. In a stasis state, the local object axis will be aligned with the world axis, so Z- is behind, Z+ in front, X- to the left, X+ to the right.
    If you read the transformation as a rotation first, then think of it as rotating the complete package: the axis and the object. Thus, after the 90º rotation the Z-/Z+ axis is no longer aligned with the world’s Z; you just rotated the reference. It’s, in fact, aligned with the world’s X axis.

So you read the translation after after, which says “move back 100 units in Z”. This Z, however, refers to the previously rotated object which included the axis reference! So yes, it will go “back 100 units” but in its own axis, which will be the same, in this specific case, as moving it -100 units in world space’s X axis.

  1. Interpretation from right to left:
    If you read them backwards (in the same way as they are multiplied), you can think of transformations as always being applied in world space and always referencing the world space axis. This is probably what normaly people learning how to use these things think it’s happening when they read them forward and obviously it becomes confusing.

So if you read the translation first, you can think of it as moving -100 in world Z. Easy enough.

Then when you read the rotation, think of the object, which is displaced to -100, rotating using the world axis as a reference. So it will not spin in its own object axis but instead rotate around the far away center, like the earth around the sun.

Just to reiterate, these two ways of thinking are just that: ways of envisioning what’s happening. The transformation I applied them to is exactly the same.

Obviously, if you change the actual order of the transformations then you are effectively changing the result.

So to answer your question, yes, it’s obviously possible to have a “base transformation” and then work applying transformations after, but then the order and values of those transformations will be dependant on the original base.

As for this:

For the matrices and learning them. I'm not sure I'm seeing the advantage. So would I...
Calculate physics movements..
calculate translations for object, store them in a matrix.
Calculate rotations for object, store them in a matrix.
Multiply them in correct order to get final matrix for object.
Later, render using loadMatrix ?

GL matrix functions are not helping you at all. All they are doing is hidding a beast you’ll eventualy have to face if you wish to continue doing anything in 3D. Manualy doing matrix calculations does not take longer than using the gl functions (bare some possible processor optimizations by the drivers, I guess) and definitely do not aid you with learning.

Personaly, I would just say that learning directly using core 3.3 is better, since it removes a massive amount of the clutter the API had and forces you to do things manualy, which means you must understand what you are doing.

Alas, it’s up to you how you aproach this.

Thanks Ed, I’ll do some digging into coding matrices.

Do you know any sites that have a good tutorial on using matrices in respect to OpenGL games (rather than OpenGL matrix functions)? Or fairly easy to read code. I see a lot of sites with Matrix math, but does my head in a bit :). I think I would learn better by looking at some example code in how its used to keep up to date information.