Which is a better aproach for camera movement?

Started by
11 comments, last by OpenglLearner 22 years, 6 months ago
I have started to learn about camera movements. In Nehe's 10th tutorial it says: "Any good 3D engine would have the user be able to walk around and explore the world, and so will ours. One way of doing this is to move the camera around and draw the 3D environment relative to the camera position. This is slow and hard to code. What we will do is this: 1. Rotate and translate the camera position according to user commands 2. Rotate the world around the origin in the opposite direction of the camera rotation (giving the illusion that the camera has been rotated) 3. Translate the world in the opposite manner that the camera has been translated (again, giving the illusion that the camera has moved)" However in gametutorials.com http://www.gametutorials.com/Tutorials/Advanced/OpenGL.htm the camera tutorials are using gluLookAt() function. Please tell me which approach is wildly used and faster for exploring 3d worlds as i don't have any time to waste on learning the inefficient method and becoming sorry afterwards. Edited by - OpenglLearner on October 8, 2001 1:37:40 PM
Advertisement
Translating and rotating is faster than using gluLookAt(). I think tutorials use gluLookAt() to make these tutorials easier to understand.
thnx for your reply. In the meantime I found the Eoin Hennessy's camera class which is supposed to be more flexible than gluLookAt() function( www.iol.ie/~hennessye/steamdriven.htm ). I don't like to use other people's coding but sometimes the time is short and there is a lot to be done.



Edited by - OpenglLearner on October 8, 2001 4:08:18 PM
Why would itbe slower? Doesn''t gluLookAt use the OGL transforms within?
In a way i think gliLookAt is slow because these routine has to calculate the View of your Camera, glRotatef(); and glTranslatef is faster... (i think so ... correct me if i am wrong) but i think the fastest would be if you directly Multiply into the Matrix, i dont know exactly the Command, i think it is something with glMultMat. This would be the fastest, but it is hard to Calculate the Rotation/Translation of an Object!

mfg J@n
J.A.N.K.E.Y.: Journeying Artificial Nocturnal Killing and Exploration Youth
Food for thought...OGL is someone else''s code....so I wouldn''t ride the "I code everything myself" high horse too much...but maybe it''s just late and I am being picky!
The Tyr project is here.
quote:Original post by ANSI2000
Why would itbe slower? Doesn''t gluLookAt use the OGL transforms within?


Well for starters it has the rotation and transformation code in it, and then it has the extra code required to calc the rotation and all for looking at a specific point from your current location, etc
-----------------------"When I have a problem on an Nvidia, I assume that it is my fault. With anyone else's drivers, I assume it is their fault" - John Carmack
I think the best way for Rotations of a Camera would be the use of quaterions, it''s hard to understand ( i still do not *g*) but they are better beacause there is no gimbal lock! They are not easy to use. .. everything works because [x² + y² + z² + w² = 1] ( correct me if i am wrong )
So you can do great Camera Movements, which are quite Smooth, because you can rotate on a sphere ( i thinks so ). Good Games like Tomb Raider, Homeworld, and so on!

There are some codes in the web for "quaterions" , just use them!

J.A.N.K.E.Y.: Journeying Artificial Nocturnal Killing and Exploration Youth
Well doing all the math(quats etc...) then calling the translations don''t it still make it as slow as gluLookAt?
I us gluLookAt in my camera system and it works great. It has very nice flexibility, but I am considering using glRotatef and glTranslatef or, with my matrix code, use glMultMatrixf. I hear that glMultMatrixf was slower than glRotatef and glTranslatef. Is that true?

This topic is closed to new replies.

Advertisement