Jump to content
  • Advertisement
Sign in to follow this  
i_luv_cplusplus

Full 3D camera - confused

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by jdi
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.
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
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.
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by lonesock
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:

*** 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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!