3
votes

I've read through several over-complicated articles on rendering a 3D scene with OpenGL, and haven't really found something that helps me to visualize the basic concepts of scene navigation with respect to glRotate and glTranslate calls.

From experimenting with the examples provided by LWJGL (my particular OpenGL library), I understand very basically what effect comes of their use. I can use glTranslate to move to a point, glRotate to rotate about that point, and glLoadIdentity to snap back to the origin or glPopMatrix to go back to the last glPushMatrix, which are essentially snapshots of a location and rotation. Finally, the scene will render to screen with respect to the origin.

So basically, to put a cube at point A with rotation B:

  1. glTranslate(A.x,A.y,A.z) [now focused on point A]
  2. glRotate(B.,,*,*) for pitch, yaw, and roll; [now rotated to rotation B]
  3. glBegin(GL_QUADS) and glVertex3f()x4 for each 'side'(quad) relative to object's origin
  4. glEnd()
  5. glLoadIdentity() [reset to origin for other objects, not needed if only drawing the cube]

As for the "camera", since openGL's "eye" is fixed, the scene has to move inversely from the camera in order to simulate moving the eye with the camera. This is my understanding so far, and if this is wrong, please put me on the right path.

Now for my specific situation and question:

My 'scene' consists of terrain and a player (some arbitrary shape, located at a terrain-relevant location and a 'camera' head). The view should rotate with respect to the player, and the player move with respect to the terrain. I want the final rendering to essentially "look through" the player's head, or camera. My confusion is with the order of translate/rotate calls for rendering each part, and the direction of translation. Is the following the proper way to render the terrain and player with respect to the player's "camera"?

  1. translate away from the player by the player's distance from origin (move the scene)
  2. rotate away from the player's rotation (player looks 40 degrees right, so rotate scene 40 left)
  3. render terrain
  4. reset via glLoadIdentity
  5. render player's head (if needed)
  6. translate to body/hands/whatever position
  7. rotate away from the player's rotation (step 2 again)
  8. render body/hands/whatever

Also, does rotating have an effect on translation? Aka, does OpenGL translate with respect to the rotation, or does rotation have no bearing on translation?

1
As is natural in the beginning, the approach seems correct, but you are complicating things. I think you must first understand the concept of viewport, projection and modelview... all becomes simple after you understand those... Try searching for those keywords...Jorge Leitao
You might also try some experiments in 2D to get comfortable with rotation vs. translation, where it might be easier to see what's going on. In general, you want to do rotation at the origin, and then translate. If I want to draw a solar system, and have the moon going around the earth, I move the earth to the origin, place the moon a certain distance from it, rotate the moon around the earth, and then move (translate) the whole earth-con-rotated-moon package to its proper place in the solar system.M Katz
From what I've read, projection is basically your depth and field of vision, while modelview is your position and rotation within the 3D world. The viewport is how it all comes together, the 2D plane that the 3D objects are mapped to. The translation and rotation calls are all within the modelview, but the way they interact with each other is a bit of a mystery to me.user1363917
@MKatz - That makes sense. Up until now, my 2D overlay rendering has been all vertex-based without translation, but I'll test out some translation/rotation calls to see what exactly is going on, and then see if I can apply that to the 3D scene.user1363917

1 Answers

1
votes

I can use glTranslate to move to a point, glRotate to rotate about that point, and glLoadIdentity to snap back to the origin or glPopMatrix to go back to the last glPushMatrix, which are essentially snapshots of a location and rotation.

No not quite. Those functions have now idea of what a scene is. All they do is manipulating matrices. Here's an excellent article about it:

http://www.opengl.org/wiki/Viewing_and_Transformations

One important thing to keep in mind when working with OpenGL is, that it is not a scene graph. All it does is rendering flat points, lines and triangles to the framebuffer. There's no such thing like a scene you navigate.

So basically, to put a cube at point A with rotation B: (...)

Yes, you got that one right.

As for the "camera", since openGL's "eye" is fixed

Well, OpenGL got no camera. It's only pushing vertices through the modelview matrix, does lighting calculations on them, then passes them through the projection and maps them to the viewport.