• Homogeneous coordinates
  • Transformation matrices
    • An introduction to matrices
    • Translation matrices
    • The Identity matrix
    • Scaling matrices
    • Rotation matrices
    • Cumulating transformations
  • The Model, View and Projection matrices
    • The Model matrix
    • The View matrix
    • The Project matrix
    • Cumulating transformations : the ModelViewProjection matrix
  • Putting it all together
  • Exercises

The engines don't motility the send at all. The ship stays where it is and the engines move the universe around it.

Futurama

This is the single most important tutorial of the whole set. Exist certain to read information technology at to the lowest degree eight times.

Homogeneous coordinates

Until and so, we merely considered 3D vertices as a (x,y,z) triplet. Let's introduce w. We will now accept (x,y,z,w) vectors.

This will be more than clear presently, only for now, merely remember this :

  • If westward == ane, then the vector (10,y,z,i) is a position in infinite.
  • If westward == 0, and so the vector (ten,y,z,0) is a direction.

(In fact, call up this forever.)

What deviation does this make ? Well, for a rotation, information technology doesn't change anything. When you rotate a point or a direction, you get the aforementioned result. Nevertheless, for a translation (when you move the point in a certain direction), things are different. What could hateful "translate a direction" ? Not much.

Homogeneous coordinates permit u.s.a. to use a single mathematical formula to bargain with these ii cases.

Transformation matrices

An introduction to matrices

Simply put, a matrix is an array of numbers with a predefined number of rows and colums. For instance, a 2x3 matrix can await similar this :

In 3D graphics we volition by and large use 4x4 matrices. They volition allow us to transform our (x,y,z,due west) vertices. This is done by multiplying the vertex with the matrix :

Matrix x Vertex (in this social club !!) = TransformedVertex

This isn't as scary as it looks. Put your left finger on the a, and your right finger on the 10. This is ax. Motility your left finger to the next number (b), and your right finger to the adjacent number (y). You've got by. Once again : cz. Once more : dw. ax + past + cz + dw. Y'all've got your new ten ! Do the same for each line, and y'all'll get your new (x,y,z,w) vector.

Now this is quite boring to compute, an we will practise this oftentimes, so let'due south ask the computer to do it instead.

In C++, with GLM: 

                          glm              ::              mat4              myMatrix              ;              glm              ::              vec4              myVector              ;              // fill myMatrix and myVector somehow                            glm              ::              vec4              transformedVector              =              myMatrix              *              myVector              ;              // Once again, in this order ! this is important.

In GLSL : 

                          mat4              myMatrix              ;              vec4              myVector              ;              // make full myMatrix and myVector somehow                            vec4              transformedVector              =              myMatrix              *              myVector              ;              // Yeah, it's pretty much the same than GLM

( take y'all cutting'due north pasted this in your code ? get on, endeavor information technology)

Translation matrices

These are the most simple tranformation matrices to sympathize. A translation matrix await similar this :

where Ten,Y,Z are the values that yous want to add to your position.

And then if we want to interpret the vector (ten,x,x,1) of ten units in the X direction, we get :

(do information technology ! doooooo it)

… and we get a (xx,ten,10,1) homogeneous vector ! Recall, the 1 means that it is a position, non a direction. So our transformation didn't change the fact that we were dealing with a position, which is good.

Permit's now see what happens to a vector that represents a direction towards the -z centrality : (0,0,-1,0)

… ie our original (0,0,-1,0) direction, which is great because equally I said ealier, moving a direction does not make sense.

So, how does this translate to code ?

In C++, with GLM: 

                          #include <glm/gtx/transform.hpp> // after <glm/glm.hpp>                            glm              ::              mat4              myMatrix              =              glm              ::              interpret              (              glm              ::              mat4              (),              glm              ::              vec3              (              10.0              f              ,              0.0              f              ,              0.0              f              ));              glm              ::              vec4              myVector              (              10.0              f              ,              10.0              f              ,              x.0              f              ,              0.0              f              );              glm              ::              vec4              transformedVector              =              myMatrix              *              myVector              ;              // judge the result

In GLSL : 

                          vec4              transformedVector              =              myMatrix              *              myVector              ;

Well, in fact, you almost never do this in GLSL. Nigh of the fourth dimension, yous apply glm::translate() in C++ to compute your matrix, send it to GLSL, and exercise only the multiplication :

The Identity matrix

This ane is special. Information technology doesn't practise annihilation. But I mention information technology because it's as important equally knowing that multiplying A by i.0 gives A.

In C++ : 

                          glm              ::              mat4              myIdentityMatrix              =              glm              ::              mat4              (              1.0              f              );

Scaling matrices

Scaling matrices are quite easy as well :

So if you want to scale a vector (position or direction, it doesn't matter) past 2.0 in all directions :

and the w notwithstanding didn't alter. Y'all may ask : what is the pregnant of "scaling a direction" ? Well, often, not much, so yous usually don't do such a thing, but in some (rare) cases it can be handy.

(detect that the identity matrix is but a special instance of scaling matrices, with (X,Y,Z) = (1,ane,ane). It's too a special case of translation matrix with (X,Y,Z)=(0,0,0), by the style)

In C++ : 

                          // Apply #include <glm/gtc/matrix_transform.hpp> and #include <glm/gtx/transform.hpp>                            glm              ::              mat4              myScalingMatrix              =              glm              ::              scale              (              ii.0              f              ,              2.0              f              ,              two.0              f              );

Rotation matrices

These are quite complicated. I'll skip the details hither, as it's non important to know their exact layout for everyday use. For more than information, please have a look to the Matrices and Quaternions FAQ (popular resource, probably available in your language likewise). You tin besides accept a look at the Rotations tutorials

In C++ : 

                          // Use #include <glm/gtc/matrix_transform.hpp> and #include <glm/gtx/transform.hpp>                            glm              ::              vec3              myRotationAxis              (              ??              ,              ??              ,              ??              );              glm              ::              rotate              (              angle_in_degrees              ,              myRotationAxis              );

Cumulating transformations

Then now we know how to rotate, translate, and calibration our vectors. It would be great to combine these transformations. This is done by multiplying the matrices together, for instance :

                          TransformedVector              =              TranslationMatrix              *              RotationMatrix              *              ScaleMatrix              *              OriginalVector              ;

!!! BEWARE !!! This lines actually performs the scaling FIRST, and And then the rotation, and And so the translation. This is how matrix multiplication works.

Writing the operations in some other order wouldn't produce the same effect. Try it yourself :

  • make one step alee ( beware of your computer ) and turn left;

  • plow left, and make one step alee

As a thing of fact, the order to a higher place is what yous will usually need for game characters and other items : Scale information technology first if needed; and so fix its direction, then translate it. For instance, given a ship model (rotations take been removed for simplification) :

  • The incorrect mode :
    • You translate the ship by (x,0,0). Its center is now at 10 units of the origin.
    • Y'all scale your ship by 2. Every coordinate is multiplied past 2 relative to the origin, which is far abroad… So you terminate upward with a large ship, but centered at 2*10 = 20. Which you don't want.
  • The correct way :
    • You scale your ship by 2. You get a big ship, centered on the origin.
    • You translate your send. It's still the aforementioned size, and at the right altitude.

Matrix-matrix multiplication is very similar to matrix-vector multiplication, so I'll one time once again skip some details and redirect you the the Matrices and Quaternions FAQ if needed. For now, we'll but inquire the figurer to exercise it :

in C++, with GLM : 

                          glm              ::              mat4              myModelMatrix              =              myTranslationMatrix              *              myRotationMatrix              *              myScaleMatrix              ;              glm              ::              vec4              myTransformedVector              =              myModelMatrix              *              myOriginalVector              ;

in GLSL : 

                          mat4              transform              =              mat2              *              mat1              ;              vec4              out_vec              =              transform              *              in_vec              ;

The Model, View and Projection matrices

For the residual of this tutorial, we volition suppose that we know how to draw Blender's favourite 3d model : the monkey Suzanne.

The Model, View and Projection matrices are a handy tool to separate transformations cleanly. You lot may non employ this (after all, that's what we did in tutorials 1 and 2). But you should. This is the way everybody does, because it'due south easier this way.

The Model matrix

This model, just every bit our beloved red triangle, is divers by a gear up of vertices. The X,Y,Z coordinates of these vertices are divers relative to the object'due south centre : that is, if a vertex is at (0,0,0), it is at the center of the object.

We'd like to be able to move this model, maybe because the player controls it with the keyboard and the mouse. Like shooting fish in a barrel, you but learnt exercise practice and then : translation*rotation*scale, and washed. You apply this matrix to all your vertices at each frame (in GLSL, not in C++!) and everything moves. Something that doesn't move will be at the center of the world.

Your vertices are now in World Space. This is the meaning of the black arrow in the epitome below : We went from Model Space (all vertices defined relatively to the center of the model) to World Space (all vertices defined relatively to the center of the world).

We can sum this upward with the following diagram :

The View matrix

Let'southward quote Futurama again :

The engines don't move the transport at all. The ship stays where information technology is and the engines move the universe around information technology.

When you call up about it, the same applies to cameras. It you desire to view a moutain from another angle, yous can either move the camera… or motion the mountain. While non practical in real life, this is really simple and handy in Computer Graphics.

So initially your photographic camera is at the origin of the World Space. In order to move the earth, you simply introduce another matrix. Let's say you lot want to move your camera of 3 units to the right (+Ten). This is equivalent to moving your whole world (meshes included) 3 units to the LEFT ! (-10). While you brain melts, let's do it :

                          // Use #include <glm/gtc/matrix_transform.hpp> and #include <glm/gtx/transform.hpp>                            glm              ::              mat4              ViewMatrix              =              glm              ::              interpret              (              glm              ::              mat4              (),              glm              ::              vec3              (              -              three.0              f              ,              0.0              f              ,              0.0              f              ));

Again, the prototype below illustrates this : We went from Earth Space (all vertices divers relatively to the center of the world, as nosotros made and then in the previous department) to Camera Space (all vertices defined relatively to the camera).

Earlier you head explodes from this, bask GLM's slap-up glm::lookAt function:

                          glm              ::              mat4              CameraMatrix              =              glm              ::              lookAt              (              cameraPosition              ,              // the position of your photographic camera, in world space                            cameraTarget              ,              // where you want to expect at, in earth infinite                            upVector              // probably glm::vec3(0,i,0), but (0,-1,0) would brand you looking upside-down, which can exist groovy too                            );

Here'south the compulsory diagram :

This is not over nevertheless, though.

The Projection matrix

Nosotros're at present in Photographic camera Space. This means that after all theses transformations, a vertex that happens to have x==0 and y==0 should be rendered at the middle of the screen. But we tin't apply just the x and y coordinates to decide where an object should be put on the screen : its distance to the photographic camera (z) counts, too ! For 2 vertices with similar x and y coordinates, the vertex with the biggest z coordinate will be more on the center of the screen than the other.

This is chosen a perspective projection :

And luckily for us, a 4x4 matrix tin can represent this project1 :

                          // Generates a really hard-to-read matrix, just a normal, standard 4x4 matrix yet                            glm              ::              mat4              projectionMatrix              =              glm              ::              perspective              (              glm              ::              radians              (              FoV              ),              // The vertical Field of View, in radians: the amount of "zoom". Call up "camera lens". Normally betwixt 90° (extra broad) and 30° (quite zoomed in)                            4.0              f              /              three.0              f              ,              // Aspect Ratio. Depends on the size of your window. Notice that four/3 == 800/600 == 1280/960, sounds familiar ?                            0.1              f              ,              // Near clipping plane. Go along as big as possible, or you lot'll get precision issues.                            100.0              f              // Far clipping aeroplane. Go along every bit little every bit possible.                            );

One last time :

Nosotros went from Photographic camera Space (all vertices divers relatively to the camera) to Homogeneous Infinite (all vertices defined in a modest cube. Everything inside the cube is onscreen).

And the final diagram :

Here'southward another diagram so that y'all empathize amend what happens with this Projection stuff. Before project, we've got our blueish objects, in Camera Space, and the cerise shape represents the frustum of the photographic camera : the part of the scene that the camera is actually able to see.

Multiplying everything past the Projection Matrix has the following effect :

In this image, the frustum is now a perfect cube (between -1 and 1 on all axes, it's a fiddling bit difficult to see it), and all bluish objects take been deformed in the aforementioned way. Thus, the objects that are most the photographic camera ( = near the face of the cube that we tin can't see) are big, the others are smaller. Seems like real life !

Let'southward see what it looks like from the "behind" the frustum :

Here you get your epitome ! It'south but a little bit as well foursquare, then another mathematical transformation is applied (this one is automatic, you don't have to practice it yourself in the shader) to fit this to the actual window size :

And this is the paradigm that is actually rendered !

Cumulating transformations : the ModelViewProjection matrix

… Just a standard matrix multiplication as y'all already honey them !

                          // C++ : compute the matrix                            glm              ::              mat4              MVPmatrix              =              projection              *              view              *              model              ;              // Call up : inverted !                                    
                          // GLSL : utilize it                            transformed_vertex              =              MVP              *              in_vertex              ;

Putting it all together

  • First step : include the GLM GTC matrix transform functions:
                          #include <glm/gtc/matrix_transform.hpp>

  • Second step : generating our MVP matrix. This must be done for each model you render.

                                      // Projection matrix : 45° Field of View, 4:three ratio, brandish range : 0.1 unit of measurement <-> 100 units                                    glm                  ::                  mat4                  Projection                  =                  glm                  ::                  perspective                  (                  glm                  ::                  radians                  (                  45.0                  f                  ),                  (                  bladder                  )                  width                  /                  (                  float                  )                  height                  ,                  0.1                  f                  ,                  100.0                  f                  );                  // Or, for an ortho camera : //glm::mat4 Projection = glm::ortho(-10.0f,10.0f,-10.0f,ten.0f,0.0f,100.0f); // In world coordinates                                    // Photographic camera matrix                                    glm                  ::                  mat4                  View                  =                  glm                  ::                  lookAt                  (                  glm                  ::                  vec3                  (                  iv                  ,                  3                  ,                  iii                  ),                  // Camera is at (4,3,3), in World Space                                    glm                  ::                  vec3                  (                  0                  ,                  0                  ,                  0                  ),                  // and looks at the origin                                    glm                  ::                  vec3                  (                  0                  ,                  1                  ,                  0                  )                  // Head is upwardly (gear up to 0,-1,0 to expect upside-down)                                    );                  // Model matrix : an identity matrix (model will exist at the origin)                                    glm                  ::                  mat4                  Model                  =                  glm                  ::                  mat4                  (                  ane.0                  f                  );                  // Our ModelViewProjection : multiplication of our 3 matrices                                    glm                  ::                  mat4                  mvp                  =                  Project                  *                  View                  *                  Model                  ;                  // Retrieve, matrix multiplication is the other way around

  • Tertiary stride : requite it to GLSL

                                      // Get a handle for our "MVP" uniform // Only during the initialisation                                    GLuint                  MatrixID                  =                  glGetUniformLocation                  (                  programID                  ,                  "MVP"                  );                  // Ship our transformation to the currently leap shader, in the "MVP" compatible // This is washed in the main loop since each model will take a different MVP matrix (At least for the M part)                                    glUniformMatrix4fv                  (                  MatrixID                  ,                  1                  ,                  GL_FALSE                  ,                  &                  mvp                  [                  0                  ][                  0                  ]);

  • Fourth step : use information technology in GLSL to transform our vertices in SimpleVertexShader.vertexshader 

                                      // Input vertex information, dissimilar for all executions of this shader.                                    layout                  (                  location                  =                  0                  )                  in                  vec3                  vertexPosition_modelspace                  ;                  // Values that stay constant for the whole mesh.                                    compatible                  mat4                  MVP                  ;                  void                  main                  (){                  // Output position of the vertex, in clip infinite : MVP * position                                    gl_Position                  =                  MVP                  *                  vec4                  (                  vertexPosition_modelspace                  ,                  1                  );                  }

  • Washed ! Hither is the same triangle as in tutorial two, withal at the origin (0,0,0), but viewed in perspective from point (four,3,iii), heads upwardly (0,1,0), with a 45° field of view.

In tutorial six you'll larn how to modify these values dynamically using the keyboard and the mouse to create a game-similar camera, but first, we'll learn how to give our 3D models some colour (tutorial four) and textures (tutorial five).

Exercises

  • Try changing the glm::perspective
  • Instead of using a perspective projection, utilise an orthographic projection (glm::ortho)
  • Modify ModelMatrix to translate, rotate, then scale the triangle
  • Do the aforementioned thing, merely in different orders. What do you detect ? What is the "best" order that you would want to use for a character ?

Addendum