OGL doesn't apply transformations in reverse/backward order. The point is that OGL by itself does allow only to multiply from one side (as oppsite to D3D, as Trienco already stated). All this is in fact only a question of matrix algebra. So this could be expressed fine the following way:

Lets assume using column vectors. Looking at vector algebra, this means that the current MODELVIEW matrix M is replaced by
M' := M * T
where T denotes any new transformation suppied to OGL (by either glMultMatrix, glRotate, glTranslate, or glScale). It comes out that transforming a vertex position under this circumstances looks like
v' := M' * v = ( M * T ) * v = M * ( T * v )

Although actually OGL stores and applies M' (say the concatenated matrix) only, you can see that the _effect_ is mathematically the same as like T applied to v, and then the former matrix M applied to the result of T*v. One could say that T is a more local transformation as M is.

The same argumentation yields in the answer of how to order scale, rotation, and translation usually. To have lowest effect of the transformations to each other, the mesh should be scaled in its local system (since scaling in local system doesn't change the local origin nor the local orientation), then rotated around its local origin (since rotation doesn't change the local origin), and then translate it. As you see here, each next step has lesser local parts that it left uneffected. So, in the above writing
T := P * R * S
where P denotes the translation ("positioning", since T already denotes the total transformation), R the rotation, and S the scaling.

So, if you use OGL to build the new matrix M'
M' := M * T = M * P * R * S
from the current MODELVIEW matrix M with such a transformation above, simply invoke OGL by going from left to right along the formula. With M being already stored in OGL, of course, you have to choose the order of invocations
glTranslate(...);
glRotate(...);
glScale(...);

(In the following I'll try to be nit-picking once more, since the problem may need some precise terminology to be understood?!)

Quote:Original post by Cacks
Lets say I'm going to have a scene, that contains bricks. I use gluLookAt that effectively sets my camera view. Each brick has local coordinates, which are their vertices.

Just to clarify: The scene (say the world at a specific moment of time) consists of a wall. The wall consists of some bricks. Each brick is given by an own model, having its own mesh and material. Hierarchically the bricks are part of the wall, and the wall is part of the world. In this sense the wall at a whole, even if not having an own mesh (no own vertices), could have a specific origin placed in the world, and an orientation w.r.t. the world. This origin and orientation together is the wall's local co-ordinate frame. It is often visualized by a 3D Cartesian axes cross in modelling applications. Now, each particular brick in the wall could have its own co-ordinate frame, too. However, instead of relating the origin and orientation to the world, you could relate it to the frame of the wall! Due to this, translating the wall will translate all bricks immediately also, since the bricks depend on the wall. Now, one step deeper, the vertices of the mesh of a brick are related to the local co-ordinate frame of the brick. So, translating the brick means to translate its mesh also. Please notice the hierarchy in this stuff; it is called the "forward kinematics chain", since changing a more globalframe implicitely affects also the related, more local frames.

So precisely, the vertices of a brick _are_ not local co-ordinates, but their co-ordinates are given relative to a local co-ordinate frame. That is why is is also named MODEL co-ordinates.

Quote:Original post by Cacks
I draw each brick in world coordinates using glTranslate & glRotate.

Also this is a question of exact terminology. You push vertices in their local co-ordinates into OGL, so I would say you draw it in local co-ordinates. But due to the fact that you have set-up the MODELVIEW matrix, OGL transforms the vertices from the local/model co-ordinates on-the-fly into view co-ordinates. That is why that matrix is named MODELVIEW matrix: from model (local) co-ordinates to view co-ordinates.

Quote:Original post by Cacks
The viewing transformations must be specified before anyother modelling transformations. This is because transformations in OpenGL are applied in reverse order.

Transformations in OGL are applied in the correct order (see my post above!). Due to OGL's API you have to supply the more local transformations nearer to the time you supply vertices. That is all.

Quote:Original post by Cacks
Thanks for all the help, im finding this modelview difficult to understand precisely LOL!

Don't give up, you're on the right way ;-)


Perhaps a hint: If you transform a model's mesh from the local frame to the global frame, you rotate and translate the mesh. If you think of the VIEW being what a camera sees, and you think of the camera as an object in world, please notice that the VIEW matrix is nothing than the inverse of the camera's local co-ordinate frame. Why? Because you could imagine the _world_ being translated so that the camera becomes the absolute origin, and the _world_ being rotated around that absoloute origin so that the camera becomes aligned to the principal orientation. This is just the opposite of how models are transformed.