# Full 3D camera - confused

This topic is 4133 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

as the topic says... lets say for space simulation game, the camera needs three degrees of freedom... is it possible to achieve it with euler angles or matrices, without any consequences (gimbal lock etc)??? I wouldn't like to use quaternions as they are complicated and I'm more used to matrices. thx in advance

##### Share on other sites
Yes.
But you will need to do small Incremental rotations.

Rather than rotate based on the World xyz axis, you will need to Keep Track Of XYZ axis for your spaceship/camera, which are allowed to rotate and change relative to World xyz.
And you'll want to rotate based on XYZ, but each rotation must also change their orientation in World. Thus theres no gimbal lock because rather than chain major euler angles into one another, you keep refreshing for a new XYZ basis.

##### Share on other sites
You will avoid gimbal lock by using a matrix ... unless you make a common mistake and that is to have 3 matrices (or quaternions), one for each of pitch, yaw, and roll.

##### Share on other sites
Just rotate around the correct axis. When you rotate the model rotate the axis that you're going to rotate around aswell. So if you rotate around the x-axis then the y-axis, the y-axis isn't going to be 0.0, 1.0, 0.0 anymore, etc.

##### Share on other sites
I find a much simpler camera paradigm that's easier to work with is to keep track of the camera's position, the position the camera is looking at, and the direction that the camera considers to be "up". Figure out these values and it's easy to generate a matrix each frame. You won't have to worry about gimbal lock or have to deal with quaternions or euler angles.

j

##### Share on other sites
Quote:
 Original post by jdiI find a much simpler camera paradigm that's easier to work with is to keep track of the camera's position, the position the camera is looking at, and the direction that the camera considers to be "up". Figure out these values and it's easy to generate a matrix each frame.
Do you use this method for 'free' (i.e. 6DOF) cameras? If so, I'm curious: how do you go about updating the orientation of the camera using this representation?

##### Share on other sites
Well, there's enough information there to construct an orthonormal basis, which you could rotate and then decompose back into the up and look-at vectors, discarding the third. That'd be my guess.

I just store a quaternion representing orientation of a set of three implicit basis vectors, and a vector for position.

##### Share on other sites
Quote:
 Original post by jpetrieWell, there's enough information there to construct an orthonormal basis, which you could rotate and then decompose back into the up and look-at vectors, discarding the third. That'd be my guess.
That's my guess to :)

I've just always been puzzled by tutorials and camera classes that represent the camera using a position and look-at vector, because (as demonstrated above) you have to convert it to an orthonormal basis and back to do anything useful with it. It's 'going around the block to get next door', as it were, and certainly doesn't seem like it would be any simpler or easier to work with than a more traditional representation.

##### Share on other sites
I find the position & look_at vectors extremely easy to work with, since I have a dynamic camera that auto-adjusts to keep selected entities in view. I also use it for placing meshes, as I need to store position and aiming (look_at) vectors for the AI and targeting code anyway...then I just drop it into OpenGL with the following (semi-ugly, and uses my vec3 class for doing easy cross-products '/' and normalizing [8^) function:

void glhPlaceMesh(GLdouble camx, GLdouble camy, GLdouble camz,                GLdouble frontx, GLdouble fronty, GLdouble frontz,                GLdouble upx, GLdouble upy, GLdouble upz){    vec3 front( frontx, fronty, frontz );    vec3 up   ( upx, upy, upz );    vec3 right = front / up;    front.Normalize();    right.Normalize();    up = right / front;    GLdouble mat[16];	//  x vector	mat[0] = right.x();	mat[1] = right.y();	mat[2] = right.z();	//  y vector	mat[4] = up.x();	mat[5] = up.y();	mat[6] = up.z();	//  z vector	mat[8] = -front.x();	mat[9] = -front.y();	mat[10] = -front.z();    //  cleanup    mat[3] = 0.0;    mat[7] = 0.0;    mat[11] = 0.0;    mat[12] = camx;    mat[13] = camy;    mat[14] = camz;    mat[15] = 1.0;    glMultMatrixd( mat );}

##### Share on other sites
Quote:
 Original post by lonesockI find the position & look_at vectors extremely easy to work with, since I have a dynamic camera that auto-adjusts to keep selected entities in view. I also use it for placing meshes, as I need to store position and aiming (look_at) vectors for the AI and targeting code anyway...then I just drop it into OpenGL with the following (semi-ugly, and uses my vec3 class for doing easy cross-products '/' and normalizing [8^) function:*** Source Snippet Removed ***
Your example appears to use a different representation than jdi was describing. You appear to be storing a forward vector (your front variable), whereas with his approach a 'target point' is stored.

It's the latter method that I question, since, again, the target and position points almost invariably need to be converted to and from a vector at some point. To me this seems circuitous, but as I mentioned, it doesn't appear that you're example uses this method.

Anyway, @The OP: Given the particular problem you're trying to solve, I would strongly suggest not using the 'position and target' representation for your object/camera. That's just my opinion though. YMMV.

1. 1
2. 2
Rutin
20
3. 3
JoeJ
17
4. 4
5. 5

• 37
• 23
• 13
• 13
• 17
• ### Forum Statistics

• Total Topics
631704
• Total Posts
3001822
×