Greetings people of earth who don't have anything else to do in this life, but GAMES! :) (can't figure out how to post those darn emoticons that smile definatly just up above, but let's stick to the initial subject) I implemented a simple camera and by looking through various tutorials on the internet I did not find only one that shows/explains how to implement a camera that acts exacly as, say, the camera in QuakeIII. That is: if you have the game or any other FPS game enter the game and move the mouse to look up, perpendicular to the ground plane then spin the mouse... that's raher cool isn't it? :) Now do this: take a tutorial from www.GameTutorials.com , www.UltimateGameProgramming.com or http://nehe.gamedev.net/ and do the same thing: try to look perpendicular to the ground plane: SHOCK! the view is limited, otherwise the camera code would create degenerate 3 axis systems(that is 3D orthogonal systems) Anyway these tutorials don't even bother to maintain an orthogonal system when calculating the view,position rotation of the camera. To put it shortly: How do I create a camera that acts exactly as in a proffesional FPS (like QuakeIII for example) without any quaternion or other matrix operations just using trigonometry and the function: RotateByAxis present in the tutorials from the sites above. I would be mainly interested in the logic involved.

What's wrong with NeHe Tutorial #10 camera?
http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=10

Quote:Original post by Deliverance
How do I create a camera that acts exactly as in a proffesional FPS (like QuakeIII for example) without any quaternion or other matrix operations just using trigonometry and the function

er... you don't? "Professional" camera systems use either quaterions or a matrix to represent the rotation of the camera. In fact, I've never seen a "professional" system for orientation (of cameras or objects of anything else) that doesn't use either quats or matrices. Learn how to use them, they're a fundimental tool for game programming.

Most "professional" FPS cameras do, in fact limit the look. They just cap your looking up and looking down to 1 degree less than directly up or directly down. If you want a full 6-degrees of freedom camera (like for a flight-sim), you'll want a nice quaternion driven camera so you don't have the hassle of gimbal lock. You can certainly do it with euler angles, but then you have to deal with the gimbal (not a hard problem really as the solution is know and easily available).

-me

Thanks for the replies guy, guess I'll just use quaternions then.

Quote:Original post by Deliverance
Thanks for the replies guy, guess I'll just use quaternions then.

good stuff. expect a fair amount of frustration for 3-5 days. they can be pretty confusing the first time through. you'll be happy to have a quaternion class though, comes in handy for tons of stuff.

-me

Quote:Original post by Promit

Quote:Original post by Deliverance
without any quaternion or other matrix operations just using trigonometry and the function: RotateByAxis present in the tutorials from the sites above.

That's a recipe for disaster.

The simple way to do this is to maintain your three orientation vectors -- right, up, and look -- and transform each of them by a rotation matrix. They'll always be rotated around the current local Right vector for the case of looking up or down, and always around the current world Up vector (this is always <0, 1, 0>) for looking side to side.

When you've done all the relevant transformations, simply orthonormalize the entire system (it will creep otherwise) and construct the appropriate matrix from the vectors (absolutely trivial).

Seconded. I use this system almost exclusively.

Just wanted to add a couple of other thoughts:

- Although a quaternion class is useful to have, it's entirely unnecessary for this type of camera

- IMO an FPS camera is best implemented using 'from scratch' matrix construction rather than incremental rotations; with the former approach, no orthonormalization is required

- Although as has been mentioned a 1-degree pitch limit will hardly be noticable, it's also not at all necessary if your code is implemented correctly

Also, this thread might be of interest to you. If you look towards the bottom there's a post that goes into some detail as to how to construct the basis vectors for an FPS camera.

Contrary to popular belief Euler angles are in fact fine for a FPS camera – you don't want 6 DOF and you do want 'I'm walking in this direction and looking up/down', which is exactly what Euler angles do. Just create a camera matrix from scratch every frame:

ResetMatrix();Translate(Camera.Position);Rotate(0, 0, Camera.Yaw);Rotate(0, Camera.Pitch, 0);Rotate(Camera.Roll, 0, 0);