I am creating a fairly complex camera class. But before I finish it, I just wanted to know what you think is the more efficient way of handling the camera. I have heard it bandied around that moving the world around the camera, rather than moving the camera at all, is good. And other people tell me that using gluLookAt to manouvre the camera is better. What do you think? I have used both in my programs and have so far noticed no real difference in speed of the programs.

I think moving the camera is better because that way you aren''t recalculating the whole world as the camera moves. It does affect the internal calculations for rendering, but I''d rather have those calculations hidden underneath what the API does to render the polygons than to recalculate the whole world with code. Besides, eventually, the graphics cards will be doing a lot of those calculations themselves, maybe soon. So letting the API do the calculations, I think, is the best way to go.

Camera positioning is such a small part of the workload that it barely makes a difference.

i.e. w/ no scene objects, I get ~500 fps, does that need optimization? (I even extract the camera matrix once per frame)

Do what is easier for you the programmer.

I do the reverse-camera method, it is logical and straighforward to me. Glulookat is easy but limits my capabilities doing other things w/o having to then do other matrix multiplications.


> "moving the camera is better because that way you aren''t recalculating the whole world as the camera moves"

The whole world is run through the matrix anyway, no extra work doing it my way.

zin

zintel.com - 3d graphics & more or less

Moving the world instead of the camera is standard practice in computer graphics.

And after those 4 or so lines doing the reverse camera thing, everything else is normal. The more you treat lights and camera as real world 3d objects, the better.

glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
gluLookAt(0,0,0, 0,0,-1, 0,1,0); // set base eye view (I do more than this for an eye-relative x/y/z tweak)
glRotatef(-orient.x),1,0,0); // orient camera
glRotatef(-orient.y),0,1,0);
glTranslatef(-pos.x,-pos.y,-pos.z); // position camera

zin

zintel.com - 3d graphics & more or less

I don''t like how this confuses so many people... treating the camera as an object is just a useful abstraction... you end up applying the same transformation anyway, so the difference is purely conceptual.

Therefore, I take advantage of that abstraction, only I make mine even more transparent... I have a camera class which has properties such as world position and rotation around each axis (I actually store orientation as forward, up, right vectors). When it comes time to apply the transform (which is the inverse of all these camera properties), the class constructs the view transform matrix, which I then pass to glLoadMatrix(..). Simple. Clean.

To answer the original question, how you compose you transformation matrix makes no difference (I do mine manually rather than use GL functions, as I store components of the matrix anyways) ...the end result should be the same.

I personally like moving the camera. It just makes more sense to me. I don''t know which is faster, but make an abstract camera object just makes sense to me. It may not be the way it is done most of the time, but I''m not a professional so I don''t care

It doesn't matter what you use. GluLookAt moves the world instead of the camera also. It's just a function that combines one glTranslatef and 3 glRotatef into a handy function with different parameters. For OGL everything is the same (moving the world inside the GPU).

The only real way to move the camera is to physically move your screen

- An eye for an eye will make the world go blind -

[edited by - smarechal on May 15, 2002 4:46:03 AM]

Some ideas for your camera class:
My original camera class had a position and orientation vector within it, but after a while I realized that for all the work I was putting into the code, to move and orient a camera "object", I realized I could leverage that, and move ANY object. So I removed the code and vars for movement and orientation, and put them into a new motion-controller class I call "place". Now my camera and any object''s position and orientation can be controlled in 5 ways:
MANUAL via arrows & mouse like Quake
ORBIT position and orientation via programmable sines
LOOKAT another "place", while in programmable ORBIT
LOOKFROM another "place" while mouselooking
HOLD

By pressing a key or moving a slider, I can select the camera or any object for editing/input control, and another key/slider steps through the motion modes, with this I can finely position/orient the camera or any object, nice when first setting up a little 3d world. Place.member_vars provide control over the programmable ORBIT''s sine amplitudes, centers and speed.

------------------

Besides moving the camera via a motion-controller (w/ optional programmable physics), I allow a final eye-relative tweak of the camera for a pure "in & out" effect along forwardZ (keys {}), and an up/down & left/right via sliders. They control eyex, eyey and eyez members in the camera class, and are only used here:

gluLookAt(eyex,eyey,eyez, eyex,eyey,eyez-1, 0.,1.,0.);

zin


zintel.com - 3d graphics & more or less

heh if I were you I would get rid of glu as a dependancy...
heres the source to glulookat... now you can re-implement your own glmultmatrix instead of depending on glu...

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/mesa3d/Mesa/src-glu/glu.c?rev=1.24&content-type=text/vnd.viewcvs-markup

Can your operating system do this?
http://r0gu3.codices.net/?software