I come from many moons with Pov-Ray. I'm used to the whole moving objects and cameras in 3d space.

could somebody please explain the whole translation and rotation thing in terms of "Pov-Ray", or just explain what is really going on so I can attempt to emulate a sort of "camera" in 3d space looking at objects that have coordinates relative to the origin of a Global coordinate system?

Thanks much,

matt

OKay. The point about opengl camera's is that they don't REALLY move; the whole world moves about *it*. For example, if you were in a train and could see the adjacent train out the window suddenly move, is it your train moving, or the other train moving? Physically, of course, there's a difference (you won't get to your destination if you don't move http://www.opengl.org/discussion_boards/ubb/wink.gif, but visually there is *no* difference.

With that in mind, you need to think about the camera in the global coordinate system being stuck at 0,0,0. Suppose there's an object at 0,0,-100, and you want it to appear 10 units closer to the viewer (because the user is walking towards it). In POV-Ray, you could leave the object at 0,0,-100 and set the camera at 0,0,10... which is very intuitive.

However, in OpenGL, you leave the camera at 0,0,0, but _set the object to 0,0,-90_. The visual effect is identical in both cases.

OK, another way of describing this is the fabled gluLookAt matrix. Suppose the matrix L represents the user's translation and orientation. If P is the camera's projection matrix and v is the point 0,0,-100, then in the first case we have

v=PIv

where I is the identity matrix because the camera hasn't moved. (in case you haven't done matrix algebra, I is effectively 1..., ie. xI=x for all x)

now, if we want to represent the user moving towards the object, we'd use an appropriate "camera translation" vector, L. In this case, L becomes

[ 1 0 0 0 ]

[ 0 1 0 0 ]

[ 0 0 -10 0 ]

[ 0 1 0 1 ]

you probably don't need to know how that works (although you can see the -10 in the third column...). gluLookAt will configure an appropriate transform matrix. When the camera has moved, the eqn becomes

v'=PLv

where P and v are the same as before, but the identity has changed to this new transform matrix.

Aha! you might think. the camera really IS moving. But, not really. If we wanted to move v independtly of the camera, we'd have

v'=PLMv

where M is the modelview matrix of v (representing it's independent transform). But... LM = some matrix T, and thus the maths becomes the indistinguishable

v'=PTv

ie. you can't look at that and "know" that the camera is moving or not. My point is, ultimately the camera is still stuck at 0,0,0, and the world still moves around it, regardless of how you fudge the description.

I hope this helps!

cheers,

John

Powered by vBulletin® Version 4.2.5 Copyright © 2018 vBulletin Solutions Inc. All rights reserved.