+
+The formula above is just the generalisation to 3D.
+
+Now we want to compute the "up" vector reliably. Notice that "up" isn't always towards +Y : if you look down, for instance, the "up" vector will be in fact horizontal. Here is an example of to cameras with the same position, the same target, but a different up:
+
+
+
+In our case, the only constant is that the vector goes to the right of the camera is always horizontal. You can check this by putting your arm horizontal, and looking up, down, in any direction. So let's define the "right" vector : its Y coordinate is 0 since it's horizontal, and its X and Z coordinates are just like in the figure above, but with the angles rotated by 90°, or Pi/2 radians.
+
+``` cpp
+// Right vector
+glm::vec3 right = glm::vec3(
+ sin(horizontalAngle - 3.14f/2.0f),
+ 0,
+ cos(horizontalAngle - 3.14f/2.0f)
+);
+```
+
+We have a "right" vector and a "direction", or "front" vector. The "up" vector is a vector that is perpendicular to these two. A useful mathematical tool makes this very easy : the cross product.
+
+``` cpp
+// Up vector : perpendicular to both direction and right
+glm::vec3 up = glm::cross( right, direction );
+```
+
+To remember what the cross product does, it's very simple. Just recall the Right Hand Rule from Tutorial 3. The first vector is the thumb; the second is the index; and the result is the middle finger. It's very handy.
+
+## Position
+
+The code is pretty straightforward. By the way, I used the up/down/right/left keys instead of the awsd because on my azerty keyboard, awsd is actually zqsd. And it's also different with qwerZ keyboards, let alone korean keyboards. I don't even know what layout korean people have, but I guess it's also different.
+
+``` cpp
+// Move forward
+if (glfwGetKey( GLFW_KEY_UP ) == GLFW_PRESS){
+ position += direction * deltaTime * speed;
+}
+// Move backward
+if (glfwGetKey( GLFW_KEY_DOWN ) == GLFW_PRESS){
+ position -= direction * deltaTime * speed;
+}
+// Strafe right
+if (glfwGetKey( GLFW_KEY_RIGHT ) == GLFW_PRESS){
+ position += right * deltaTime * speed;
+}
+// Strafe left
+if (glfwGetKey( GLFW_KEY_LEFT ) == GLFW_PRESS){
+ position -= right * deltaTime * speed;
+}
+```
+
+The only special thing here is the deltaTime. You don't want to move from 1 unit each frame for a simple reason :
+
+* If you have a fast computer, and you run at 60 fps, you'd move of 60*speed units in 1 second
+* If you have a slow computer, and you run at 20 fps, you'd move of 20*speed units in 1 second
+
+Since having a better computer is not an excuse for going faster, you have to scale the distance by the "time since the last frame", or "deltaTime".
+
+* If you have a fast computer, and you run at 60 fps, you'd move of 1/60 * speed units in 1 frame, so 1*speed in 1 second.
+* If you have a slow computer, and you run at 20 fps, you'd move of 1/20 * speed units in 1 second, so 1*speed in 1 second.
+
+which is much better. deltaTime is very simple to compute :
+
+``` cpp
+double currentTime = glfwGetTime();
+float deltaTime = float(currentTime - lastTime);
+```
+
+## Field Of View
+
+For fun, we can also bind the wheel of the mouse to the Field Of View, so that we can have a cheap zoom :
+
+``` cpp
+float FoV = initialFoV - 5 * glfwGetMouseWheel();
+```
+
+## Computing the matrices
+
+Computing the matrices is now straightforward. We use the exact same functions than before, but with our new parameters.
+
+``` cpp
+// Projection matrix : 45° Field of View, 4:3 ratio, display range : 0.1 unit <-> 100 units
+ProjectionMatrix = glm::perspective(glm::radians(FoV), 4.0f / 3.0f, 0.1f, 100.0f);
+// Camera matrix
+ViewMatrix = glm::lookAt(
+ position, // Camera is here
+ position+direction, // and looks here : at the same position, plus "direction"
+ up // Head is up (set to 0,-1,0 to look upside-down)
+);
+```
+
+# Results
+
+
+
+
+## Backface Culling
+
+Now that you can freely move around, you'll notice that if you go inside the cube, polygons are still displayed. This can seem obvious, but this remark actually opens an opportunity for optimisation. As a matter of fact, in a usual application, you are never _inside_ a cube.
+
+The idea is to let the GPU check if the camera is behind, or in front of, the triangle. If it's in front, display the triangle; if it's behind, *and* the mesh is closed, *and* we're not inside the mesh, *then* there will be another triangle in front of it, and nobody will notice anything, except that everything will be faster : 2 times less triangles on average !
+
+The best thing is that it's very easy to check this. The GPU computes the normal of the triangle (using the cross product, remember ?) and checks whether this normal is oriented towards the camera or not.
+
+This comes at a cost, unfortunately : the orientation of the triangle is implicit. This means that is you invert two vertices in your buffer, you'll probably end up with a hole. But it's generally worth the little additional work. Often, you just have to click "invert normals" in your 3D modeler (which will, in fact, invert vertices, and thus normals) and everything is just fine.
+
+Enabling backface culling is a breeze :
+
+``` cpp
+// Cull triangles which normal is not towards the camera
+glEnable(GL_CULL_FACE);
+```
+
+# Exercices
+
+
+* Restrict verticalAngle so that you can't go upside-down
+* Create a camera that rotates around the object ( position = ObjectCenter + ( radius * cos(time), height, radius * sin(time) ) ); bind the radius/height/time to the keyboard/mouse, or whatever
+* Have fun !
+
+
diff --git a/pt/beginners-tutorials/tutorial-7-model-loading/index.markdown b/pt/beginners-tutorials/tutorial-7-model-loading/index.markdown
new file mode 100644
index 000000000..7bd644b40
--- /dev/null
+++ b/pt/beginners-tutorials/tutorial-7-model-loading/index.markdown
@@ -0,0 +1,270 @@
+---
+layout: tutorial
+status: publish
+published: true
+title: 'Tutorial 7 : Model loading'
+date: '2011-05-08 17:48:12 +0200'
+date_gmt: '2011-05-08 17:48:12 +0200'
+categories: [tuto]
+order: 70
+tags: []
+---
+
+* TOC
+{:toc}
+
+Until now, we hardcoded our cube directly in the source code. I'm sure you will agree that this was cumbersome and not very handy.
+
+In this tutorial we will learn how to load 3D meshes from files. We will do this just like we did for the textures : we will write a tiny, very limited loader, and I'll give you some pointers to actual libraries that can do this better that us.
+
+To keep this tutorial as simple as possible, we'll use the OBJ file format, which is both very simple and very common. And once again, to keep things simple, we will only deal with OBJ files with 1 UV coordinate and 1 normal per vertex (you don't have to know what a normal is right now).
+
+# Loading the OBJ
+
+Our function, located in common/objloader.cpp and declared in common/objloader.hpp, will have the following signature :
+
+``` cpp
+bool loadOBJ(
+ const char * path,
+ std::vector < glm::vec3 > & out_vertices,
+ std::vector < glm::vec2 > & out_uvs,
+ std::vector < glm::vec3 > & out_normals
+)
+```
+
+We want loadOBJ to read the file "path", write the data in out_vertices/out_uvs/out_normals, and return false if something went wrong. std::vector is the C++ way to declare an array of glm::vec3 which size can be modified at will: it has nothing to do with a mathematical vector. Just an array, really. And finally, the & means that function will be able to modify the std::vectors.
+
+## Example OBJ file
+
+An OBJ file looks more or less like this :
+
+```
+# Blender3D v249 OBJ File: untitled.blend
+# www.blender3d.org
+mtllib cube.mtl
+v 1.000000 -1.000000 -1.000000
+v 1.000000 -1.000000 1.000000
+v -1.000000 -1.000000 1.000000
+v -1.000000 -1.000000 -1.000000
+v 1.000000 1.000000 -1.000000
+v 0.999999 1.000000 1.000001
+v -1.000000 1.000000 1.000000
+v -1.000000 1.000000 -1.000000
+vt 0.748573 0.750412
+vt 0.749279 0.501284
+vt 0.999110 0.501077
+vt 0.999455 0.750380
+vt 0.250471 0.500702
+vt 0.249682 0.749677
+vt 0.001085 0.750380
+vt 0.001517 0.499994
+vt 0.499422 0.500239
+vt 0.500149 0.750166
+vt 0.748355 0.998230
+vt 0.500193 0.998728
+vt 0.498993 0.250415
+vt 0.748953 0.250920
+vn 0.000000 0.000000 -1.000000
+vn -1.000000 -0.000000 -0.000000
+vn -0.000000 -0.000000 1.000000
+vn -0.000001 0.000000 1.000000
+vn 1.000000 -0.000000 0.000000
+vn 1.000000 0.000000 0.000001
+vn 0.000000 1.000000 -0.000000
+vn -0.000000 -1.000000 0.000000
+usemtl Material_ray.png
+s off
+f 5/1/1 1/2/1 4/3/1
+f 5/1/1 4/3/1 8/4/1
+f 3/5/2 7/6/2 8/7/2
+f 3/5/2 8/7/2 4/8/2
+f 2/9/3 6/10/3 3/5/3
+f 6/10/4 7/6/4 3/5/4
+f 1/2/5 5/1/5 2/9/5
+f 5/1/6 6/10/6 2/9/6
+f 5/1/7 8/11/7 6/10/7
+f 8/11/7 7/12/7 6/10/7
+f 1/2/8 2/9/8 3/13/8
+f 1/2/8 3/13/8 4/14/8
+```
+
+So :
+
+* `#` is a comment, just like // in C++
+* usemtl and mtllib describe the look of the model. We won't use this in this tutorial.
+* v is a vertex
+* vt is the texture coordinate of one vertex
+* vn is the normal of one vertex
+* f is a face
+
+v, vt and vn are simple to understand. f is more tricky. So, for f 8/11/7 7/12/7 6/10/7 :
+
+* 8/11/7 describes the first vertex of the triangle
+* 7/12/7 describes the second vertex of the triangle
+* 6/10/7 describes the third vertex of the triangle (duh)
+* For the first vertex, 8 says which vertex to use. So in this case, -1.000000 1.000000 -1.000000 (index start to 1, not to 0 like in C++)
+* 11 says which texture coordinate to use. So in this case, 0.748355 0.998230
+* 7 says which normal to use. So in this case, 0.000000 1.000000 -0.000000
+
+These numbers are called indices. It's handy because if several vertices share the same position, you just have to write one "v" in the file, and use it several times. This saves memory.
+
+The bad news is that OpenGL can't be told to use one index for the position, another for the texture, and another for the normal. So the approach I took for this tutorial is to make a standard, non-indexed mesh, and deal with indexing later, in Tutorial 9, which will explain how to work around this.
+
+## Creating an OBJ file in Blender
+
+Since our toy loader will be severely limited, we have to be extra careful to set the right options when exporting the file. Here's how it should look in Blender :
+
+
+
+
+## Reading the file
+
+Ok, down with the actual code. We need some temporary variables in which we will store the contents of the .obj :
+
+``` cpp
+std::vector< unsigned int > vertexIndices, uvIndices, normalIndices;
+std::vector< glm::vec3 > temp_vertices;
+std::vector< glm::vec2 > temp_uvs;
+std::vector< glm::vec3 > temp_normals;
+```
+
+Since Tutorial 5 : A Textured Cube, you know how to open a file :
+
+``` cpp
+FILE * file = fopen(path, "r");
+if( file == NULL ){
+ printf("Impossible to open the file !\n");
+ return false;
+}
+```
+
+Let's read this file until the end :
+
+``` cpp
+while( 1 ){
+
+ char lineHeader[128];
+ // read the first word of the line
+ int res = fscanf(file, "%s", lineHeader);
+ if (res == EOF)
+ break; // EOF = End Of File. Quit the loop.
+
+ // else : parse lineHeader
+```
+
+(notice that we assume that the first word of a line won't be longer than 128, which is a very silly assumption. But for a toy parser, it's all right)
+
+Let's deal with the vertices first :
+
+``` cpp
+if ( strcmp( lineHeader, "v" ) == 0 ){
+ glm::vec3 vertex;
+ fscanf(file, "%f %f %f\n", &vertex.x, &vertex.y, &vertex.z );
+ temp_vertices.push_back(vertex);
+```
+
+i.e : If the first word of the line is "v", then the rest has to be 3 floats, so create a glm::vec3 out of them, and add it to the vector.
+
+``` cpp
+}else if ( strcmp( lineHeader, "vt" ) == 0 ){
+ glm::vec2 uv;
+ fscanf(file, "%f %f\n", &uv.x, &uv.y );
+ temp_uvs.push_back(uv);
+```
+
+i.e if it's not a "v" but a "vt", then the rest has to be 2 floats, so create a glm::vec2 and add it to the vector.
+
+same thing for the normals :
+
+``` cpp
+}else if ( strcmp( lineHeader, "vn" ) == 0 ){
+ glm::vec3 normal;
+ fscanf(file, "%f %f %f\n", &normal.x, &normal.y, &normal.z );
+ temp_normals.push_back(normal);
+```
+
+And now the "f", which is more difficult :
+
+``` cpp
+}else if ( strcmp( lineHeader, "f" ) == 0 ){
+ std::string vertex1, vertex2, vertex3;
+ unsigned int vertexIndex[3], uvIndex[3], normalIndex[3];
+ int matches = fscanf(file, "%d/%d/%d %d/%d/%d %d/%d/%d\n", &vertexIndex[0], &uvIndex[0], &normalIndex[0], &vertexIndex[1], &uvIndex[1], &normalIndex[1], &vertexIndex[2], &uvIndex[2], &normalIndex[2] );
+ if (matches != 9){
+ printf("File can't be read by our simple parser : ( Try exporting with other options\n");
+ return false;
+ }
+ vertexIndices.push_back(vertexIndex[0]);
+ vertexIndices.push_back(vertexIndex[1]);
+ vertexIndices.push_back(vertexIndex[2]);
+ uvIndices .push_back(uvIndex[0]);
+ uvIndices .push_back(uvIndex[1]);
+ uvIndices .push_back(uvIndex[2]);
+ normalIndices.push_back(normalIndex[0]);
+ normalIndices.push_back(normalIndex[1]);
+ normalIndices.push_back(normalIndex[2]);
+```
+
+This code is in fact very similar to the previous one, except that there is more data to read.
+
+## Processing the data
+
+So what we did there was simply to change the "shape" of the data. We had a string, we now have a set of std::vectors. But it's not enough, we have to put this into a form that OpenGL likes. Namely, removing the indexes and have plain glm::vec3 instead. This operation is called indexing.
+
+We go through each vertex ( each v/vt/vn ) of each triangle ( each line with a "f" ) :
+
+``` cpp
+ // For each vertex of each triangle
+ for( unsigned int i=0; i
+
+
diff --git a/pt/intermediate-tutorials/billboards-particles/billboards/index.markdown b/pt/intermediate-tutorials/billboards-particles/billboards/index.markdown
new file mode 100644
index 000000000..78fbca6c6
--- /dev/null
+++ b/pt/intermediate-tutorials/billboards-particles/billboards/index.markdown
@@ -0,0 +1,123 @@
+---
+layout: tutorial
+status: publish
+published: true
+title: Billboards
+date: '2013-10-15 17:15:15 +0200'
+date_gmt: '2013-10-15 17:15:15 +0200'
+categories: []
+order: 584
+tags: []
+---
+
+* TOC
+{:toc}
+
+Billboards are 2D elements incrusted in a 3D world. Not a 2D menu on top of everything else; not a 3D plane around which you can turn; but something in-between, like health bars in many games.
+
+What's different with billboards is that they are positionned at a specific location, but their orientation is automatically computed so that it always faces the camera.
+
+# Solution #1 : The 2D way
+
+This one is supra-easy.
+
+Just compute where your point is on screen, and display a 2D text (see Tutorial 11) at this position.
+
+``` cpp
+// Everything here is explained in Tutorial 3 ! There's nothing new.
+glm::vec4 BillboardPos_worldspace(x,y,z, 1.0f);
+glm::vec4 BillboardPos_screenspace = ProjectionMatrix * ViewMatrix * BillboardPos_worldspace;
+BillboardPos_screenspace /= BillboardPos_screenspace.w;
+
+if (BillboardPos_screenspace.z < 0.0f){
+ // Object is behind the camera, don't display it.
+}
+```
+
+Ta-dah !
+
+On the plus side, this method is really easy, and the billboard will have the same size regardless of its distance to the camera. But 2D text is always displayed on top of everything else, and this can/will mess up the rendering and show above other objects.
+
+# Solution #2 : The 3D way
+
+This one is usually better and not much more complicated.
+
+The goal is to keep the mesh aligned with the camera, even when the camera moves :
+
+
+
+
+You can view this problem as generating an appropriate Model matrix, even though it's is much simpler than that.
+
+The idea is that each corner of the billboard is at the center position, displaced by the camera's up and right vectors :
+
+
+
+Of course, we only know the billboard's center position in world space, so we also need the camera's up/right vectors in world space.
+
+In camera space, the camera's up vector is (0,1,0). To get it in world space, just multiply this by the matrix that goes from Camera Space to World Space, which is, of course, the inverse of the View matrix.
+
+An easier way to express the same math is :
+
+```
+CameraRight_worldspace = {ViewMatrix[0][0], ViewMatrix[1][0], ViewMatrix[2][0]}
+CameraUp_worldspace = {ViewMatrix[0][1], ViewMatrix[1][1], ViewMatrix[2][1]}
+```
+
+Once we have this, it's very easy to compute the final vertex' position :
+
+``` glsl
+vec3 vertexPosition_worldspace =
+ particleCenter_wordspace
+ + CameraRight_worldspace * squareVertices.x * BillboardSize.x
+ + CameraUp_worldspace * squareVertices.y * BillboardSize.y;
+```
+{: .highlightglslvs }
+
+* particleCenter_worldspace is, as its name suggests, the billboard's center position. It is specified with an uniform vec3.
+* squareVertices is the original mesh. squareVertices.x is -0.5 for the left vertices, which are thus moved towars the left of the camera (because of the *CameraRight_worldspace)
+* BillboardSize is the size, in world units, of the billboard, sent as another uniform.
+
+News
+ +-
+ {% for post in site.posts %}
+
- + {{ post.date | date: "%b %-d, %Y" }} + {{ post.title }} + + {% endfor %} +
subscribe via RSS
+ +And presto, here's the result. Wasn't this easy ?
+
+
+For the record, here's how squareVertices is made :
+
+``` cpp
+// The VBO containing the 4 vertices of the particles.
+ static const GLfloat g_vertex_buffer_data[] = {
+ -0.5f, -0.5f, 0.0f,
+ 0.5f, -0.5f, 0.0f,
+ -0.5f, 0.5f, 0.0f,
+ 0.5f, 0.5f, 0.0f,
+ };
+```
+
+# Solution #3 : The fixed-size 3D way
+
+As you can see above, the size of the billboard changes with respect to the camera's distance. This is the expected result in some cases, but in others, such as health bars, you probably want a fixed-size instead.
+
+Since the displacement between the center and a corner must be fixed in screen-space, that's exactly what we're going to do : compute the center's position in screen space, and offset it.
+
+``` cpp
+vertexPosition_worldspace = particleCenter_wordspace;
+// Get the screen-space position of the particle's center
+gl_Position = VP * vec4(vertexPosition_worldspace, 1.0f);
+// Here we have to do the perspective division ourselves.
+gl_Position /= gl_Position.w;
+
+// Move the vertex in directly screen space. No need for CameraUp/Right_worlspace here.
+gl_Position.xy += squareVertices.xy * vec2(0.2, 0.05);
+```
+
+Remember that at this stage of the rendering pipeline, you're in Normalized Device Coordinates, so between -1 and 1 on both axes : it's not in pixels.
+
+If you want a size in pixels, easy : just use (ScreenSizeInPixels / BillboardSizeInPixels) instead of BillboardSizeInScreenPercentage.
+
+
+
+# Solution #4 : Vertical rotation only
+
+Some systems model faraway trees and lamps as billboards. But you really, really don't want your tree to be bent : it MUST be vertical. So you need an hybrid system that rotates only around one axis.
+
+Well, this one is left as an exercise to the reader !
diff --git a/pt/intermediate-tutorials/billboards-particles/index.markdown b/pt/intermediate-tutorials/billboards-particles/index.markdown
new file mode 100644
index 000000000..38a42fc98
--- /dev/null
+++ b/pt/intermediate-tutorials/billboards-particles/index.markdown
@@ -0,0 +1,15 @@
+---
+layout: page
+status: publish
+published: true
+title: 'Tutorial 18 : Billboards & Particles'
+date: '2013-09-07 11:17:18 +0200'
+date_gmt: '2013-09-07 11:17:18 +0200'
+categories: [tuto]
+order: 580
+tags: []
+---
+This tutorials is divided in two parts:
+
+- [Part 1: Billboards](./billboards)
+- [Part 2: Particles and object instancing](./particles-instancing)
diff --git a/pt/intermediate-tutorials/billboards-particles/particles-instancing/index.markdown b/pt/intermediate-tutorials/billboards-particles/particles-instancing/index.markdown
new file mode 100644
index 000000000..9d269d795
--- /dev/null
+++ b/pt/intermediate-tutorials/billboards-particles/particles-instancing/index.markdown
@@ -0,0 +1,412 @@
+---
+layout: tutorial
+status: publish
+published: true
+title: Particles / Instancing
+date: '2013-10-19 10:52:04 +0200'
+date_gmt: '2013-10-19 10:52:04 +0200'
+categories: []
+order: 588
+tags: []
+---
+
+* TOC
+{:toc}
+
+Particles are very similar to 3D billboards. There are two major differences, though :
+
+* there is usually a LOT of them
+* they move
+* the appear and die.
+* they are semi-transparent
+
+Both of these difference come with problems. This tutorial will present ONE way to solve them; there are many other possibilities.
+
+# Particles, lots of them !
+
+The first idea to draw many particles would be to use the previous tutorial's code, and call glDrawArrays once for each particle. This is a very bad idea, because this means that all your shiny GTX' 512+ multiprocessors will all be dedicated to draw ONE quad (obviously, only one will be used, so that's 99% efficiency loss). Then you will draw the second billboard, and it will be the same.
+
+Clearly, we need a way to draw all particles at the same time.
+
+There are many ways to do this; here are three of them :
+
+* Generate a single VBO with all the particles in them. Easy, effective, works on all platforms.
+* Use geometry shaders. Not in the scope of this tutorial, mostly because 50% of the computers don't support this.
+* Use instancing. Not available on ALL computers, but a vast majority of them.
+
+In this tutorial, we'll use the 3rd option, because it is a nice balance between performance and availability, and on top of that, it's easy to add support for the first method once this one works.
+
+## Instancing
+
+"Instancing" means that we have a base mesh (in our case, a simple quad of 2 triangles), but many instances of this quad.
+
+Technically, it's done via several buffers :
+
+* Some of them describe the base mesh
+* Some of them describe the particularities of each instance of the base mesh.
+
+You have many, many options on what to put in each buffer. In our simple case, we have :
+
+* One buffer for the vertices of the mesh. No index buffer, so it's 6 vec3, which make 2 triangles, which make 1 quad.
+* One buffer for the particles' centers.
+* One buffer for the particles' colors.
+
+These are very standard buffers. They are created this way :
+
+``` cpp
+// The VBO containing the 4 vertices of the particles.
+// Thanks to instancing, they will be shared by all particles.
+static const GLfloat g_vertex_buffer_data[] = {
+ -0.5f, -0.5f, 0.0f,
+ 0.5f, -0.5f, 0.0f,
+ -0.5f, 0.5f, 0.0f,
+ 0.5f, 0.5f, 0.0f,
+};
+GLuint billboard_vertex_buffer;
+glGenBuffers(1, &billboard_vertex_buffer);
+glBindBuffer(GL_ARRAY_BUFFER, billboard_vertex_buffer);
+glBufferData(GL_ARRAY_BUFFER, sizeof(g_vertex_buffer_data), g_vertex_buffer_data, GL_STATIC_DRAW);
+
+// The VBO containing the positions and sizes of the particles
+GLuint particles_position_buffer;
+glGenBuffers(1, &particles_position_buffer);
+glBindBuffer(GL_ARRAY_BUFFER, particles_position_buffer);
+// Initialize with empty (NULL) buffer : it will be updated later, each frame.
+glBufferData(GL_ARRAY_BUFFER, MaxParticles * 4 * sizeof(GLfloat), NULL, GL_STREAM_DRAW);
+
+// The VBO containing the colors of the particles
+GLuint particles_color_buffer;
+glGenBuffers(1, &particles_color_buffer);
+glBindBuffer(GL_ARRAY_BUFFER, particles_color_buffer);
+// Initialize with empty (NULL) buffer : it will be updated later, each frame.
+glBufferData(GL_ARRAY_BUFFER, MaxParticles * 4 * sizeof(GLubyte), NULL, GL_STREAM_DRAW);
+```
+
+, which is as usual. They are updated this way :
+
+
+
+``` cpp
+// Update the buffers that OpenGL uses for rendering.
+// There are much more sophisticated means to stream data from the CPU to the GPU,
+// but this is outside the scope of this tutorial.
+// http://www.opengl.org/wiki/Buffer_Object_Streaming
+
+glBindBuffer(GL_ARRAY_BUFFER, particles_position_buffer);
+glBufferData(GL_ARRAY_BUFFER, MaxParticles * 4 * sizeof(GLfloat), NULL, GL_STREAM_DRAW); // Buffer orphaning, a common way to improve streaming perf. See above link for details.
+glBufferSubData(GL_ARRAY_BUFFER, 0, ParticlesCount * sizeof(GLfloat) * 4, g_particule_position_size_data);
+
+glBindBuffer(GL_ARRAY_BUFFER, particles_color_buffer);
+glBufferData(GL_ARRAY_BUFFER, MaxParticles * 4 * sizeof(GLubyte), NULL, GL_STREAM_DRAW); // Buffer orphaning, a common way to improve streaming perf. See above link for details.
+glBufferSubData(GL_ARRAY_BUFFER, 0, ParticlesCount * sizeof(GLubyte) * 4, g_particule_color_data);
+```
+
+, which is as usual. Before render, they are bound this way :
+
+
+
+``` cpp
+// 1rst attribute buffer : vertices
+glEnableVertexAttribArray(0);
+glBindBuffer(GL_ARRAY_BUFFER, billboard_vertex_buffer);
+glVertexAttribPointer(
+ 0, // attribute. No particular reason for 0, but must match the layout in the shader.
+ 3, // size
+ GL_FLOAT, // type
+ GL_FALSE, // normalized?
+ 0, // stride
+ (void*)0 // array buffer offset
+);
+
+// 2nd attribute buffer : positions of particles' centers
+glEnableVertexAttribArray(1);
+glBindBuffer(GL_ARRAY_BUFFER, particles_position_buffer);
+glVertexAttribPointer(
+ 1, // attribute. No particular reason for 1, but must match the layout in the shader.
+ 4, // size : x + y + z + size => 4
+ GL_FLOAT, // type
+ GL_FALSE, // normalized?
+ 0, // stride
+ (void*)0 // array buffer offset
+);
+
+// 3rd attribute buffer : particles' colors
+glEnableVertexAttribArray(2);
+glBindBuffer(GL_ARRAY_BUFFER, particles_color_buffer);
+glVertexAttribPointer(
+ 2, // attribute. No particular reason for 1, but must match the layout in the shader.
+ 4, // size : r + g + b + a => 4
+ GL_UNSIGNED_BYTE, // type
+ GL_TRUE, // normalized? *** YES, this means that the unsigned char[4] will be accessible with a vec4 (floats) in the shader ***
+ 0, // stride
+ (void*)0 // array buffer offset
+);
+```
+
+, which is as usual. The difference comes when rendering. Instead of using glDrawArrays (or glDrawElements if your base mesh has an index buffer), you use glDrawArrraysInstanced / glDrawElementsInstanced, which is equivalent to calling glDrawArrays N times (N is the last parameter, in our case ParticlesCount) :
+
+``` cpp
+glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, ParticlesCount);
+```
+
+Bue something is missing here. We didn't tell OpenGL which buffer was for the base mesh, and which were for the different instances. This is done with glVertexAttribDivisor. Here's the full commented code :
+
+``` cpp
+// These functions are specific to glDrawArrays*Instanced*.
+// The first parameter is the attribute buffer we're talking about.
+// The second parameter is the "rate at which generic vertex attributes advance when rendering multiple instances"
+// http://www.opengl.org/sdk/docs/man/xhtml/glVertexAttribDivisor.xml
+glVertexAttribDivisor(0, 0); // particles vertices : always reuse the same 4 vertices -> 0
+glVertexAttribDivisor(1, 1); // positions : one per quad (its center) -> 1
+glVertexAttribDivisor(2, 1); // color : one per quad -> 1
+
+// Draw the particules !
+// This draws many times a small triangle_strip (which looks like a quad).
+// This is equivalent to :
+// for(i in ParticlesCount) : glDrawArrays(GL_TRIANGLE_STRIP, 0, 4),
+// but faster.
+glDrawArraysInstanced(GL_TRIANGLE_STRIP, 0, 4, ParticlesCount);
+```
+
+As you can see, instancing is very versatile, because you can pass any integer as the AttribDivisor. For instance, with glVertexAttribDivisor(2, 10), each 10 subsequent instances will have the same color.
+
+## What's the point ?
+
+The point is that now, we only have to update a small buffer each frame (the center of the particles) and not a huge mesh. This is a x4 bandwidth gain !
+
+
+
+# Life and death
+
+On the contrary to most other objects in the scene, particles die and born at a very high rate. We need a decently fast way to get new particles and to discard them, something better than "new Particle()".
+
+## Creating new particles
+
+For this, we will have a big particles container :
+
+``` cpp
+// CPU representation of a particle
+struct Particle{
+ glm::vec3 pos, speed;
+ unsigned char r,g,b,a; // Color
+ float size, angle, weight;
+ float life; // Remaining life of the particle. if < 0 : dead and unused.
+
+};
+
+const int MaxParticles = 100000;
+Particle ParticlesContainer[MaxParticles];
+```
+
+Now, we need a way to create new ones. This function searches linearly in ParticlesContainer, which should be an horrible idea, except that it starts at the last known place, so this function usually returns immediately :
+
+``` cpp
+int LastUsedParticle = 0;
+
+// Finds a Particle in ParticlesContainer which isn't used yet.
+// (i.e. life < 0);
+int FindUnusedParticle(){
+
+ for(int i=LastUsedParticle; iINCLUDEPATH += \
+```
+
+### Link with a library
+
+Right clic on project -> Add library
+
+* If you're on Linux and you installed the library with apt-get or similar, chances are that the library registered itself in the system. You can select "System package" and enter the name of the library ( ex : *libglfw* or *glew* )
+
+
+
+
+* If not, use "System Library". Browse to where you compiled it.
+
+
+### Build, Run & Debug
+
+Building : Ctrl-B, or the hammer on the bottom left corner.
+
+Running : the green arrow. You can set the program's arguments and working directory in Projects -> Run Settings
+
+Debugging :
+
+* Setting a breakpoint : Click on the left of the line number. A red dot will appear.
+* F10 : execute current line
+* F11 : execute current line, but step into the functions this line is calling ("step into")
+* Shift-F11 : run until the end of the function ("step out")
+
+You also have plenty of debugging windows : watched variables, callstack, threads, ...
+
+## XCode
+
+Work in progress...
+
+### Creating a new project
+
+
+### Adding a source file in a project
+
+
+### Adding include directories
+
+
+### Link with a library
+
+
+### Build, Run & Debug
+
+
+## CMake
+
+CMake will create projects for almost any software building tool : Visual, QtCreator, XCode, make, Code::Blocks, Eclipse, etc, on any OS. This frees you from maintaining many project files.
+
+### Creating a new project
+
+Create a CMakeLists.txt file and write the following inside (adapt if needed) :
+
+```
+cmake_minimum_required (VERSION 2.6)
+project (your_project_name)
+
+find_package(OpenGL REQUIRED)
+
+add_executable(your_exe_name
+ tutorial04_colored_cube/tutorial04.cpp
+ common/shader.cpp
+ common/shader.hpp
+)
+```
+
+Launch the CMake GUI, browse to your .txt file, and select your build folder. Click Configure, then Generate. Your solution will be created in the build folder.
+
+### Adding a source file in a project
+
+Simply add a line in the add_executable command.
+
+### Adding include directories
+
+
+```
+include_directories(
+ external/AntTweakBar-1.15/include/
+ external/glfw-2.7.2/include/
+ external/glm-0.9.1/
+ external/glew-1.5.8/include/
+ .
+)
+```
+
+### Link with a library
+
+```
+set(ALL_LIBS
+ ${OPENGL_LIBRARY}
+ GLFW_272
+ GLEW_158
+ ANTTWEAKBAR_151_OGLCORE_GLFW
+)
+
+target_link_libraries(tutorial01_first_window
+ ${ALL_LIBS}
+)
+```
+
+### Build, Run & Debug
+
+CMake doesn't do that. Use your favourite IDE.
+
+## make
+
+Please, just don't use that.
+
+## gcc
+
+It might be worth compiling a small project "by hand" in order to gain a better comprehension of the workflow. Just don't do this on a real project...
+
+Note that you can also do that on Windows using mingw.
+
+Compile each .cpp file separately :
+
+``` bash
+g++ -c main.cpp
+g++ -c tools.cpp
+```
+
+
+As said above, you will have a main.o and a tools.o files. Link them :
+
+``` bash
+g++ main.o tools.o
+```
+
+a *a.out* file appeared; It's your executable, run it :
+
+``` bash
+./a.out
+```
+
+That's it !
+
+# Building your own C application
+
+Armed with this knowledge, we can start building our own OpenGL application.
+
+* Download the dependencies : Here we use GLFW, GLEW and GLM, but depending on your project, you might need something different. Save same preferably in a subdirectory of your project (for instance : external/)
+* They should be pre-compiled for your platform. GLM doesn't have to be compiled, though.
+* Create a new project with the IDE of your choice
+* Add a new .cpp file in the project
+* Copy and paste, for instance, the following code (this is actually playground.cpp) :
+
+``` cpp
+#include There's one big situation where you might want to use a very recent version, say 4.2 : you're a graduate student doing high-end research, you really need a recent feature, and you don't care about compatibility because your software will never be ran outside your lab. In this case, don't waste time and go straight to the highest OpenGL version your hardware supports.
+
+
+# Where do I download OpenGL 3 ?
+
+You don't.
+
+On Windows, for instance, you only have opengl32.dll, which is only OpenGL 1.1. BUT there is this function, wglGetProcAddress(), which makes is possible to get functions that are not implemented directly in opengl32.dll, but which are available in the driver.
+
+GLEW calls wglGetProcAdress on all needed symbols, and make them available to you. (you can do it yourself but it's horribly boring). It also declares new constants which did not exist 10 years ago, like, for instance, GL_VERTEX_ATTRIB_ARRAY_DIVISOR_ARB.
+
+So, just make sure your GPU driver supports the needed version, use GLEW, and you're good to go.
+
+
+
+# Why do you create a VAO in each tutorial, but you never use it ?
+
+
+Wrong. It's bound, so in fact, it's used during the whole execution.
+
+VAOs are wrappers around VBOs. They remember which buffer is bound to which attribute and various other things. This reduces the number of OpenGL calls before glDrawArrays/Elements(). Since OpenGL 3 Core, they are compulsory, but you may use only one and modify it permanently (which is what is done in the tutorial).
+
+VAOs may be confusing for this beginner's tutorial, and there is no equivalent in OpenGL 2 (which I recommend for production, see related FAQ), and the performance benefits are not clear. If you're interested in VAOs, please have a look at OpenGL's wiki. It *may* slightly simplify your application and *may* increase the performance a tiny bit, but not always.
+
+
+
+# I've got error "Unable to start program ALL_BUILD"
+
+ALL_BUILD is just a helper project generated by CMake; it's not a real program.
+
+As stated in Tutorial 1, you have to select the project you want to run by right-clicking on a project (from inside Visual) and select "Set up as startup project", like this :
+
+
+
+
+
+
+# I've got a message about the working directory, and the program crashes.
+
+You have to start the program from tutorial01_first_window/, tutorial02_red_triangle/, etc. If you start the program from your IDE, you have to configure it from him to do so.
+
+Please read Tutorial 1 for details.
diff --git a/pt/miscellaneous/index.markdown b/pt/miscellaneous/index.markdown
new file mode 100644
index 000000000..053d2e154
--- /dev/null
+++ b/pt/miscellaneous/index.markdown
@@ -0,0 +1,25 @@
+---
+layout: page
+type: section
+status: publish
+published: true
+title: Miscellaneous
+date: '2011-05-08 08:24:33 +0200'
+date_gmt: '2011-05-08 08:24:33 +0200'
+categories: []
+tags: []
+---
+
+{% assign sorted_pages = site.pages | sort:"order" %}
+{% for p in sorted_pages %}
+ {% assign splt = p.url | split: page.url %}
+ {% if splt.size == 2 and splt[0] == '' %}
+ {% assign slash = splt[1] | split: '/' %}
+{% if slash.size == 1 %}
+- {{p.title}}
+{% else %}
+ - {{p.title}}
+{% endif %}
+ {% endif %}
+{% endfor %}
+
diff --git a/pt/miscellaneous/math-cheatsheet/index.markdown b/pt/miscellaneous/math-cheatsheet/index.markdown
new file mode 100644
index 000000000..b586859a2
--- /dev/null
+++ b/pt/miscellaneous/math-cheatsheet/index.markdown
@@ -0,0 +1,124 @@
+---
+layout: page
+status: publish
+published: true
+title: Math Cheatsheet
+date: '2011-05-11 20:04:48 +0200'
+date_gmt: '2011-05-11 20:04:48 +0200'
+categories: []
+order: 20
+tags: []
+print: true
+---
+
+# Trigonometry
+
+
+## Pi
+
+const float pi = 3.14159265f; // but an infinity of digits in reality
+
+## Cosinus & Sinus
+
+
+*(From http://commons.wikimedia.org/wiki/User:Geek3 , under GNU Free Documentation License )*
+
+## Unit circle
+
+
+
+*( Modified from http://en.wikipedia.org/wiki/User:Gustavb under Crative Commons 3.0 )*t is an angle in radians.
+
+0 radians = 0 degrees
+
+180 degrees = Pi radians
+
+360 degrees ( full circle ) = 2*Pi radians
+
+90 degrees = Pi/2 radians
+
+# Vectors
+
+ALWAYS know in which coordinates your vector is. See section 3 for details.
+
+## Homogeneous coordinates
+
+A 3D vector is (x,y,z), but a homogeneous 3D vector is (x,y,z,w).
+
+* w=0 : it's a direction
+* w=1 : it's a position
+* else : it may still be correct, but you'd better know what you're doing.
+
+You can only multiply a 4x4 matrix with a homogeneous vector.
+
+## Length
+
+Just like cartesian distance : sqrt( x² + y² + z² ). w doesn't count.
+
+## Cross product
+
+
+
+*( Modified from http://en.wikipedia.org/wiki/User:Acdx , former image under Creative Commons 3.0 )*The X is the notation for the cross product. length( a x b ) == length(a) * length(b) * sin(θ), so you may want to normalize() the result.
+
+## Dot product
+
+
+##
+
+
+*( from http://en.wikipedia.org/wiki/File:Dot_Product.svg )*A.B = length(A)*cos(Theta) , but most likely computed as A.x*B.x +A.y*B.y +A.z*B.z
+
+## Addition and substraction
+
+compontent-wise :
+
+``` cpp
+res.x = A.x + B.x
+res.y = A.y + B.y
+...
+```
+
+## Multiplication
+
+compontent-wise :
+
+``` cpp
+res.x = A.x * B.x
+res.y = A.y * B.y
+...
+```
+
+## Normalization
+
+Divide the vector by its length :
+
+``` cpp
+normalizedVector = vec * ( 1.0f / vec.length() )
+```
+
+# Matrices
+
+
+## Matrix-Matrix multiplication
+
+example for a translation matrix :
+
+
+
+
+
+
+## Matrix-Vector multiplication
+
+
+
+
+# Usual Transformations
+
+
+
+
+... but in your shaders, you can also represent your vectors in tangent space. And in image-space when you do post-effects.
+
+res.x = A.x + B.x
diff --git a/pt/miscellaneous/useful-tools-links/index.markdown b/pt/miscellaneous/useful-tools-links/index.markdown
new file mode 100644
index 000000000..59da77ba2
--- /dev/null
+++ b/pt/miscellaneous/useful-tools-links/index.markdown
@@ -0,0 +1,112 @@
+---
+layout: page
+status: publish
+published: true
+title: Useful Tools & Links
+date: '2011-05-11 20:31:21 +0200'
+date_gmt: '2011-05-11 20:31:21 +0200'
+categories: []
+order: 30
+tags: []
+---
+
+# Documentation
+
+
+
+## OpenGL references
+
+
+* [OpenGL Quick Reference PDF](http://www.opengl.org/sdk/docs/reference_card/opengl45-reference-card.pdf)
+* [OpenGL 4.5 Reference Pages](http://www.opengl.org/sdk/docs/man4/)
+* [OpenGL 4.5 (Core Profile) Specification](https://www.khronos.org/registry/OpenGL/specs/gl/glspec45.core.pdf). A heavy read.
+* [GLSL Specifications](https://www.khronos.org/registry/OpenGL/specs/gl/GLSLangSpec.4.50.pdf)
+* [List of all extensions, and up-to-date specs](http://www.opengl.org/registry/) If your GPU is recent enough, most of them will be available through GLEW.
+
+
+## Other tutorials
+
+
+* [ogldev](http://ogldev.atspace.co.uk/index.html) A nice and thorough tutorial
+* [NeHe ](http://nehe.gamedev.net/)Extensive OpenGL 1.1 programming tutorials and resources. Mostly deprecated now, but there are still a few intersting things.
+
+
+## Books
+
+
+* [Real-time Rendering 3](http://www.realtimerendering.com/). Fantastic for learning the high-level concepts.
+* [GPU Pro book series](http://gpupro.blogspot.fr/). For detailed explanation of specific algorithms.
+
+## Others
+
+
+* [A trip trough the graphic pipeline](http://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/) : In-depth information about how the drivers & GPUs actually work. Fantastic source of information. Highly recommended.
+* [Unity stats](https://hwstats.unity3d.com/)
+* [Extensions stats](http://gpuinfo.org/)
+
+
+# Debugging tools
+
+
+* [NVidia Parallel NSight](http://developer.nvidia.com/nvidia-parallel-nsight) A wonderful tool which gives access to extremely precise performance numbers. Highly recommended. Visual Studio + NVidia only. The one I use most.
+* [GLIntercept ](http://glintercept.nutty.org/) Generates a webpage with the list of OpenGL commands issued. Displays shader code, content of images, content of framebuffers, etc. A bit hard to master, but very precise and useful.
+* [gdebugger](http://www.gremedy.com/) A profiler
+
+
+# Libraries
+
+
+## Windowing & misc
+
+* [GLFW ](http://www.glfw.org/), the one we use
+* GLUT, the oldest. Not maintained, horrible license. Not recommended.
+* [FreeGlut](http://freeglut.sourceforge.net/), same API, but Open Source.
+* [SDL](http://www.libsdl.org/) I think this one is weird but some people like it.
+* [SFML](http://www.sfml-dev.org/index-fr.php). Includes a coffee machine, a washing machine, and a cellular.
+
+## Extension loading
+
+Beware, most extensions loading library don't work well with OpenGL 3+ Core. Actually, GLEW is the only one I managed to make work, with changes in the source code.
+
+If unsure, simply use the GLEW version included in the source code.
+
+* [GLEW ](http://glew.sourceforge.net/), the one we use
+* [GLEE ](http://elf-stone.com/glee.php)I hear it's not bad either
+* [gl3w ](https://github.com/skaslev/gl3w/wiki). A Python scripts that generates a C++ file.
+
+## Math library
+
+* [GLM](http://glm.g-truc.net/), the one we use. Very complete. Directly OpenGL and CUDA compatible.
+* [Bullet's Vectormath](http://bulletphysics.com/Bullet/BulletFull/) Never used it but it seems to be SIMD'ed ( = faster, even if you seldom make big computations on the CPU side )
+* [Boost.ublas ](http://www.boost.org/). Heavyweight. I don't recommend it for OpenGL.
+* [MathFu](https://google.github.io/mathfu/) Google's tak on math libraries, SIMD optimised.
+
+## Image loading
+
+* [stbimage](http://nothings.org/) A single .c file to include to your project, and you can load jpeg, bmp and png files !!!
+* [SOIL ](http://www.lonesock.net/soil.html)I recommend this one. Based on stbimage, provides handy functions for use with OpenGL, and a DDS loader.
+* [DevIL](http://openil.sourceforge.net/) An all-in-one image loading library
+* [FreeImage](http://freeimage.sourceforge.net/) ... and another one
+* [Boost.GIL](http://www.boost.org/) Big and bulky, doesn't do jpg.
+* libjpg The usual library for .jpg loading. Quite hard to use, but plenty of examples on the net.
+* libpng Same thing here.
+
+## Static objects loading
+
+* [ASSIMP ](http://assimp.sourceforge.net/)
+
+## Articulated objects loading & stuff
+
+* Any Quake III or Quake IV loader around
+* [Cal3D](http://gna.org/projects/cal3d/)
+
+
+## Physics
+
+
+* [Bullet](http://bulletphysics.org/wordpress/) Open source, used by many games and even films
+* [Newton](http://newtondynamics.com/forum/newton.php) Free, very good too.
+* [ODE](http://www.ode.org/). Old and unstable. Avoid.
+* PhysX
+* Havok (expensive)
+