I am building a demo where the camera is always moving. Is it more efficient to move the camera every frame (gluPerspective, gluLookAt) or move and rotate the world to the current ‘eye’ position every frame?
There is only one way to do it, and it is to move the world around the viewpoint. There is no such thing as a camera, only a viewpoint. gluLookAt moves the world around this viewpoint.
You should be carefull with high values in the vertexes! I had some effects like texture-distortion.
So I would say You should move the world to set the Vertex-values near to the camera low.
[This message has been edited by TB-Rex (edited 10-30-2000).]
However, when you do view frustum culling,
you should probably test the untransformed
world data against a transformed “camera”
to avoid having to transform all of the
world data just for culling.
What do you mean “nop such thing as a camera”? Camera are modelled in OpenGL. It models them in a similar, albeit subtly different, manner to other camera models, like those used in 3D Studio, POV-Ray and the entire field of computer vision…
the projection matrix is the camera model. It defines a focal length, retina plane, view frustum. What more do you want? In-built flash?
cheers,
John
What i mean with “no camera” is that there is a modelview matrix transforming every coordinate you pass. After the transformation, all vertices has been transformed so they are all relative the world origin. This wouldn’t be the case if there was a camera you could move. Then you would move the point of view, and not the objects around this point.
Yes, 3D modelers got cameras. You place the geometry all over the scene, but no matter what camera you choose, their coordinates is still the same.
And yes, the projection matrix can be called a camera, but this is after the modelview matrix is applied. You can translate this matrix the same way you translate the modelview matrix, and the result is the same. But not until then you can talk about moving the camera. No matter where you place this projection matrix, the coordinates is the same after modelview matrix. But you shouldn’t touch the projection matrix, it can screw up some things, and this kind of problem can be a pain to find. And if you got a fixed camera you shouldn’t move, then why talk about one?
I just think we got different oppinions on what a camera is.
For all intents and purposes, camera == world in OpenGL.
The only real difference is your way of looking at it. The only physical difference is an inverse coordinate system between the two, and this difference is essentially negated out because its symmetrical in all aspects.
Thus, if you move the camera toward an object, its identical to moving the object toward the camera by the same amount.
I know you all know this, or at least you should. The people that don’t, yep, its hard to get used to but its true! 
Siwko
Yepp, I agree with ya. It’s just a matter of how we look at it. Personally, I think it’s more correct to see it that we move the world, because this is what we do with the modelview matrix, we transform all incomming coordinates. Anyways, how you look at it is out of my interest, and I accept people got different oppinions. Not going to argue about that.
But as you say, we should be aware that whatever method we use (moving the camera or moving the world), we have to do it the same way, using the same commands, and getting the same result. The only difference is how we interpretate the commands when reading the code.
Maybe this makes it easier to get used to:
Imagine you sit in a car on a red traffic light and the car in front of you starts rolling backwards slowly. That’s something that has probably happened to everybody once, and probably everybody has slammed his foot on his brake on that occasion - because, if you only watch the car in front of you, it’s impossible to tell if the car in front of you moves backwards or if your car rolls forward.
That’s relativity, every movement of one point A in a system can be represented by the movement of all other points in the system relatively to point A (unless one of the points is moving with light speed, but that’s a different story).
John, In OpenGL you only have one viewpoint (“camera”) which is nailed, glued and stapled to the coordinate origin (0|0|0). If you want to move the camera by 5 units in positive Z direction, the result is exactly the same as if you move the world by 5 units in negative Z direction (imagine the viewpoint being one car and the world being the other car at the traffic light).
And because the math that projects the 3d world on a 2d screen can’t really make any use of a movement of the viewpoint only, OpenGL will move the world with the translate and rotate functions. So will every other 3D library, API and routine - if one provides camera movement, then the camera movement is just recalculated into world movement before the actual transformations are done.
Hope that was understandable 
IMHO, there is a camera in OpenGL. In all my OpenGL apps, I change the projection matrix to set the camera, and the modelview to set world geometry. It makes life much easier for me. I can’t understand how that can be more complicated than just using the modelview matrix for everything.
Hello,
firstly, I appreciate that we are really all agreeing on the same thing, but just have different opinions on thing (re: Bob).
I agree that OpenGL doesn’t specify transformation in the projection matrix. Rather, all verticies are transformed by the modelview matrix first. But, when you look at the expanded equation, then we’re really talking about the same thing, and in the end, we still have a camera.
For example, supppose I do this:
glFrustum(…);
glLoadIdenity();
gluLookAt(0.0, 0.0, 5.0, 0.0, 0.0, 0.0, 0.0, 1.0, 0.0);
glTranslatef(0.0, 0.0, -5.0);
glutSolidCUbe();
then we all agree that we’re effectively looking at a cube 10 units away from us. The geometery pipeline looks like this, then:
v’ = P I L T v;
where:
P = Projection matrix (frustum)
I = Identity (since we loaded it=)
L = the lookAt Matrix
T = the cube translate matrix
and v’ and v are the image and world points of the cube, respectively.
yes, i conceed that this is modelled in OpenGL as Projection = P and modelview = ILT, but that’s only because OpenGL rips extra information from the P matrix. okay. yes, we’re talking avout opengl here, but bear with me.
In some other field where people are more liberal with their projection matricies, then they might say they could have their projection matrix as:
Proj = PIL (ie. move the camera and then project) and
v = Tv (ie. we don’t “move” verticies, they’re just in the world coordinates like that, always)
but… this is STILL the same projection equation, ie. v’=PLTv. we’ve just given different names to things…
so, my argument is this: just because we seperate the camera lookat transformation from the projection matrix doesn’t mean we don’t have a camera, or that our camera is nailed" down and magically turned into just a viewport. Graphics guys just think of more coordinate systems because the matricies are decomposed (ie. world to eye to image), but this doesn’t change the analogy of a camera with a specified focal length and retinal plane modelled by a projection matrix.
it’s just a matter of opinion in the end.
cheers,
John
Whatever. I won’t try to change you oppinion, and I guess you won’t change mine. As long as it isn’t only a question of interpretation, it’s useless to go on.
But to you Antonio: I must say that you shouldn’t do any kind of movements at all in the projection matrix. This is because some kind of features is depending on the total movement in the modelview matrix. It’s things like lightning and fogging, and if you do some of the movements in the projection matrix, you won’t have all transformations in the modelview, and therefore some of the above mentioned features might look strange. As long as you don’t need them, or in your particular case they occur properly, it’s OK. But IF they fail, I guess you will have a hard time finding the source.
to Bob: Yes you’re right, I confess that I wasn’t thinking straight. Nevertheless I still believe that there is a camera in OpenGL but as you pointed out this disscussion is pointless because its just a question of interpretation.