but regardless, that doesn't seem right. OpenGL performs the transformations in the reverse order of when you specify them.

Say you start with the model View matrix as the Identity. Then you specify a rotation matrix R, a translation matrix T, ands a scaler matrix S, in that order. Each transformation right multiplies the new matrix by the old one, so we get: (R*T*S) as our modelview matrix.

If we had to left multiply a 4vector V (or rather, a 1x4 matrix) by this matrix, V(R*T*S), that would result in the transformations occurring in the order in which they were specified, and not in reverse, which is not how its supposed to work. Unless perhaps, the reverse order process is not used for the Projection Matrix.

]]>glPushMatrix();

rotate object at origin;

translate object to the position you want;

glPopMatrix();

glPushMatrix();

now work on your next object;

...

glPopMatrix();

And so on. The functions involved give a view of what is actually going on in the computer. Moving points in space is always done by multiplying a coordinate by a matrix. All movement functions are done by matrix multiplication. Translating then rotation is done by multiplying a translating matrix by a rotating matrix. pushing the matrix in effect saves the "movement" matrix where you are currently at, then you make changes to it by multiplying by other matrices. Popping takes you back to that saved state.

PS: What is the proper word for "movement" matrix? I know there is one...

]]>But surely you would know the translation required already and do it first before doing any rotations?

pooossibly! But one thing I like making is a robot model that can be positioned based on a set of angle parameters. When updating its position, I would basically assemble each piece in a series of rotations and translations. For instance, you would rotate the forearm by say, leftElbowAngle, and then move it onto the bottom of the upper arm, and then the two of them would be rotated by leftArmShoulderAngle. The entire upper body could be rotated about its waste, and finally the entire model could be rotated and shifted to its appropriate location.

Now according to that, if different parts of the body are rotated at all these different angles, then calling glTranslate to shift its location would send them off in all different directions.

now i MAY be able to reorder it so that every piece is rotated before its translated, I just suspect that in certain scenarios, you might need to shift after rotating, and it would be a nightmare.

]]>anyways.

float cmat [16];

glGetFloatv(GL_MODELVIEW_MATRIX, cmat);

glLoadIdentity();

glTranslatef(...);

glMultMatrixf(cmat);

However, constantly retrieving the modelview matrix might have a performance impact. But surely you would know the translation required already and do it first before doing any rotations?

I personally don't like openGL for its ordering, i.e. if you have

glTranslatef(...);

glRotatef(...);

glScalef(...);

that means its going to scale it, then rotate it, then translate it. which is kind of counter intuitive i think

]]>One thing I read today is that when doing model rotations, you effectively rotate a models coordinate system. This means that when you use GL translate to shift the model over, say by a vector of (1, 0, 0), it gets shifted by that vector, relative to its new coordinate system.

That sounds like a hassle to me. Say you had a 3d object thats been rotated several ways, and you want to transfer the object onto say.... a table, by shifting its location. You'd have to calculate the coordinates of the table with respect to the objects weirdly rotated coordinate system, and that sounds unnecessarily complicated for such a simple thing.

Is there a simpler way to move an object in this fashion?

]]>