In lesson 10 it uses glTranslatef() and glRotate4f() to move the world around the camera, but in lesson 34 it uses GluLookAt() to change the camera position itself. It seems like GluLookAt() would be much easier to use... What are the pros and cons of each? And which one is easier on the proccessor

I use gluLookAt to move the camera, thats what it does.
I use glTranlsate to move objects around my scene.

Using glTranslate to move or fake a camera i VERY expensive on the hardware.

eg:

I draw 10 boxes
I use glTranslate to make them rotate around the scene, seemingly as if I am turning my head. Each box requires a movement.

Whereas with gluLookAt, with some nice simple maths, I can get the exact same effect, but simply by moving just the camera.

Its much quicker to move a camera then to move 10 boxes!

anyway, hope that helps.

Experiment.
Set up an FPS to display on your screen and try similar to the above.



~~~~~~~~~~~~~~~~~~~~~~~~~

http://on.to/oni

quote:

---

What are the pros and cons of each?

---

Both have the disadvantage that you can''t easily ''save'' the previous rotation, an example of this is a space ship where pressing left will always rotate it left realitive to where it is currently pointing. Neither can do that well. You would need a seperate matrix and glLoadMatrix for that. (good practise to do this imo)

a pro of the glTrans/Rot method is that you arn''t tied to glu. but that isn''t exactly groundbreaking.

LookAt is nice, but I still feel a proper matrix class is considerably better in the long run. Not for cameras, (unless you have a ''lookat'' function in your matrix class ) but for when a program gets much more complex and you want to deal with individual entities. rotate and translate will actually handle this better than gluLookAt, especially when used with push/pop matrix, but once again seperate stored matrices (or quaternions really just have to feel important) is better overall imo.

quote:

---

And which one is easier on the proccessor

---

both come down to a couple of matrix multiplications or less.
considering that you will likly be drawing millions of traingles per second (if you code well ) then neither would ever possibly even be a *slight* performance issue.
Never underestimate how fast a pc is. it''s just when it''s not syncronised everything falls to bits.

| - Project-X - my mega project.. big things comming soon - | - adDeath - an ad blocker I made - | - email me - |

I have never worried about this, because in the first place I haven't come into contact with it in the first place, and secondly I don't think you cannot do the calculations any faster yourself. Thereby, you will probably will be working on model level, each consisting of perhaps thousands of polygons. If you do a single rotation of translation before it you will hardly notice, because the lot of the time will go into rendering the model. Or you must be rotating every single poly in the model, but then you're doing something wrong .

And I agree with RipTorn saying that one shouldn't underestimate the power of current PC's. A single rotation will be hardly noticable.

As for chosing between glulookat and glrotate & translate. I use lookat to set up my camera position, and translate and rotate to position an object in the world, relative to the origin.

-> lookat: set up our camera

-> glPushMatrix(); //save current matrix
-> translate
-> rotate
-> draw the object
-> glPopMatrix(); //reset last saved matrix, so future drawn objects aren't effected my the previous translate and rotation

-> draw the other objects according to the same principle...

-> profit

[edited by - Structural on January 21, 2003 10:15:41 AM]

I''m slightly confused about all this...

I''m not rotating every polygon, at the top, before i render my world, i translate the opposite of my camera''s x and y positions, and rotate it to 360 minus the angle of my camera...

I don''t use any matrices, and I only have 3 variables, and then i use a little bit of trig to find new x and y, and turning just changes the heading...

Sorry, what I described was merely a hypothetical (spelling?) situation.

What you do works perfectly fine, translating and rotating the oposite but personally I''d use lookat to set up my camera, because you don''t have to reverse your way of thinking when moving the camera. Disadvantage is that you are unable to express the angle you are looking under in degrees, or you have to recalculate the second point that you give to lookat. That''s the biggest disadvantage of lookat that I''ve found.

Lookat DOES solve the problem of tracing an object. Think of when you are moving the camera around space, but you want to keep an eye on that space ship that is floating around. Instead of calculating the angles you have to rotate, you simply tell lookat to look at the point where the space ship is, regardless of the camera position it will always keep the ship in the centre of the screen. That''s one pro of lookat that I''ve found very handy.

It''s all personal preference really. If you like to work with angles, and don''t mind thinking in reversed order, then translate and rotate will do the job.
If you always work with two points, a position and lookat point, then gluLookAt is your choice.
You aren''t bound to either one, there is no "right" way of doing this. And for processor load you don''t have to make a choice either. That single calculation to set up a camera is hardly (if at all) noticeable.

Hmm... Thanks.

So glulookat may be better for 3rd person, but gltranslate and rotate are probably better for 1st person.

Started to use glLookAt. A bit paintful to understand the function giving a tremendous amount of parameters. As one of my project is a racing game, I found it useful. Now time to see what I can do for the contest.

Actually, gluLookAt is just making the appropriate calls to glTranslate and glRotate, so the only additional processor stress you may get is in solving your viewing vector.

To solve the viewing vector, I''ve found it very easy to imagine a sphere of radius ''1'' aroung the point ''camera''. Depending on mouse movement (or preprogrammed movement), you increase/decrease the angle rot_x, rot_y, rot_z and solve for the end point. The reason I use as radius of ''1'' is that the answer solved by sin(rot_axis) or cos(rot_axis) does not have to be scaled, thus saving some floating point multiplication. But then again I''m still adding overhead by using the trig functions in the first place... but it''s never given my any headaches.

It''s been ages since I used this code, but if anyone is interested this code creates a ''look at'' matrix..




| - Project-X - my mega project.. big things comming soon - | - adDeath - an ad blocker I made - | - email me - |