FPS Camera

[NoteMe]

I have seldom gotten as good help as I have done here. So I will try once more (thank you to everyone in the past that have helped me).

I want to make a FPS camera for my game. This is for DX (so right handed coordinate system), but I don't think that matters at al.

I have the movement and strafing ready to go. Works perfect. But now I am going to start to write the rotate by mouse code. I don't want to use Quaternions so, Matrices will have to do.


Lets say that the camera is positioned at (1,1,1), and the user pitches (tilts camera up) the camera. Is all I have to do translate the camera back to the X axis, then rotate it around the X axis as many degrees as the user pitched and then translate the camera back where it was? Is that all?

Thanks in advance.

- ØØ -

 

[Humus]

Is that all?

Yup.

 

[NoteMe]

Are you sure...what did I do wrong.....I have been sitting with the stupid thing since I posted, and figgured it had to be more to it, and then you say that is it...grrr.......must read over my code again then. Thanks for at least telling me that I should be in the right direction..

- ØØ -

 

[Humus]

Maybe you have your transforms applied in the wrong order? At least in OpenGL this can be a bit confusing the first time you do it if you're using built-in matrix functions, because transforms are applied the opposite order of your function calls. Which makes sense with matrix hierarchies, but isn't very intuitive at first.

If you have trouble getting it right, you could always look into any of my demos.

 

[KimB]

Lets say that the camera is positioned at (1,1,1), and the user pitches (tilts camera up) the camera. Is all I have to do translate the camera back to the X axis, then rotate it around the X axis as many degrees as the user pitched and then translate the camera back where it was? Is that all?

Also be aware that if you're adjusting the camera, you're likely working with a passive coordinate transform instead of an active one, so you may want to be careful about which way you're moving things.

 

[ERP]

I'd construnt the matrix from some set of source values every time, you will run into denormalisation issues if you do it incrementally.

For what you want to do pitch, yaw and distance from the target would be sufficient. Since the gimble lock is irrelevant.

Personally I'd just do this with the front right and up vectors, during camera construction, rather than attempting to do it incrementally with rotations. adjust the forwards vector to point more or less where you want, normalise it, Cross it with the up vector to give the right vector, cross that with the forwards vector to give the new up and then translate to the final position.

I Should note that there is a practical limit to how big an angle delta you can get away with using this method.

 

[KimB]

It's easy enough to calculate the right, front, and up vectors if you have the angles stored, though (you can just use the Euler angles for this pretty easily...granted, it will take a few cycles this way, since it involves evaluating sin/cos functions...but you could just do this once every, say, tenth frame and use incremental changes with small-angle approximations inbetween).

 

[ERP]

It's easy enough to calculate the right, front, and up vectors if you have the angles stored, though (you can just use the Euler angles for this pretty easily...granted, it will take a few cycles this way, since it involves evaluating sin/cos functions...but you could just do this once every, say, tenth frame and use incremental changes with small-angle approximations inbetween).

Honestly if you're worried about the cost of a few trig functions don't.

I'd do it from the data that exists in the matrix only because years ago avoiding the trig functions was worth the effort and that's how I've always done it.

 

[KimB]

Well, the cost of trig functions is still pretty high, but I suppose generating the camera view is only done once per frame, so it shouldn't be an issue.

Side comment: I currently have some software where 60% of the time is spent calculating logarithms and exponentials. This was rather shocking to me because only a tiny part of the written code uses them.

 

[NoteMe]

I kind of managed to get it working in the end. Took me some time to get back to this thread because the HDD with all my code for the last 12 years died on me.....used a few days to gatter pieces....


But I must admitt that I didn't manage to use rotations. I used trig, something that I actualy didn't want to use... Because I guess it is importent to understand how to rotate around an arbitrary axis anyway. I guess you do that in 3D all the time.


BTW humus. I just glimpsed at your code before my hard drive died. Didn't look like you had a camera class..am I right, or was I just looking in the wrong direction. (BTW that rollercoaster demo of yours in the lava is sooo cool. It is nearly cooler then the flag demo you have.)



Øyvind Østlund