Reason why opengl transform in reverse?

OpenGL matrices aer columnn major, when multiplynig two column major matrices A and B you hey: A*B in this order. When you multiply a vertex by A*B you get
A*B*v, this means that matrix B will affect first the vertex v and then matrix A will contribute to v, in this order.

When applying transformations like glRotatef you multiply the stack matrix with the rotate matrix and so for example you obtain this:

current stack matrix = I3.

glRotatef(90, 0,1,0); I3 * rotate
glScalef(1,1,0.5); I3 * rotate * scale;

And that's how the matrices are applied in reverse order considering the order you type the transformations.

[Edited by - Deliverance on February 7, 2010 8:32:43 AM]

The order of transformation is just an interpretation of intermediate steps of a sequence of several transformations, and nothing related to OpenGL.

If you look at an object and transformations as being applied to the object's local coordinate system, they behave as if the transformations are applied individually in reverse order as they appear in the code. You can also look at transformations from a global coordinate system perspective, and then the objects appear to be transformed in forward order as they appear in the code.

So it is only about how you interpret the code and transformations. As far as OpenGL is concerned, there is a single matrix, and coordinates are multiplied by that matrix (considering the object and viewpoint transforms, so the modelview matrix concept only).

There are only two things that concerns OpenGL; that is the initial coordinate and the final transformed coordinate. If you need to interpret each individual steps, you concern yourself with intermediate steps, but OpenGL doesn't.

Mathematicians transform points as OpenGL does. So, it's DirectX who do it in reverse. Even if we usually work with affine transformations, which can be represented by 4x4 matrices, general transformations aren't matrices. They are functions from a space to another. A simple example of non-affine transformation is this. So the composition of transformations should follow the conventions of composition of functions: if you have two functions f and g their composition is the function (f.g)(x) = f(g(x)). In your case, if S is the scaling and R the rotation then (S.R)(P) = S(R(P)) which is the rotation followed by the scaling. Hope it make sense for you.

That way you can build hierarchical renderings:

For example you have a car with four wheels.

In real life (I mean the non-reversed order):

transform_wheel (its rotation, and steering)transform_wheel position (put the 4 wheels to the 4 corners)transformation_of_car_in_worldcamera_transformation.

So if you want to draw the wheels, you have to traverse trough all transformations to get the final transformation.
If you want to draw the body of the car: traverse through the last 3 transforms, and so on.

in opengl:

camera_transformationdraw_worldtransformation_of_car_in_worlddraw_car_bodypushtransform_wheel_1 position (put the 4 wheels to the 4 corners)transform_wheel_1 (its rotation, and steering)draw_first_wheelpoppushtransform_wheel_2_positiontransform_wheel_2 (its rotation, and steering)draw_second_wheelpop

...

So if you build the hierarchy well, you don't have to traverse through all transformations for every single objects, only have to multiply with the local transformation of the current object, and use the matrix stack (push/pop).