# The Industry's Foundation for High Performance Graphics

1. ## camera stuff (matrices?)

Hi!

I'm trying to make it easy to use camera. When I press for example left arrow, camera should always turn to left. It isn't the same as rotating around y-axis. When camera is looking down, it should rotate around z-axis. I hope you understand what I mean.

Thanks and sorry(my English...)

2. ## Re: camera stuff (matrices?)

You might want to look into camera models.Search google for RUV(also called UVN) camera models to see what they are and if they suit your needs.
But for a very quick solution(although a RUV model for example isn't much harder to code) try the following.Use a 3x3 camera rotation matrix R[9] and a camera position vector P[3].Now to rotate the camera multiply any rotation matrix with R(like R=M*R).To move the camera x units along the x axis,y along the y axis an z along z,multiply the (x,y,z) vector V with R and add it to P(like P=P+V*R).Finaly construct a 4x4 translation matrix out of P,a 4x4 rotation matrix out of R,multiply them and glLoadMatrix the result.This last multiplication must be done in the correct order(transl*rot I think).
You can find info on how to construct 4x4 homogenous matrices on the net(it's really easy just mind the opengl way of storing them).I hope this info will help you understand that camera model stuff.

3. ## Re: camera stuff (matrices?)

Yes, but you want to rotate around the camera's Y axis. To do that, you can keep the current orientation and position in a 4x4 matrix. To rotate, you post-multiply (using OpenGL's notation) it by a rotation matrix -- C' = C * R. You might want to use a quaternion and position instead of the 4x4.

4. ## Re: camera stuff (matrices?)

Originally posted by Jambolo:
Yes, but you want to rotate around the camera's Y axis. To do that, you can keep the current orientation and position in a 4x4 matrix. To rotate, you post-multiply (using OpenGL's notation) it by a rotation matrix -- C' = C * R. You might want to use a quaternion and position instead of the 4x4.

5. ## Re: camera stuff (matrices?)

sorry for the sta post, accidently hit my enter key

now to the real post
i am using it for all my camera models
6DOF cam, quake like cam, 3rd person cam, etc
you just deal with 3 vectors in worst case
is it so much faster to do all the matrix multiplication stuff (i only need a vector addition to translate my cams and for rotations it is mostly one matrix-vector-multiplication and a little normalize and cross-product, can be less dependent of the camera typ)

what type of camera do you want to implement dja?

sounds like my quake like cam works like you want it although it is limited to -90 to 90 degree rotations about the right vector (meaning looking up and down) to avoid gimble lock

6. ## Re: camera stuff (matrices?)

rgh...what type of camera?
I don't know. Axises should be always rotated with the camera, and I don't know how to do that.

7. ## Re: camera stuff (matrices?)

If I get it correctly what dja wants is just some generic camera model where he can rotate the cam and move forward,strfe etc. sort of like in the old doom games.
Jambolo:the matrix doesn't need to be a 4x4 matrix,it can be converted later.You're right on the post-multiplying though.As for quaternions it's best to start with a very simple implementation to get the hang of it first.Since this doesn't require much effort it can be rewritten later when he has more specific needs.
Satan:since cam calculations are done once per frame I doubt it would make a (big) difference in speed.But for some cams like the quake style you mentioned LookAt wouldn't be the best thing.Just getting the relative movement of the mouse and creating to matrices(which can be simplified to one) is mich simpler).

8. ## Re: camera stuff (matrices?)

There's a pretty good camera tutorial available here . As long as you know basic linear algebra you should have no problem understanding.

9. ## Re: camera stuff (matrices?)

Originally posted by zen:

Satan:since cam calculations are done once per frame I doubt it would make a (big) difference in speed.But for some cams like the quake style you mentioned LookAt wouldn't be the best thing.Just getting the relative movement of the mouse and creating to matrices(which can be simplified to one) is mich simpler).
it is working and as long as i don't get a great performance loss i think i will keep it that way (would have to rewrite all my cameras since they are derived from a parent class heavily relying on glulookat)
and much simpler than my approach it can't be (since it is very simple what i do, it could only be a little simpler )
thx anyway

10. ## Re: camera stuff (matrices?)

Also check this out for some interesting info on rotation matrices: www.makegames.com/3drotation

#### Posting Permissions

• You may not post new threads
• You may not post replies
• You may not post attachments
• You may not edit your posts
•