Best Way To Do Camera Transformations In Opengl ?.

[Vorporeal]

Couldn't find a significantly better subforum to ask this, so I'll ask it here, I guess. I'm currently working on adding in a camera class into this game I'm writing. I'm not quite sure what the best way to implement it is. I've thought of two approaches: do trig calculations based on user input and then pass the calculated result to gluLookAt, or just keep track of the position and rotation, then use glTranslate and glRotate. NeHe's tutorials used glTranslate and glRotate, but that might just be that it's easier to do it that way and not have to worry about the trig calculations, or it might just be because it's the better way. Is either way inherently better or faster? Is there some other option that's better than either of those? I'm just trying to make sure I do it correctly the first time and not get myself into bad habits.

EDIT: I guess I should have put a question mark at the end of the topic title to avoid confusion, my bad.

 

[PokeParadox]

The problem with just using glRotate is that you can encounter something called "gimble lock" with regards to 3d rotations.
Gimble lock is when the camera gets stuck along one axis and your rotations will not behave as expected.
You will be best using matrix transformations and quaternians to avoid this.
generally it is better to always rotate from the origin, rather than cumulatively since you can accumulate transformation errors otherwise.

That's about all I can advise, and I'm yet to implement a "decent" camera solution myself...

 

[trooper]

I guess I should have put a question mark at the end of the topic title to avoid confusion, my bad.

Done.

Trooper

 

[JayFoxRox]

In my GTA-style game (not for pandora though) I keep the players angle (horizontal rotation) and look (vertical rotation) in memory and modify that based on the mouse movement. I then calculate the new camera-matrix every frame using simple sin/cos to place the camera on a sphere surrounding the player.

 

[Butterman]

http://www.darkrockstudios.com/public/project/ezcamera

EZCamera is written by a friend of mine. I'm using it in Human Condition. If you're using OpenGL ES 1.1, just load the matrix. If you're using ES 2.0, pass the matrix to your shader and use it as the camera matrix.

The rest is explained in the source.

 

[darkblu]

Couldn't find a significantly better subforum to ask this, so I'll ask it here, I guess. I'm currently working on adding in a camera class into this game I'm writing. I'm not quite sure what the best way to implement it is. I've thought of two approaches: do trig calculations based on user input and then pass the calculated result to gluLookAt, or just keep track of the position and rotation, then use glTranslate and glRotate. NeHe's tutorials used glTranslate and glRotate, but that might just be that it's easier to do it that way and not have to worry about the trig calculations, or it might just be because it's the better way. Is either way inherently better or faster? Is there some other option that's better than either of those? I'm just trying to make sure I do it correctly the first time and not get myself into bad habits.

allow me to toss in my penny.

* as a spatial object your camera interfaces should not differ much from your bog-standard spatial objects. one day you'll want to subject your camera to animation controllers, etc. ultimately, your camera needs to keep track of just:

1. a world-to-camera transform, preferably its inverse too
2. a projection transform

technically, (1) is a standard property for any spatial object (world-to-local/local-to-world transform)

* how the user controls your camera is entirely a matter of what the game mechanics are - control may need to be relative, or mixed, or something entirely different.

* if you really want to understand game cameras, read this book:
http://www.amazon.com/Real-Time-Cameras-Mark-Haigh-Hutchinson/dp/0123116341/ref=sr_1_1?ie=UTF8&s=books&qid=1247752452&sr=1-1