Is The View Matrix The Camera Transform

Article - World, View and Projection Transformation Matrices

Introduction

In this commodity nosotros will try to understand in details i of the core mechanics of whatsoever 3D engine, the chain of matrix transformations that allows to represent a 3D object on a 2D monitor. We volition try to enter into the details of how the matrices are constructed and why, and then this article is non meant for absolute beginners.I will assume general knowledge of vectors math and matrices math.

We will first talk about the relationship between transformations and vector spaces. And so we will testify how a transformation tin be represented in matrix form. From there nosotros will show the typical sequence of transformations that you will need to apply, which is fromModel toWorld Space, then toCameraand soProjection.

Vector Spaces: Model Space and Earth Infinite

A vector space is a mathematical structure that is defined by a given number of linearly independent vectors, too called base vectors (for example in Figure ane there are three base vectors); the number of linearly contained vectors defines the size of the vector space, therefore a 3D infinite has 3 base vectors, while a 2d infinite would have two. These base of operations vectors tin can be scaled and added toghether to obtain all the other vectors in the space. Vector spaces is quite a wide topic, and it's non the goal of this article to explain them in particular, all we need to know for our purposes is that our models live in one specific vector infinite, which goes under the name of Model Infinite and it's represented with the approved3D coordinates system(Figure one).

When an creative person authors a 3D model he creates all the vertices and faces relatively to the 3D coordinate system of the tool he is working in, which is the Model Space. All the vertices are relative to the origin of the Model Infinite, and so if we have a point at coordinates (1,ane,one) in Model Infinite, we know exactly where it is (Figure 2).

Every model in the game lives in its own Model Space and if you desire them to be in any spatial relation (similar if y'all want to put a teapot over a table) you need to transform them into a mutual space (which is what is frequently chosenEarth Space).

Figure one:Standard Right Handed 3D Coordinate System

Figure ii:Vertex of the teapot in position (1,1,i)

Let me stress this again. It's of import to sympathize that a vector only makes sense within a coordinate arrangement; if we don't specify the space we tin can't represent any signal. Once the model is exported from the tool to the game engine, all the vertices are represented in Model Infinite. Now, if nosotros want to put the object we only imported in the game world, we will need to move it and/or rotate it to the desired position, and this volition put the object into World Space.Moving, rotating or scaling an object it's what nosotros call atransformation. When all the objects have been transformed into a common space (the Globe Space) their vertices will be relative to the Globe Infinite itself.

Transformation

We can meet transformations in a vector infinite merely as a change from one space to another. This is 1 of the trickiest bits of vector transformations, so let'southward try to make information technology as clear every bit possible.
We can imagine a vector infinite in 3d as three orthogonal axis (as in Figure 1). We always need to take an "active" infinite, which is the space that nosotros are using equally a reference for everything else (either geometry or other spaces). If nosotros have ii models, each 1 in its ain Model Space, nosotros can't draw them both until we ascertain a common "agile" space.
Now let's say that nosotros outset with an agile space, telephone call information technology SpaceA, that contains a teapot. Nosotros now want to utilise a transformation that moves everything in Space A into a new position; simply if nosotros move Infinite A we then demand to define a new "active" infinite to represent the transformed Infinite A. Allow's call the new agile space Space B (Figure iii). Before the transformation, whatsoever point described in Infinite A, was relative to the origin of that space (as described in Figure 3 on the left). Later on we have applied the transformation all the points are now relative to the new active infinite, Space B (Effigy 3, right). Any operation that re-defines Infinite A relatively to Space B is a transformation. Notice how, after the transformation, Space A is at present "lost" into Infinite B, or more precisely it'south re-mapped into Space B, so we have no way to apply any other transformations to it (unless nosotros undo the transformation and make Space A the 'active' space again).

Another way of seeing this is, imagine that anything in a space moves with the base of operations vectors, and imagine that Space A starts perfectly overlapped over Space B. When we utilise the transformation we move Space A away from Space B, and anything in Infinite A moves with it. Once we have moved all the vertices we then represent all of them equally relative to Space B, and we have completed the transformation.

In case we need to operate in Infinite A over again it's possible to apply the inverse of the transformation to Space B. Doing and so Infinite B will exist re-mapped into Space A again (and at this point, nosotros "lose" Infinite B). If we know both transformations and their inverse we can e'er re-map the two spaces 1 to the other.

Figure 3: Space Transformations

The transformations that nosotros can use in vector spaces are calibration, translation and rotation. Information technology'south important to observe that every transformation is always relative to the origin, which makes the order we use to apply the transformations themselves very important. If we rotate 90° left and then translate we obtain something very different to what we become if nosotros outset translate and then rotate 90° (Figure 4, I've omitted any infinite apart from the active one).

Figure 4:Different results from aforementioned transformations practical in a different society

Figure 4 can also aid u.s.a. understanding the changed of a transformation a bit more. Then if you lot take Figure 4 meridian left, the xc° rotation to the left transformation can be removed with it's inverse, which is a xc° rotation to the right. Notice how the changed of a transformation is a transformation itself, then at that place is no reason why we shouldn't apply it to objects that are in a completely unrelated infinite. The inverse of the 90° transformation to the left is a xc° transformation to the right, which obviously can be applied to anything in any infinite.

Transformation Matrix

Now that we empathize that a transformation is a change from one infinite to another we can get to the math. If we want to represent a transformation from one 3D space to some other nosotros volition demand a 4x4 Matrix. I will presume from here on a column vector note, as in OpenGL. If you are into row vectors, y'all only need to transpose the matrix and premultiply the vector where I post multiply information technology. In order to apply the transformation we have to multiply all the vectors that we desire to transform confronting the transformation matrix. If vectors were in Space A and the transformation was describing a new position of Space A relative to Space B, after the multiplication all the vectors would so be described in Space B.
At present, let'south meet how we stand for a generic transformation in matrix form:

Where Transform_XAxis is the XAxis orientation in the new space,Transform _YAxis is the YAxis orientation in the new space,Transform _ZAxis is the ZAxis orientation in the new space and Translationdescribes the position where the new space is going to be relatively to the active infinite.

Sometimes we want to practise unproblematic transformations, like translations or rotations; in these cases we may utilize the following matrices which are special cases of the generic class we accept merely presented.

Translation Matrix:

Where translation is a 3D vector that represent the position where nosotros want to move our space to. A translation matrix leaves all the axis rotated exactly every bit the agile infinite.

Scale Matrix:

Where scale is a 3D vector that represent the scale along each axis. If you read the starting time column you can come across how the new X axis it'southward still facing the same direction but it's scaled by the scalar scale.x. The same happens to all the other axis as well. Besides notice how the translation column is all zeros, which means no translation is required.

Rotation Matrix around 10 Axis:

Where theta is the angle we want to utilize for our rotation. Notice how the first column will never change, which is expected since nosotros are rotating around the 10 axis. As well notice how change theta to 90° remaps the Y axis into the Z centrality and the Z centrality into -Y axis.

Rotation Matrix around Y Centrality:

Rotation Matrix around Z Axis:

The rotation matrices for the Z axis and the Y centrality behave in the same way of the Ten centrality matrix.

The matrices I've just presented to yous are the near used ones and they are all you need to describe rigid transformations. You can chain several transformations together past multiplying matrices one later on the other. The consequence will exist a unmarried matrix that encodes the full transformation. As we have seen in the transformation section, the order that nosotros utilise to utilize transformations is very important. This is mirrored in math by the fact that matrix multiplication is non commutative. Therefore in general Translate 10 Rotate is unlike from Rotate x Translate.

Since we are using column vectors we will have to read a chain of transformation right to left, then if we want to rotate xc° to the left around the Y axis, and then interpret of x units along the Z centrality the chain will be [Translate ten forth X]x [RotateY xc°] = [ComposedTransformation].

Let's put some numbers into this then that nosotros can see how it works. Allow'due south say we want to transform the sphere in Effigy 5. For simplicity we will utilise the transformation just to the meridian vertex of the sphere which is in position (0,one,0) in Model Space. We volition summate where it'south going to be in Globe Space. Commencement of all we ascertain the transformation matrix. Say that we want the sphere to exist placed in the World Space and it will be rotated around the Y axis for ninety° clockwise, then rotated 180° effectually the Ten axis, and so translated into (1.5, 1, ane.5). This ways that the transformation matrix volition be:

Please detect how the Result matrix perfectly fits the Generic Transformation formula that we take presented. In Earth Space the Ten axis is now oriented as the Z axis of that space therefore information technology'southward now (0,0,1). The Y axis is at present flipped upside downward, hence (0,-1,0). The Z axis is at present oriented as the X axis, (ane,0,0). Finally, the translation vector (1.five, 1, 1.5).

Once we take the result we can multiply any vertex of the sphere to change it from Model Infinite into World Space. Allow'due south do our vertex (0,one,0). Observe that since we use a 4x4 matrix we need to utilize homogeneous coordinates, there fore nosotros need a four dimensions vector that has 1 in the last component.

Effigy 5: Sphere transformed from model space to world space

Model Space, World Infinite, View Space

Now nosotros have all the pieces of the puzzle, let's put them together. The first pace when we want to to render a 3D scene is to put all the models in the same space, the Earth Space. Since every object will exist in its own position and orientation in the globe, every 1 has a unlike Model to Globe transformation matrix.

Effigy 6: Three teapots each ane in its ain model space

Figure vii: Three teapots set in World Infinite

With all the objects at the right place we now need to project them to the screen. This is commonly done in two steps. The first pace moves all the object in another space chosen the View Space. The second step performs the actual project using the project matrix. This final pace is a fleck dissimilar from the others and we will run into information technology in detail in a moment.

Why do we need a View Infinite? The View Infinite is an auxiliary space that nosotros use to simplify the math and keep everything elegant and encoded into matrices. The idea is that we demand to render to a camera, which implies projecting all the vertices onto the camera screen that can exist arbitrarily oriented in space. The math simplifies a lot if we could have the photographic camera centered in the origin and watching downwards one of the three axis, permit'south say the Z centrality to stick to the convention. So why not to create a space that is doing exaclty this, remapping the World Infinite then that the photographic camera is in the origin and looks downward along the Z centrality? This space is the View Space (sometimes calledPhotographic camera Infinite) and the transformation we apply moves all the vertices from Earth Infinite to View Space.
How practice we calculate the transformation matrix for View Space? At present, if y'all imagine you want to put the camera in Globe Infinite you would use a transformation matrix that is located where the photographic camera is and is oriented so that the Z axis is looking to the camera target. The changed of this transformation, if applied to all the objects in Globe Space, would move the entire world into View Space. Notice that we tin can combine the two transformations Model To World and World to View into a single transformation Model To View.

Figure 8: On the Left two teapots and a camera in World Infinite; On the right everything is transformed into View Infinite (World Space is represented only to help visualize the transformation)

Projection Space

The scene is now in the most friendly space possible for a projection, the View Space. All we have to do now is to project it onto the imaginary screen of the camera. Earlier flattening the image, nosotros still have to move into some other, final infinite, the Projection Space. This space is a cuboid which dimensions are between -one and 1 for every axis. This space is very handy for clipping (annihilation outside the one:-1 range is outside the photographic camera view area) and simplifies the flattening operation (we just need to drop the z value to get a flat image).
To go from the View Space into the Project Space we need some other matrix, the View to Projection matrix, and the values of this matrix depend on what type of projection nosotros want to perform. The two nigh used projections are the Orthographic Projection and the Perspective Project.

To do the Orthographic projection we have to define the size of the surface area that the camera can run across. This is usually defined with a width and summit values for the x and y axis, and a well-nigh and far z values for the z axis (Figure 9).

Effigy 9: Orthographic Projection

Given these values we tin can create the transformation matrix that remaps the box area into the cuboid. The matrix that follows is transforms vectors from View Space into Ortho Projected Space and assumes a right handed coordinates arrangement.

Figure 10: Projection Space obtained from the teapot in Effigy nine

The other projection is the perspective project. The thought is like to the orthographic projection, but this fourth dimension the view expanse is a frustum and therefore it's a bit more tricky to remap. Unfortunately the matrix multiplication in this case is non enough, because after multiplying by the matrix the issue is not on the same projective infinite (which means that the w component is not 1 for every vertex). To complete the transformation we will need to divide every component of the vector by the west component itself. Current graphics APIs exercise the division for you, therefore y'all can merely multiply all your vertices past the perspective projection matrix and send the upshot to the GPU.

GPU takes care of dividing past westward, clipping those vertices exterior the cuboid area, flattening the image dropping the z component, re-mapping everything from the -1 to 1 range into the 0 to one range and and then calibration it to the viewport width and height, and rasterizing the triangles to the screen (if you are doing the rasterization on the CPU you will accept to take care of these steps yourself). We can therefore accept these concluding steps for granted if nosotros return via OpenGL or DirectX, so the perspective infinite is the last step of our concatenation of transformation.

Finally a model can be transformed for rendering chaining [View To Projection]x[World To View]x[Model to World]=[ModelViewProjectionMatrix].