How would one implement an FPS camera?

Question

So I'm currently working on some FPS game programming in OpenGL (JOGL, more specifically) just for fun and I wanted to know what would be the recommended way to create an FPS-like camera?

At the moment I basically have a vector for the direction the player is facing, which will be added to the current player position upon pressing the "w" or forward key. The negative of that vector is of course used for the "s" or backward key. For "a", left, and "d", right I use the normal of the direction vector. (I am aware that this would let the player fly, but that is not a problem at the moment)

Upon moving the mouse, the direction vector will be rotated using trigonometry and matrices. All vectors are, of course, normalized for easy speed control.

Is this the common and/or good way or is there an easier/better way?

Spider

Answer 1

The way I have always seen it done is using two angles, yaw and pitch. The two axes of mouse movement correspond to changes in these angles.

You can calculate the forward vector easily with a spherical-to-rectangular coordinate transformation. (pitch=latitude=φ, yaw=longitude=θ)

You can use a fixed up vector (say (0,0,1)) but this means you can't look directly upwards or downwards. (Most games solve this by allowing you to look no steeper than 89.999 degrees.)

The right vector is then the cross product of the forward and up vectors. It will always be parallel to the ground plane since the up vector is always perpendicular to the ground plane.

Left/right strafe keys then use the +/-right vector. For a forward vector parallel to the ground plane, you can take the cross product of the right and the up vectors.

As for the GL part, you can simply use gluLookAt() using the player's origin, the origin plus the forward vector and the up vector.

Oh and please, please add an "invert mouse" option.

Edit: Here's an alternative solution which gets rid of the 89.9 problem, asked in another question, which involves building the right vector first (with no pitch information) and then forward and up.

Erythrocyte

Answer 2

Yes, thats essentially the way I have always seen it done.

Gaye

Ok, thanks. Just wanted to make sure I'm not missing anything. Have a nice day! – Allerus

Answer 3

Yeah, but in the end you will want to add various other attributes to the camera. To spell it n00b: keep it tidy if you want to mimic Quake or CS. In the end might have bobing, FoV, motion filtering, network lag suspension and more.

Cameras are actually one of the more difficult parts to make in a good game. That's why developers usually are content with a seriously dull, fixed 1st/3rd person ditto.

Pyretotherapy

Answer 4

You could use Quaternions for your camera rotation. Although I have not tried it myself, they are useful for avoiding gimbal lock.

Ridley

Gimbal lock can't happen in FPSs; in fact coupling Euler angles to mouse moves is a massive simplification without any risk. – Arizona

Jonas is right, there is only a risk of gimbal lock when you combine at least 3 rotations. The article you quote is just plain wrong. You can have some gimbal lock with matrices and quaternions if and only if you use Eulerian transforms. There are only two ways of fixing that, some non linear treatments for the singularities on poles or non Eulerian transforms which are easier to express with ... quaternions :) – Phosphoroscope