Advanced 3D Game Programming with DirectX - phần 4 ppsx

214 Now that know how to represent all of the transformations with matrices, you can concatenate them together, saving a load of time and space. This also changes the way you might think about transformations. Each object defines all of its points with respect to a local coordinate system, with the origin representing the center of rotation for the object. Each object also has a matrix, which transforms the points from the local origin to some location in the world. When the object is moved, the matrix can be manipulated to move the points to a different location in the world. To understand what is going on here, you need to modify the way you perceive matrix transformations. Rather than translate or rotate, they actually become maps from one coordinate space to another. The object is defined in one coordinate space (which is generally called the object's local coordinate space), and the object's matrix maps all of the points to a new location in another coordinate space, which is generally the coordinate space for the entire world (generally called the world coordinate space). A nice feature of matrices is that it's easy to see where the matrix that transforms from object space to world space is sitting in the world. If you look at the data the right way, you can actually see where the object axes get mapped into the world space. Consider four vectors, called n, o, a, and p. The p vector represents the location of the object coordinate space with relation to the world origin. The n, o, and a vectors represent the orientation of the i, j, and k vectors, respectively. Figure 5.23: The n, o, a, and p vectors for a transformation You can get and set these vectors right in the matrix, as they are sitting there in plain sight: 215 This system of matrix concatenations is how almost all 3D applications perform their transformations. There are four spaces that points can live in: object space, world space, and two new spaces: view space and screen space. View space defines how images on the screen are displayed. Think of it as a camera. If you move the camera around the scene, the view will change. You see what is in front of the camera (in front is defined as positive z). Figure 5.24: Mapping from world space to view space The transformation here is different than the one used to move from object space to world space. Now, while the camera is defined with the same n, o, a, and p vectors as defined with the other transforms, the matrix itself is different. In fact, the view matrix is the inversion of what the object matrix for that position and orientation would be. This is because you're performing a backward transformation: taking points once they're in world space and putting them into a local coordinate space. As long as you compose the transformations of just rotations and translations (and reflections, by the way, but that comes into play much later in the book), computing the inverse of a transformation is easy. Otherwise, computing an inverse is considerably more difficult and may not even be possible. The inverse of a transformation matrix is given below. 216 Warning This formula for inversion is not universal for all matrices. In fact, the only matrices that can be inverted this way are ones composed exclusively of rotations, reflections, and translations. There is a final transformation that the points must go through in the transformation process. This transformation maps 3D points defined with respect to the view origin (in view space) and turns them into 2D points that can be drawn on the display. After transforming and clipping the polygons that make up the scene such that they are visible on the screen, the final step is to move them into 2D coordinates, since in order to actually draw things on the screen you need to have absolute x,y coordinates on the screen to draw. The way this used to be done was without matrices, just as an explicit projection calculation. The point <x,y,z> would be mapped to <x ′,y ′> using the following equations: where xCenter and yCenter were half of the width and height of the screen, respectively. These days more complex equations are used, especially since there is now the need to make provisions for z- buffering. While you want x and y to still behave the same way, you don't want to use a value as arbitrary as scale. Instead, a better value to use in the calculation of the projection matrix is the horizontal field of view (fov). The horizontal fov will be hardcoded, and the code chooses a vertical field of view that will keep the aspect ratio of the screen. This makes sense: You couldn't get away with using the same field of view for both horizontal and vertical directions unless the screen was square; it would end up looking vertically squished. Finally, you also want to scale the z values appropriately. In Chapter 8 , I'll teach you about z-buffering, but for right now just make note of an important feature: They let you clip out certain values of z-range. Given the two variables z near and z far , nothing in front of z near will be drawn, nor will anything behind z far . To make the z-buffer work swimmingly on all ranges of z near and z far , you need to scale the valid z values to the range of 0.0 to 1.0. For purposes of continuity, I'll use the same projection matrix definition that Direct3D recommends in the documentation. First, let's define some values. You initially start with the width and height of the viewport and the horizontal field of view. 217 With these parameters, the following projection matrix can be made: Just for a sanity check, check out the result of this matrix multiplication: Hmm… this is almost the result wanted, but there is more work to be done. Remember that in order to extract the Cartesian (x,y,z) coordinates from the vector, the homogenous w component must be 1.0. Since, after the multiplication, it's set to z (which can be any value), all four components need to be divided by w to normalize it. This gives the following Cartesian coordinate: As you can see, this is exactly what was wanted. The width and height are still scaled by values as in the above equation and they are still divided by z. The visible x and y pixels are mapped to [−1,1], so before rasterization Direct3D multiplies and adds the number by xCenter or yCenter. This, in essence, maps the coordinates from [−1,1] to [0,width] and [0,height]. With this last piece of the puzzle, it is now possible to create the entire transformation pipeline. When you want to render a scene, you set up a world matrix (to transform an object's local coordinate points into world space), a view matrix (to transform world coordinate points into a space relative to the viewer), and a projection matrix (to take those viewer-relative points and project them onto a 2D surface so that they can be drawn on the screen). You then multiply the world, view, and projection matrices together (in that order) to get a total matrix that transforms points from object space to screen space. 218 Warning OpenGL uses a different matrix convention (where vectors are column vectors, not row vectors, and all matrices are transposed). If you're used to OpenGL, the equation above will seem backward. This is the convention that Direct3D uses, so to avoid confusion, it's what is used here. To draw a triangle, for example, you would take its local space points defining its three corners and multiply them by the transformation matrix. Then you have to remember to divide through by the w component and voilá! The points are now in screen space and can be filled in using a 2D raster algorithm. Drawing multiple objects is a snap, too. For each object in the scene all you need to do is change the world matrix and reconstruct the total transformation matrix. The matrix4 Structure Now that all the groundwork has been laid out to handle transformations, let's actually write some code. The struct is called matrix4, because it represents 4D homogenous transformations. Hypothetically, if you wanted to just create rotation matrices, you could do so with a class called matrix3. The definition of matrix4 appears in Listing 5.23 . Listing 5.23: The matrix4 structure struct matrix4 { /** * we're using m[y][x] as our notation. */ union { struct { float _11, _12, _13, _14; 219 float _21, _22, _23, _24; float _31, _32, _33, _34; float _41, _42, _43, _44; }; float m[4][4]; }; // justification for a function this ugly: // provides an easy way to initialize static matrix variables // like base matrices for bezier curves and the identity matrix4(float IN_11, float IN_12, float IN_13, float IN_14, float IN_21, float IN_22, float IN_23, float IN_24, float IN_31, float IN_32, float IN_33, float IN_34, float IN_41, float IN_42, float IN_43, float IN_44) { _11 = IN_11; _12 = IN_12; _13 = IN_13; _14 = IN_14; _21 = IN_21; _22 = IN_22; _23 = IN_23; _24 = IN_24; _31 = IN_31; _32 = IN_32; _33 = IN_33; _34 = IN_34; _41 = IN_41; _42 = IN_42; _43 = IN_43; _44 = IN_44; } matrix4() { // Do nothing. } static const matrix4 Identity; }; The code contains three main ways to multiply matrices. Two 4x4 matrices can be multiplied together; this is useful for concatenating matrices. A point4 structure can be multiplied by a matrix4 structure; the result is the application of the transformation to the 4D point. Finally, a specialization for multiplying 220 point3 structures and matrix4 structures exists to apply a non-projection transformation to a point3 structure. The matrix4*matrix4 operator creates a temporary structure to hold the result, and isn't terribly fast. Matrix multiplications aren't performed often enough for this to be much of a concern, however. Warning If you plan on doing a lot of matrix multiplications per object or even per triangle, you won't want to use the operator. Use the provided MatMult function; it's faster. Listing 5.24: Matrix multiplication routines matrix4 operator*(matrix4 const &a, matrix4 const &b) { matrix4 out; // temporary matrix4 for storing result for(int j = 0; j < 4; j ++) // transform by columns first for(int i = 0; i < 4; i ++) // then by rows out.m[i][j] = a.m[i][0] * b.m[0][j] + a.m[i][1] * b.m[1][j] + a.m[i][2] * b.m[2][j] + a.m[i][3] * b.m[3][j]; return out; }; inline const point4 operator*( const matrix4 &a, const point4 &b) { return point4( b.x*a._11 + b.y*a._21 + b.z*a._31 + b.w*a._41, b.x*a._12 + b.y*a._22 + b.z*a._32 + b.w*a._42, b.x*a._13 + b.y*a._23 + b.z*a._33 + b.w*a._43, b.x*a._14 + b.y*a._24 + b.z*a._34 + b.w*a._44 ); }; inline const point4 operator*( const point4 &a, const matrix4 &b) { return b*a; 221 }; inline const point3 operator*( const matrix4 &a, const point3 &b) { return point3( b.x*a._11 + b.y*a._21 + b.z*a._31 + a._41, b.x*a._12 + b.y*a._22 + b.z*a._32 + a._42, b.x*a._13 + b.y*a._23 + b.z*a._33 + a._43 ); }; inline const point3 operator*( const point3 &a, const matrix4 &b) { return b*a; }; There are two ways to create each type of matrix transformation. One performs on an existing matrix4 structure (it doesn't create a temporary matrix4 structure, which is slow). The function for a transformation x is void matrix4::Tox. The other is a static function designed to help write cleaner looking code, not for speed. The format for these functions is static matrix4 matrix4::x. Translation Here again is the matrix for the translation transformation by a given point p: The code to create this type of transformation matrix appears in Listing 5.25 . Listing 5.25: Code to create a translation transformation void matrix4::ToTranslation( const point3& p ) 222 { MakeIdent(); _41 = p.x; _42 = p.y; _43 = p.z; } matrix4 matrix4::Translation( const point3& p ) { matrix4 out; out.ToTranslation( p ); return out; } Basic Rotations The matrices used to rotate around the three principal axes, again, are: The code to set up Euler rotation matrices appears in Listing 5.26 . Listing 5.26: Code to create Euler rotation transformations void matrix4::ToXRot( float theta ) { 223 float c = (float) cos(theta); float s = (float) sin(theta); MakeIdent(); _22=c; _23=s; _32 = -s; _33=c; } matrix4 matrix4::XRot( float theta ) { matrix4 out; out.ToXRot( theta ); return out; } //========== void matrix4::ToYRot( float theta ) { float c = (float) cos(theta); float s = (float) sin(theta); MakeIdent(); _11 = c; _13 = -s; _31 = s; _33 = c; } matrix4 matrix4::YRot( float theta ) { matrix4 out; out.ToYRot( theta ); [...]... _21 = x*y*(1-c )-( z*s); _31 = x*z*(1-c)+(y*s); _41 = 0; _12 = y*x*(1-c)+(z*s); _22 = y*y*(1-c)+c; _32 = y*z*(1-c )-( x*s); _42 = 0; _13 = z*x*(1-c )-( y*s); _23 = z*y*(1-c)+(x*s); _33 = z*z*(1-c)+c; _43 = 0; _ 14 = 0; _ 24 = 0; _ 34 = 0; _44 = 1; } matrix4 matrix4::AxisAngle( const point3& axis, float angle ) { matrix4 out; out.ToAxisAngle( axis, angle ); return out; } 226 The LookAt Matrix I discussed before... } color4& operator += ( const color4& in ); color4& operator -= ( const color4& in ); color4& operator *= ( const color4& in ); color4& operator /= ( const color4& in ); color4& operator *= ( const float& in ); color4& operator /= ( const float& in ); // some basic colors static const color4 Black; static const color4 Gray; static const color4 White; static const color4 Red; static const color4 Green;... values _41 = loc.x; _42 = loc.y; _43 = loc.z; _ 14 = 0; _ 24 = 0; _ 34 = 0; _44 = 1; } matrix4 matrix4::ObjectLookAt( const point3& loc, const point3& lookAt, const point3& inUp ) { 228 matrix4 out; out.ToObjectLookAt( loc, lookAt, inUp ); return out; } //========== void matrix4::ToCameraLookAt( const point3& loc, const point3& lookAt, const point3& inUp ) { point3 viewVec = lookAt - loc;... matrix4::ToInverse( const matrix4& in ) { // first transpose the rotation matrix _11 = in._11; _12 = in._21; _13 = in._31; _21 = in._12; _22 = in._22; _23 = in._32; _31 = in._13; _32 = in._23; _33 = in._33; // fix right column _ 14 = 0; _ 24 = 0; _ 34 = 0; _44 = 1; // now get the new translation vector point3 temp = in.GetLoc(); _41 = -( temp.x * in._11 + temp.y * in._12 + temp.z * in._13); _42 = -( temp.x... _42 = - (loc * upVec); 229 _43 = - (loc * viewVec); _ 14 = 0; _ 24 = 0; _ 34 = 0; _44 = 1; } matrix4 matrix4::CameraLookAt( const point3& loc, const point3& lookAt, const point3& inUp ) { matrix4 out; out.ToCameraLookAt( loc, lookAt, inUp ); return out; } Perspective Projection Matrix Creating a perspective projection matrix will be handled by the graphics layer when I add Direct3D to it in Chapter 8, using... implemented a ray-tracer a while back using two algorithms One was a brute-force, test-every-polygon-against-every-ray nightmare; the other used BSP trees The first algorithm took about 90 minutes to render a single frame with about 15K triangles in it With BSP trees, the rendering time went down to about 45 seconds Saying BSP trees make a big difference is a major understatement 248 It all started... axis-angle matrix transformation appears in Listing 5.27 Listing 5.27: Axis-angle matrix transformation code void matrix4::ToAxisAngle( const point3& inAxis, float angle ) 225 { point3 axis = inAxis.Normalized(); float s = (float)sin( angle ); float c = (float)cos( angle ); float x = axis.x, y = axis.y, z = axis.z; _11 = x*x*(1-c)+c; _21 = x*y*(1-c )-( z*s); _31 = x*z*(1-c)+(y*s); _41 = 0; _12 = y*x*(1-c)+(z*s);... void matrix4::ToZRot( float theta ) { float c = (float) cos(theta); float s = (float) sin(theta); MakeIdent(); _11 = c; _12 = s; _21 = -s; _22 = c; } matrix4 matrix4::ZRot( float theta ) { matrix4 out; out.ToZRot( theta ); return out; } Axis-Angle Rotation While there isn't enough space to provide a derivation of the axis-angle rotation matrix, that doesn't stop it from being cool Axis-angle rotations... temp.z * in._13); _42 = -( temp.x * in._21 + temp.y * in._22 + temp.z * in._23); _43 = -( temp.x * in._31 + temp.y * in._32 + temp.z * in._33); } matrix4 matrix4::Inverse( const matrix4& in ) { 231 matrix4 out; out.ToInverse( in ); return out; } Collision Detection with Bounding Spheres Up until now, when I talked about moving 3D objects around, I did so completely oblivious to wherever they may be moving... being cool Axis-angle rotations are the most useful matrix-based rotation (I say matrix-based because quaternions are faster and more flexible than matrix rotations; see Real-Time Rendering by Tomas Moller and Eric Haines for a good discussion on them.) There are a few problems with using just Euler rotation matrices (the x-rotation, y-rotation, z-rotation matrices you've seen thus far) For starters, . x*x*(1-c)+c; _21 = x*y*(1-c )-( z*s); _31 = x*z*(1-c)+(y*s); _41 = 0; _12 = y*x*(1-c)+(z*s); _22 = y*y*(1-c)+c; _32 = y*z*(1-c )-( x*s); _42 = 0; _13 = z*x*(1-c )-( y*s); _23 = z*y*(1-c)+(x*s);. translation values _41 = - (loc * rightVec); _42 = - (loc * upVec); 230 _43 = - (loc * viewVec); _ 14 = 0; _ 24 = 0; _ 34 = 0; _44 = 1; } matrix4 matrix4::CameraLookAt( const. IN_32; _33 = IN_33; _ 34 = IN_ 34; _41 = IN _41 ; _42 = IN _42 ; _43 = IN _43 ; _44 = IN _44 ; } matrix4() { // Do nothing. } static const matrix4 Identity; }; The code contains three