controlling the camera

Controlling the Camera

3D Navigation Paradigms

Mathematics of 3D Navigation The Examine model The Virtual World model Gravity and walking over bumpy ground

Navigation Models

3D applications today often involve navigating the camera through a virtual scene.

Sometimes this navigation emulates flight; walking on foot; or examining an object floating before you in space.

These different modes of interaction are called navigation models or navigational paradigms.

The two dominant navigational models are Virtual World and Examine

Navigation Models

Virtual World: Walking, running, flying through a scene which moves around the user in a fair approximation of reality 1st-person : camera is the eyes of the player’s character

DOOM, Quake

MS Flight Simulator 3rd-person : camera watches the player and moves to keep the player

in sight

Tomb Raider, Indiana Jones, Super Mario Brothers

Alone in the Dark

Navigation Models

Examine : Placing the camera outside the virtual scene, looking inwards Like holding an object at arm’s length and turning it before your eyes,

examining every different point of view. Viewer is not part of scene Camera can be perspective or orthogonal Examples:

CAD/CAM and modeling software

Medical imaging softwareStarCraft and other RTS

games

Navigation Models

In the Virtual World models, it is reasonable for the world to interact with the camera’s perceived location. The viewer is a part of the scene, and the world reacts accordingly Ex: Lasers shoot at you, waves rock you, you fall off of cliffs and

platforms. In the Examine model, the perceived location of the

camera has no effect on the scene. There is no concept of the

camera as an interactive part of the world; it is a ghost, moving through the world without substance.

Navigation Models

VRML (the Virtual Reality Modelling Language) breaks navigation into three discrete modes: Walk mode Fly mode Examine mode

VRML extends these modes with the concept of pre-set viewpoints which encode a point of view, a direction of view, and sometimes a navigation mode in a browsable interface.

Navigation Models

Attributes of the Virtual World model: Gravity?

If a virtual world has gravity, the camera will fall if unsupported.

Momentum?In the real world, a body in motion stays in motion.In the virtual world, a body in motion might slow down if

not under constant acceleration (PacMan). Collision detection?

Objects in the virtual world such as walls may prevent the camera from passing through them.

A sense of ‘up’?The navigation model may enforce an up direction on

the camera, not allowing it to tilt or preventing roll (DOOM)

Navigation Models

Combinations of Virtual World attributes: Gravity, minimal momentum, and collision detection: Quake, Tomb

Raider Gravity, momentum, collision detection: Gran Turismo No gravity, momentum, collision detection, a sense of ‘up’ : MS Flight

Simulator and other air-flight sims No gravity, momentum, collision detection, no sense of ‘up’ :

Freelancer and other space flight sims

Mathematics of Navigation (Examine Mode)

The math behind the Examine paradigm is actually significantly simpler than the math of a reasonable Virtual World model.

This is because the Examine model generally involves tracking across a sphere, always facing towards a fixed point; whereas the Virtual World models assume that the camera may face in any direction, and interaction (acceleration, turning, rising) is generally in terms of that current facing.


A minimal Examine mode: circling around the object in the XZ plane Remember that a circle is

X=radius * cos(theta)Z= radius * sin(theta)

Passing these X, Z values with Y=0 into gluLookAt as the from coordinates will place the camera in the circle around the origin in the XZ plane, at an angle determined by theta and a distance determined by radius.

The actual code: gluLookAt( 10*cos(t), 0, 10*sin(t), 0,0,0, 0,1,0);


An interesting variation on the simple examine mode is to allow the camera to swing up and down at the same time as it swings left and right. This uses a second and variable, rho, and X, Y, and Z are found

from the equation for a sphere:

X = r*sin(theta)*cos(rho)

Y = r*sin(rho)

Z = r*cos(theta)*cos(rho) This allows the camera

to trace a sphere, but youmust constrain rho to therange from -π/2 to π/2 orthe user might flip over thetop of the scene.


Lastly, the user can “zoom” or “dolly” the camera in and out by modifying the radius of the sphere.

These versions of the Examine mode might be called a “polar coordinates” approach to describing the camera position. Polar coordinates describe a point with angles and radius instead of X,

Y, Z.


Disadvantage to a polar approach to Examining: As you drag the mouse sideways when you’re near the XZ

plane, the object spins before you. But if you drag the mouse up or down, until the camera is

near the Y axis looking down towards the plane, dragging the mouse sideways will spin the model around the Y axis--seemingly spinning around an axis that pierces the screen. This is unintuitive, and not the effect the user would expect if they were spinning an object in space before them.


If not polar then what? In lieu of a polar approach to examining the scene, where you

store the camera position as two angles and a radius, you could store the camera’s position as a proper 3D vector.

Part of the trick is that swinging a point around the origin means building a rotation matrix. For instance, dragging the mouse sideways would apply a Rotate-Around-Y matrix to the current camera position.

The real difficulty is that as the user, say, drags the mouse sideways, the axis that you expect to rotate around is the vertical axis of the screen, not necessarily that of the world.

What if the user is upside-down, or rolled over onto one side?

Mathematics of Navigation (Virtual World Mode)

The Virtual World model of navigation You can store a camera as a location, a point being looked at, and

an up axis:

class Camera {

Vec lookFrom;

Vec lookAt;

Vec lookUp;

};

Clearly this makes theOpenGL call trivial, butthe math behindspinning around a pointbecomes more difficult.


Co-ordinate Systems (briefly) When you look at the screen, the X axis is to the right, the Y

axis is up, Z is towards you. You could summarise this by saying that

Vector X = [ 1, 0, 0 ]

Vector Y = [ 0, 1, 0 ]

Vector Z = [ 0, 0, 1 ] You can use any three perpendicular

vectors to describe a co-ordinate system:Vector X = Z Y

Vector Y = lookUp;

Vector Z = lookAt - lookFrom

and then [-dy, dx] can be expressed as V = -dy * X + dx * Y.


Once your camera is stored as a triple of vectors, moving the camera around becomes much easier.

Vector X = Z Y

Vector Y = lookUp;

Vector Z = lookAt - lookFrom

Strafing side-to-side : add X to lookFrom Strafing up-and-down : add Y to lookFrom Dollying forward and backwards : add Z to lookFrom Turning in place : Build a rotation matrix, as for examining, but

this time apply it to the lookAt instead of the lookFrom.


The Virtual World model of navigation To rotate the camera around the look-at point, we need to rotate the

vector from the look-at point to the look-from point around the origin. We know how to rotate a point around the origin, around the X, Y or

Z axes. So if the user drags only left-right or only up-down, we can build the

appropriate matrix to rotate the look-from point. Rotating a camera around a center:

Let F=look-from of camera

Let C=look-at of camera

Let M=the rotation matrix around X, Y or Z by theta degrees.

Then

F’ = C + M * (F-C)


Rotating the camera in the Virtual World model When the user drags the mouse sideways, they’re really requesting

a rotation around the vertical axis of the screen. When the user drags the mouse vertically, they’re really requesting a

rotation around the horizontal axis of the screen.

In fact, in general, if the mouse is dragged along a 2D vector [dx, dy], the user expects to rotate around the on-screen vector [-dy, dx]:

The axis of rotation is rotated 90 from the axis of mouse drag.

Rotation by 90 is the matrix R below, and the axis = R * [dx,dy].

R = [ 0 -1 ]

[ 1 0 ]

X

Y


Rotating the camera in the Virtual World modelIf the axis of rotation is [-dy, dx]

then we can find the amount of

rotation from how far the user

dragged the mouse : the length

of [-dy, dx], scaled to radians.

How to go from [-dy, dx] to a 3D vector? [-dy, dx] is on the screen, it’s in the plane perpendicular to the camera’s

viewing direction. This defines a co-ordinate system--local X, Y and Z vectors:

• Vector Z = lookAt - lookFrom

• Vector Y = lookUp;

• Vector X = Z Y

[dx, dy]

[-dy, dx]


V = -dy * X + dx * Y lets us calculate the vector V in 3D space which is the real-world axis of rotation that the user expects to rotate around. It has no Z component, of course, because the screen is flat.

The matrix to rotate around an arbitrary vector V:Vec v; // Vector axis to rotate around

double theta; // Angle to rotate by, in radians

double s = sin(theta);

double c = cos(theta);

double t = 1 - cos(theta);

double m[16] =

{ t * v.x * v.x + c, t * v.x * v.y + s * v.z, t * v.x * v.z - s * v.y, 0,

t * v.x * v.y - s * v.z, t * v.y * v.y + c, t * v.y * v.z + s * v.x, 0,

t * v.x * v.z + s * v.y, t * v.y * v.z - s * v.x, t * v.z * v.z + c, 0,

0, 0, 0, 1 };

Gravity

User motion: A camera gives you a “user position”. You can use a second vector to store “user momentum”, the current

speed and direction of travel of the camera. Every time your idle() routine ticks, you’ll add the momentum vector to

the lookFrom of your camera.

Gravity made simple: It’s simple to test if the camera is on the ground or above it. Every tick that the camera is above the ground, add a little bit (0.1 or

less) to the Y component of your velocity vector.

This will have the effect of moving the user downwards, more and more quickly the longer they’re airborn.

As soon as your camera hits ground level, lock its Y value to that of the ground (don’t want to go through!) and set the Y component of your velocity vector to zero.

Parametric Terrain

Remember parametric functions? A 2D parametric function, something like

X=u

Y=sin(u*v)

Z=v

...is a great way to make gently rollinghills!

You can use the Y value of the parametric function, for any [u,v], to find the height that the camera should stop at when falling.

Remember to add a small fixed bit more to the camera’s Y value for the height of the camera above the ground. (This is the height of the user in the world.)

Height-Mapped Terrain

Height Maps If you want to use a more detailed data set, you can use a height

map, a very large two-dimensional array of height values. Each cell in the 2D array is the height at

that particular [u,v].

You can associate colors

with height to create the

appearance of mountains

and grass; or you can use

texture-mapping to create

more realistic terrains.

http://www.planetside.co.uk/terragen/

controlling the camera

Documents