Trying to get this right in openGL:
1) glRotate( cameraRotation )
2) glTranslate( -cameraPosition )
3) glRotate( objectRotation )
4) glTranslate( objectPosition )
5) Draw Object
is that right?
You're right about having the camera applied first and then the object transform, because this allows the usage of pushing and popping matrix states between objects.
Aside from that there is no "correct" order, other than a basic assumption that the transforms will be applied in the reverse order to which you call the matrix functions.
So if for example you do:
glRotate(Camera_Rotation) glTranslate(Camera_Position) (optional push) glTranslate(Object_Position) glRotate(Object_Rotation) glScale(Object_Scale)
The result will be that the object's vertices will first be scaled (along the local XYZ axes), then rotated (around the local origin), and then translated into "world" space. Then the world-space co-ordinates will be translated such that the camera is at the origin, and finally everything will be rotated around to the correct view direction. This is probably what you want for a basic scene.
As Richard Fabian says, you generally want to consider the camera transforms as an inverse, though you might equally replace the camera transforms with a lookAt() function or similar, to directly construct an appropriate view matrix.
If you push the matrix stack after setting up the camera, you can pop/push for each object without having to set the camera up again.
It would help if this had some proper context to it. But the general rule of thumb as far as I am aware is this:
Because a camera is usually the inverse (because the position and rotation of the camera are applied inverse to the scene to bring the scene into the camera's space) the order of the transforms is a little odd.
it's more like:
// fixed glRotate( -cameraR ); glTranslate( -cameraP ); glTranslate( objectP ), glRotate( objectR ),
EDIT: Doh, Jason is right. I'm going to blame it on not doing OpenGl in a while ;) OpenGl does indeed apply your transforms in reverse order so my original post was the opposite of correct ;) Another thing to consider is, not many people I know actually use these gl functions. Most people use a full math library once they've got started, mostly because without that you're going to be quite stuck when it comes to more advanced animations and camera paths. Also, as Jason mentions, a look-at matrix is a fundamentally more accurate description of a camera transform, so you should probably look into using matrices rather than these base functions.