240 likes | 378 Vues
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.
E N D
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 software • StarCraft 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.
Mathematics of Navigation (Examine Mode) • 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);
Mathematics of Navigation(Examine Mode) • 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 camerato trace a sphere, but youmust constrain rho to therange from -π/2 to π/2 orthe user might flip over thetop of the scene.
Mathematics of Navigation(Examine Mode) • 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.
Mathematics of Navigation(Examine Mode) • 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.
Mathematics of Navigation(Examine Mode) • 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.
Mathematics of Navigation(Virtual World Mode) • 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.
Mathematics of Navigation(Virtual World Mode) • 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.
Mathematics of Navigation(Virtual World Mode) • 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)
Mathematics of Navigation(Virtual World Mode) • 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 ] Y X
Mathematics of Navigation(Virtual World Mode) • Rotating the camera in the Virtual World model • If 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 [-dy, dx] [dx, dy]
Mathematics of Navigation(Virtual World Mode) • 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 arbitraryvector 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/