Vector Cam

Welcome to GDNet :) I won't try and comment on the design questions, but I'll see if I can address some of your camera-related questions:

Quote:

*I know I've got UVN vectors (for right, up, and forward) *I need an additional vector for the viewing direction, right? *the viewing direction is calculated by the angles yaw, pitch and roll around the right, up and forward vectors, right? *are the vectors right, up and forward fix? I mean are they always parallel to the plane I'm walking on when I want to do a first-person camera or are those bound to the world axis? (In a shooter I do not turn around a local axis but on world axis right? *when I want to use the gluLookat function do I put in the lookat-vector as vector of length 1 or is it: pos+fwd? and is the lookat-vector the forward vector?

I have the GPG book you refer to, but I haven't read that article in a while.

Anyway, I wouldn't get too fixated on a particular camera representation (and in any case, I'm not sure that the UVN representation has any particular advantages over other possible representations - could be wrong though).

The first thing I'd suggest is not to get too hung up on the fact that it's a 'camera'. A camera is an object just like any other game object, with the same characteristics (it has a transform associated with it, it can be moved about, etc.). The camera is usually set apart by the fact that we invert its transform before submitting it to the graphics API, but that's just a detail.

On that note, people seem to get hung up on the whole 'look at' thing, leading to weird, awkward code involving rotating target points and whatnot. The 'look at' function is merely a convenience. In fact, most people don't even use it for what it's really for (that is, setting up a camera to aim at a particular target) - they just use it because it hides the details of inverting the view matrix, a step which some find confusing.

Don't be confused. Just invert the camera transform before submitting it to the API and you're good to go. (One minor note: there may or may not be additional complications here when dealing with a right-handed coordinate system, but I'm not going to go into that now, and in any case they're very easy to work around.)

As for the transform itself, a camera transform is almost always going to consist of a rotation and a translation (that is, there's no scale, shear, etc.). The most straightforward representation for this is probably a simple 4x4 matrix (given that this is what most hardware works with nowadays). You could also use a quaternion and a point, or perhaps a 3x3 matrix and a point. Or, three orthonormal vectors and a point, such as in the UVN example. Ultimately, it's not that important (and it's almost certainly going to end up in matrix form anyway).

Now, controlling a camera is a different issue. There are many types of camera control schemes (e.g. first-person, third-person, 6DOF, orbital, etc.). For some of these you'd probably want to choose a more specialized representation, such as an Euler-angle pair for first-person, target transform and trailing distance for third-person, a quaternion and a point for 6DOF, azimuth, elevation, distance, and target for orbital, and so on. Ultimately, of course, you'd end up converting all of these to matrix form, but choosing the right representation to use up to that point can make your code much cleaner and more straightforward than it otherwise might be.

I've got to go, so I'll leave it at that for now, but please post back with questions if any of that is unclear (which it probably is).

hey,
actually I already know the modelview and projection matrix construction parameters and stuff.
I basically use my own lookat-function as well, cause it's more intresting than using the glut-functions. for the projection matrix as well.
I know I'd probably need the quaternion cam sooner or later, but first I want to understand the geometric problem better.
the problem of left or right-handed coordinate system can be tryied out by using z or -z. i don't understand the parameters I definitely need to save for player movement: is it UVN or is it the world position and a viewing vector?
actually a viewing vector would suffice cause i get the world coordinate forward from it's projection on the world xz-plane (right-hand).

or is it better to store ypr and on which axis should I apply those?
I think a good technical answer should wake me up
thanx to all who take their precious time to read here

Quote:

Original post by zqueezy hey, actually I already know the modelview and projection matrix construction parameters and stuff. I basically use my own lookat-function as well, cause it's more intresting than using the glut-functions. for the projection matrix as well. I know I'd probably need the quaternion cam sooner or later, but first I want to understand the geometric problem better. the problem of left or right-handed coordinate system can be tryied out by using z or -z. i don't understand the parameters I definitely need to save for player movement: is it UVN or is it the world position and a viewing vector? actually a viewing vector would suffice cause i get the world coordinate forward from it's projection on the world xz-plane (right-hand). or is it better to store ypr and on which axis should I apply those? I think a good technical answer should wake me up thanx to all who take their precious time to read here

A couple of random answers...

First of all, you won't necessarily 'need' a quaternion camera at any point; although quaternions are handy for certain purposes, you can do all of the same things using matrices (and as you stated, it's probably better to understand the problem in terms of matrices and/or basis vectors before venturing into quaternion-land).

As for movement, generally speaking, you need the position of the camera and the three basis vectors. The basis vectors are the first three columns or rows of the transform matrix (if you're using a matrix representation), or the UVN vectors themselves (if you're using a UVN representation). If you're using some other representation (such as a quaternion or an Euler-angle pair), the basis vectors can be derived straightforwardly. (As for the 'viewing vector' you mention, I'm not sure how that differs from the forward vector (N?) in the UVN system.)

That leaves the question of Euler angles (the 'ypr' you mention). Applied locally, Euler angles are fine for incrementally updating a rotation (typically roll is about the forward vector, pitch about the side vector, and yaw about the up vector). Applied globally, they are of limited use in a 6DOF context, but can be useful in other contexts.

OK cool, but I just started my "Half-Life2" version for a test and definitely the rotation is about world axis... whenever I go down a slope and the "up"-vector differs from the "world-up"-vector the rotation seems to be around the world-axis. this might differ in a flight-simulator. but how is it done in a shooter. or is the up-vector always fix and does not rotate?

and same for the forward=lookat vector. when I look at the sky (in a shooter) and walk forward I usualy don't fly in the air. is this due to collision detection or is the forward vector the projection of the view vector into the plane parallel to the surface I'm walking on?

Quote:

Original post by zqueezy and same for the forward=lookat vector. when I look at the sky (in a shooter) and walk forward I usualy don't fly in the air. is this due to collision detection or is the forward vector the projection of the view vector into the plane parallel to the surface I'm walking on?

Yes, for FPS character motion the forward movement vector is usually computed in a different way than the forward 'look' vector (as you note, it's restricted so that it remains parallel to the ground plane). In 'spectator' mode, however, the forward movement and look vectors are typically the same, which allows you to 'fly' around.

hm... I wanted to prevent this but here's some code
My Rotation:


My Modelview

In my console I can see, that the position of the camera is always correct, but as soon as I rotate the whole scene blurrs somehow like some maxpain-drug-scene
...

And now the funny part:
when I remove the multiplication of the inverse translation matrix I can rotate perfectly. when I remove the rotation call (Computeinfo) I can walk perfectly