LearnOpenGL

Instancing.html (25682B)

---

     <div id="content">
     <h1 id="content-title">Instancing</h1>
 <h1 id="content-url" style='display:none;'>Advanced-OpenGL/Instancing</h1>
 <p>
   Say you have a scene where you're drawing a lot of models where most of these models contain the same set of vertex data, but with different world transformations. Think of a scene filled with grass leaves: each grass leave is a small model that consists of only a few triangles. You'll probably want to draw quite a few of them and your scene may end up with thousands or maybe tens of thousands of grass leaves that you need to render each frame. Because each leaf is only a few triangles, the leaf is rendered almost instantly. However, the thousands of render calls you'll have to make will drastically reduce performance.
 </p>
 
 <p>
   If we were to actually render such a large amount of objects it will look a bit like this in code:
 </p>
 
 <pre><code>
 for(unsigned int i = 0; i &lt; amount_of_models_to_draw; i++)
 {
     DoSomePreparations(); // bind VAO, bind textures, set uniforms etc.
     <function id='1'>glDrawArrays</function>(GL_TRIANGLES, 0, amount_of_vertices);
 }
 </code></pre>
 
 <p>
   When drawing many <def>instances</def> of your model like this you'll quickly reach a performance bottleneck because of the many draw calls. Compared to rendering the actual vertices, telling the GPU to render your vertex data with functions like <fun><function id='1'>glDrawArrays</function></fun> or <fun><function id='2'>glDrawElements</function></fun> eats up quite some performance since OpenGL must make necessary preparations before it can draw your vertex data (like telling the GPU which buffer to read data from, where to find vertex attributes and all this over the relatively slow CPU to GPU bus). So even though rendering your vertices is super fast, giving your GPU the commands to render them isn't.
 </p>
 
 <p>
   It would be much more convenient if we could send data over to the GPU once, and then tell OpenGL to draw multiple objects using this data with a single drawing call. Enter <def>instancing</def>.
 </p>
 
 <p>
   Instancing is a technique where we draw many (equal mesh data) objects at once with a single render call, saving us all the CPU -> GPU communications each time we need to render an object. To render using instancing all we need to do is change the render calls <fun><function id='1'>glDrawArrays</function></fun> and <fun><function id='2'>glDrawElements</function></fun> to <fun><function id='98'><function id='1'>glDrawArrays</function>Instanced</function></fun> and <fun><function id='99'><function id='2'>glDrawElements</function>Instanced</function></fun> respectively. These <em>instanced</em> versions of the classic rendering functions take an extra parameter called the <def>instance count</def> that sets the number of instances we want to render. We sent all the required data to the GPU once, and then tell the GPU how it should draw all these instances with a single call. The GPU then renders all these instances without having to continually communicate with the CPU.
 </p>
 
 <p>
   By itself this function is a bit useless. Rendering the same object a thousand times is of no use to us since each of the rendered objects is rendered exactly the same and thus also at the same location; we would only see one object! For this reason GLSL added another built-in variable in the vertex shader called <var>gl_InstanceID</var>. 
 </p>
 
 <p>
   When drawing with one of the instanced rendering calls, <var>gl_InstanceID</var> is incremented for each instance being rendered starting from <code>0</code>. If we were to render the 43th instance for example, <var>gl_InstanceID</var> would have the value <code>42</code> in the vertex shader. Having a unique value per instance means we could now for example index into a large array of position values to position each instance at a different location in the world.
 </p>
 
 <p>
   To get a feel for instanced drawing we're going to demonstrate a simple example that renders a hundred 2D quads in normalized device coordinates with just one render call. We accomplish this by uniquely positioning each instanced quad by indexing a uniform array of <code>100</code> offset vectors. The result is a neatly organized grid of quads that fill the entire window:
 </p>
 
 <img src="/img/advanced/instancing_quads.png" class="clean" alt="100 Quads drawn via OpenGL instancing."/>
 
 <p>
   Each quad consists of 2 triangles with a total of 6 vertices. Each vertex contains a 2D NDC position vector and a color vector. Below is the vertex data used for this example - the triangles are small enough to properly fit the screen when there's a 100 of them:
 </p>
 
 <pre><code>
 float quadVertices[] = {
     // positions     // colors
     -0.05f,  0.05f,  1.0f, 0.0f, 0.0f,
      0.05f, -0.05f,  0.0f, 1.0f, 0.0f,
     -0.05f, -0.05f,  0.0f, 0.0f, 1.0f,
 
     -0.05f,  0.05f,  1.0f, 0.0f, 0.0f,
      0.05f, -0.05f,  0.0f, 1.0f, 0.0f,   
      0.05f,  0.05f,  0.0f, 1.0f, 1.0f		    		
 };  
 </code></pre>
 
 <p>
   The quads are colored in the fragment shader that receives a color vector from the vertex shader and sets it as its output:
 </p>
 
 <pre><code>
 #version 330 core
 out vec4 FragColor;
   
 in vec3 fColor;
 
 void main()
 {
     FragColor = vec4(fColor, 1.0);
 }
 </code></pre>
 
 <p>
   Nothing new so far, but at the vertex shader it's starting to get interesting:
 </p>
 
 <pre><code>
 #version 330 core
 layout (location = 0) in vec2 aPos;
 layout (location = 1) in vec3 aColor;
 
 out vec3 fColor;
 
 uniform vec2 offsets[100];
 
 void main()
 {
     vec2 offset = offsets[gl_InstanceID];
     gl_Position = vec4(aPos + offset, 0.0, 1.0);
     fColor = aColor;
 }  
 </code></pre>
 
 <p>
   Here we defined a uniform array called <var>offsets</var> that contain a total of <code>100</code> offset vectors. Within the vertex shader we retrieve an offset vector for each instance by indexing the <var>offsets</var> array using <var>gl_InstanceID</var>. If we now were to draw <code>100</code> quads with instanced drawing we'd get <code>100</code> quads located at different positions.
 </p>
 
 <p>
   We do need to actually set the offset positions that we calculate in a nested for-loop before we enter the render loop:
 </p>
 
 <pre><code>
 glm::vec2 translations[100];
 int index = 0;
 float offset = 0.1f;
 for(int y = -10; y &lt; 10; y += 2)
 {
     for(int x = -10; x &lt; 10; x += 2)
     {
         glm::vec2 translation;
         translation.x = (float)x / 10.0f + offset;
         translation.y = (float)y / 10.0f + offset;
         translations[index++] = translation;
     }
 }  
 </code></pre>
 
 <p>
   Here we create a set of <code>100</code> translation vectors that contains an offset vector for all positions in a 10x10 grid. In addition to generating the <var>translations</var> array, we'd also need to transfer the data to the vertex shader's uniform array:
 </p>
 
 <pre><code>
 shader.use();
 for(unsigned int i = 0; i &lt; 100; i++)
 {
     shader.setVec2(("offsets[" + std::to_string(i) + "]")), translations[i]);
 }  
 </code></pre>
 
 <p>
   Within this snippet of code we transform the for-loop counter <var>i</var> to a <fun>string</fun> to dynamically create a location string for querying the uniform location. For each item in the <var>offsets</var> uniform array we then set the corresponding translation vector.
 </p>
 
 <p>
   Now that all the preparations are finished we can start rendering the quads. To draw via instanced rendering we call <fun><function id='98'><function id='1'>glDrawArrays</function>Instanced</function></fun> or <fun><function id='99'><function id='2'>glDrawElements</function>Instanced</function></fun>. Since we're not using an element index buffer we're going to call the <fun><function id='1'>glDrawArrays</function></fun> version:
 </p>
 
 <pre class="cpp"><code>
 <function id='27'>glBindVertexArray</function>(quadVAO);
 <function id='98'><function id='1'>glDrawArrays</function>Instanced</function>(GL_TRIANGLES, 0, 6, 100);  
 </code></pre>
 
 <p>
   The parameters of <fun><function id='98'><function id='1'>glDrawArrays</function>Instanced</function></fun> are exactly the same as <fun><function id='1'>glDrawArrays</function></fun> except the last parameter that sets the number of instances we want to draw. Since we want to display <code>100</code> quads in a 10x10 grid we set it equal to <code>100</code>. Running the code should now give you the familiar image of <code>100</code> colorful quads.
 </p>
 
 <h2>Instanced arrays</h2>
 <p>
   While the previous implementation works fine for this specific use case, whenever we are rendering a lot more than <code>100</code> instances (which is quite common) we will eventually hit a <a href="https://www.khronos.org/opengl/wiki/GLSL_Uniform#Implementation_limits" target="_blank">limit</a> on the amount of uniform data we can send to the shaders. One alternative option is known as <def>instanced arrays</def>. Instanced arrays are defined as a vertex attribute (allowing us to store much more data) that are updated per instance instead of per vertex.
 </p>
 
 <p>
   With vertex attributes, at the start of each run of the vertex shader, the GPU will retrieve the next set of vertex attributes that belong to the current vertex. When defining a vertex attribute as an instanced array however, the vertex shader only updates the content of the vertex attribute per instance. This allows us to use the standard vertex attributes for data per vertex and use the instanced array for storing data that is unique per instance.
 </p>
 
 <p>
   To give you an example of an instanced array we're going to take the previous example and convert the offset uniform array to an instanced array. We'll have to update the vertex shader by adding another vertex attribute:
 </p>
 
 <pre><code>
 #version 330 core
 layout (location = 0) in vec2 aPos;
 layout (location = 1) in vec3 aColor;
 layout (location = 2) in vec2 aOffset;
 
 out vec3 fColor;
 
 void main()
 {
     gl_Position = vec4(aPos + aOffset, 0.0, 1.0);
     fColor = aColor;
 }  
 </code></pre>
 
 <p>
   We no longer use <var>gl_InstanceID</var> and can directly use the <var>offset</var> attribute  without first indexing into a large uniform array.
 </p>
 
 <p>
   Because an instanced array is a vertex attribute, just like the <var>position</var> and <var>color</var> variables, we need to store its content in a vertex buffer object and configure its attribute pointer. We're first going to store the <var>translations</var> array (from the previous section) in a new buffer object:
 </p>
 
 <pre><code>
 unsigned int instanceVBO;
 <function id='12'>glGenBuffers</function>(1, &instanceVBO);
 <function id='32'>glBindBuffer</function>(GL_ARRAY_BUFFER, instanceVBO);
 <function id='31'>glBufferData</function>(GL_ARRAY_BUFFER, sizeof(glm::vec2) * 100, &translations[0], GL_STATIC_DRAW);
 <function id='32'>glBindBuffer</function>(GL_ARRAY_BUFFER, 0); 
 </code></pre>
 
 <p>
   Then we also need to set its vertex attribute pointer and enable the vertex attribute:
 </p>
 
 <pre><code>
 <function id='29'><function id='60'>glEnable</function>VertexAttribArray</function>(2);
 <function id='32'>glBindBuffer</function>(GL_ARRAY_BUFFER, instanceVBO);
 <function id='30'>glVertexAttribPointer</function>(2, 2, GL_FLOAT, GL_FALSE, 2 * sizeof(float), (void*)0);
 <function id='32'>glBindBuffer</function>(GL_ARRAY_BUFFER, 0);	
 <function id='100'>glVertexAttribDivisor</function>(2, 1);  
 </code></pre>
 
 <p>
   What makes this code interesting is the last line where we call <fun><function id='100'>glVertexAttribDivisor</function></fun>. This function tells OpenGL <strong>when</strong> to update the content of a vertex attribute to the next element. Its first parameter is the vertex attribute in question and the second parameter the <def>attribute divisor</def>. By default, the attribute divisor is <code>0</code> which tells OpenGL to update the content of the vertex attribute each iteration of the vertex shader. By setting this attribute to <code>1</code> we're telling OpenGL that we want to update the content of the vertex attribute when we start to render a new instance. By setting it to <code>2</code> we'd update the content every 2 instances and so on. By setting the attribute divisor to <code>1</code> we're effectively telling OpenGL that the vertex attribute at attribute location <code>2</code> is an instanced array.
 </p>
 
 <p>
   If we now were to render the quads again with <fun><function id='98'><function id='1'>glDrawArrays</function>Instanced</function></fun> we'd get the following output:
 </p>
 
 <img src="/img/advanced/instancing_quads.png" class="clean" alt="Same image of OpenGL instanced quads, but this time using instanced arrays."/>
 
 <p>
   This is exactly the same as the previous example, but now with instanced arrays, which allows us to pass a lot more data (as much as memory allows us) to the vertex shader for instanced drawing.
 </p>
 
 <p>
   For fun we could slowly downscale each quad from top-right to bottom-left using <var>gl_InstanceID</var> again, because why not?
 </p>
 
 <pre><code>
 void main()
 {
     vec2 pos = aPos * (gl_InstanceID / 100.0);
     gl_Position = vec4(pos + aOffset, 0.0, 1.0);
     fColor = aColor;
 } 
 </code></pre>
 
 <p>
   The result is that the first instances of the quads are drawn extremely small and the further we're in the process of drawing the instances, the closer <var>gl_InstanceID</var> gets to <code>100</code> and thus the more the quads regain their original size. It's perfectly legal to use instanced arrays together with <var>gl_InstanceID</var> like this.
 </p>
 
 <img src="/img/advanced/instancing_quads_arrays.png" class="clean" alt="Image of instanced quads drawn in OpenGL using instanced arrays"/>
 
 <p>
   If you're still a bit unsure about how instanced rendering works or want to see how everything fits together you can find the full source code of the application <a href="/code_viewer_gh.php?code=src/4.advanced_opengl/10.1.instancing_quads/instancing_quads.cpp" target="_blank">here</a>.
 </p>
 
 <p>
   While fun and all, these examples aren't really good examples of instancing. Yes, they do give you an easy overview of how instancing works, but instancing gets most of its power when drawing an enormous amount of similar objects. For that reason we're going to venture into space.
 </p>
 
 <h1>An asteroid field</h1>
 <p>
   Imagine a scene where we have one large planet that's at the center of a large asteroid ring. Such an asteroid ring could contain thousands or tens of thousands of rock formations and quickly becomes un-renderable on any decent graphics card. This scenario proves itself particularly useful for instanced rendering, since all the asteroids can be represented with a single model. Each single asteroid then gets its variation from a transformation matrix unique to each asteroid.
 </p>
 
 <p>
   To demonstrate the impact of instanced rendering we're first going to render a scene of asteroids hovering around a planet <em>without</em> instanced rendering. The scene will contain a large planet model that can be downloaded from <a href="/data/models/planet.zip" target="_blank">here</a> and a large set of asteroid rocks that we properly position around the planet. The asteroid rock model can be downloaded <a href="/data/models/rock.zip" target="_blank">here</a>.
 </p>
 
 <p>
   Within the code samples we load the models using the model loader we've previously defined in the <a href="https://learnopengl.com/Model-Loading/Assimp" target="_blank">model loading</a> chapters. 
 </p>
 
 <p>
   To achieve the effect we're looking for we'll be generating a model transformation matrix for each asteroid. The transformation matrix first translates the rock somewhere in the asteroid ring - then we'll add a small random displacement value to the offset to make the ring look more natural. From there we also apply a random scale and a random rotation. The result is a transformation matrix that translates each asteroid somewhere around the planet while also giving it a more natural and unique look compared to the other asteroids. 
 </p>
 
 <pre><code>
 unsigned int amount = 1000;
 glm::mat4 *modelMatrices;
 modelMatrices = new glm::mat4[amount];
 srand(<function id='47'>glfwGetTime</function>()); // initialize random seed	
 float radius = 50.0;
 float offset = 2.5f;
 for(unsigned int i = 0; i &lt; amount; i++)
 {
     glm::mat4 model = glm::mat4(1.0f);
     // 1. translation: displace along circle with 'radius' in range [-offset, offset]
     float angle = (float)i / (float)amount * 360.0f;
     float displacement = (rand() % (int)(2 * offset * 100)) / 100.0f - offset;
     float x = sin(angle) * radius + displacement;
     displacement = (rand() % (int)(2 * offset * 100)) / 100.0f - offset;
     float y = displacement * 0.4f; // keep height of field smaller compared to width of x and z
     displacement = (rand() % (int)(2 * offset * 100)) / 100.0f - offset;
     float z = cos(angle) * radius + displacement;
     model = <function id='55'>glm::translate</function>(model, glm::vec3(x, y, z));
 
     // 2. scale: scale between 0.05 and 0.25f
     float scale = (rand() % 20) / 100.0f + 0.05;
     model = <function id='56'>glm::scale</function>(model, glm::vec3(scale));
 
     // 3. rotation: add random rotation around a (semi)randomly picked rotation axis vector
     float rotAngle = (rand() % 360);
     model = <function id='57'>glm::rotate</function>(model, rotAngle, glm::vec3(0.4f, 0.6f, 0.8f));
 
     // 4. now add to list of matrices
     modelMatrices[i] = model;
 }  
 </code></pre>
 
 <p>
   This piece of code may look a little daunting, but we basically transform the x and z position of the asteroid along a circle with a radius defined by <var>radius</var> and randomly displace each asteroid a little around the circle by <var>-offset</var> and <var>offset</var>. We give the <code>y</code> displacement less of an impact to create a more flat asteroid ring. Then we apply scale and rotation transformations and store the resulting transformation matrix in <var>modelMatrices</var> that is of size <var>amount</var>. Here we generate <code>1000</code> model matrices, one per asteroid.
 </p>
 
 <p>
   After loading the planet and rock models and compiling a set of shaders, the rendering code then looks a bit like this:
 </p>
 
 <pre><code>
 // draw planet
 shader.use();
 glm::mat4 model = glm::mat4(1.0f);
 model = <function id='55'>glm::translate</function>(model, glm::vec3(0.0f, -3.0f, 0.0f));
 model = <function id='56'>glm::scale</function>(model, glm::vec3(4.0f, 4.0f, 4.0f));
 shader.setMat4("model", model);
 planet.Draw(shader);
   
 // draw meteorites
 for(unsigned int i = 0; i &lt; amount; i++)
 {
     shader.setMat4("model", modelMatrices[i]);
     rock.Draw(shader);
 }  
 </code></pre>
 
 <p>
   First we draw the planet model, that we translate and scale a bit to accommodate the scene, and then we draw a number of rock models equal to the <var>amount</var> of transformations we generated previously.  Before we draw each rock however, we first set the corresponding model transformation matrix within the shader.
 </p>
 
 <p>
   The result is then a space-like scene where we can see a natural-looking asteroid ring around a planet:
 </p>
 
 <img src="/img/advanced/instancing_asteroids.png" class="clean" alt="Image of asteroid field drawn in OpenGL"/>
 
 <p>
   This scene contains a total of <code>1001</code> rendering calls per frame of which <code>1000</code> are of the rock model. You can find the source code for this scene <a href="/code_viewer_gh.php?code=src/4.advanced_opengl/10.2.asteroids/asteroids.cpp" target="_blank">here</a>.
 </p>
 
 <p>
   As soon as we start to increase this number we will quickly notice that the scene stops running smoothly and the number of frames we're able to render per second reduces drastically. As soon as we set <var>amount</var> to something close to <code>2000</code> the scene already becomes so slow on our GPU that it becomes difficult to move around. 
 </p>
 
 <p>
   Let's now try to render the same scene, but this time with instanced rendering. We first need to adjust the vertex shader a little:
 </p>
 
 <pre><code>
 #version 330 core
 layout (location = 0) in vec3 aPos;
 layout (location = 2) in vec2 aTexCoords;
 layout (location = 3) in mat4 instanceMatrix;
 
 out vec2 TexCoords;
 
 uniform mat4 projection;
 uniform mat4 view;
 
 void main()
 {
     gl_Position = projection * view * instanceMatrix * vec4(aPos, 1.0); 
     TexCoords = aTexCoords;
 }
 </code></pre>
 
 <p>
   We're no longer using a model uniform variable, but instead declare a <fun>mat4</fun> as a vertex attribute so we can store an instanced array of transformation matrices. However, when we declare a datatype as a vertex attribute that is greater than a <fun>vec4</fun> things work a bit differently. The maximum amount of data allowed for a vertex attribute is equal to a <fun>vec4</fun>. Because a <fun>mat4</fun> is basically 4 <fun>vec4</fun>s, we have to reserve 4 vertex attributes for this specific matrix. Because we assigned it a location of <code>3</code>, the columns of the matrix will have vertex attribute locations of <code>3</code>, <code>4</code>, <code>5</code>, and <code>6</code>.
 </p>
 
 <p>
   We then have to set each of the attribute pointers of those <code>4</code> vertex attributes and configure them as instanced arrays:
 </p>
 
 <pre><code>
 // vertex buffer object
 unsigned int buffer;
 <function id='12'>glGenBuffers</function>(1, &buffer);
 <function id='32'>glBindBuffer</function>(GL_ARRAY_BUFFER, buffer);
 <function id='31'>glBufferData</function>(GL_ARRAY_BUFFER, amount * sizeof(glm::mat4), &modelMatrices[0], GL_STATIC_DRAW);
   
 for(unsigned int i = 0; i &lt; rock.meshes.size(); i++)
 {
     unsigned int VAO = rock.meshes[i].VAO;
     <function id='27'>glBindVertexArray</function>(VAO);
     // vertex attributes
     std::size_t vec4Size = sizeof(glm::vec4);
     <function id='29'><function id='60'>glEnable</function>VertexAttribArray</function>(3); 
     <function id='30'>glVertexAttribPointer</function>(3, 4, GL_FLOAT, GL_FALSE, 4 * vec4Size, (void*)0);
     <function id='29'><function id='60'>glEnable</function>VertexAttribArray</function>(4); 
     <function id='30'>glVertexAttribPointer</function>(4, 4, GL_FLOAT, GL_FALSE, 4 * vec4Size, (void*)(1 * vec4Size));
     <function id='29'><function id='60'>glEnable</function>VertexAttribArray</function>(5); 
     <function id='30'>glVertexAttribPointer</function>(5, 4, GL_FLOAT, GL_FALSE, 4 * vec4Size, (void*)(2 * vec4Size));
     <function id='29'><function id='60'>glEnable</function>VertexAttribArray</function>(6); 
     <function id='30'>glVertexAttribPointer</function>(6, 4, GL_FLOAT, GL_FALSE, 4 * vec4Size, (void*)(3 * vec4Size));
 
     <function id='100'>glVertexAttribDivisor</function>(3, 1);
     <function id='100'>glVertexAttribDivisor</function>(4, 1);
     <function id='100'>glVertexAttribDivisor</function>(5, 1);
     <function id='100'>glVertexAttribDivisor</function>(6, 1);
 
     <function id='27'>glBindVertexArray</function>(0);
 }  
 </code></pre>
 
 <p>
   Note that we cheated a little by declaring the <var>VAO</var> variable of the <fun>Mesh</fun> as a public variable instead of a private variable so we could access its vertex array object. This is not the cleanest solution, but just a simple modification to suit this example. Aside from the little hack, this code should be clear. We're basically declaring how OpenGL should interpret the buffer for each of the matrix's vertex attributes and that each of those vertex attributes is an instanced array.
 </p>
 
 <p>
   Next we take the <var>VAO</var> of the mesh(es) again and this time draw using <fun><function id='99'><function id='2'>glDrawElements</function>Instanced</function></fun>:
 </p>
 
 <pre><code>
 // draw meteorites
 instanceShader.use();
 for(unsigned int i = 0; i &lt; rock.meshes.size(); i++)
 {
     <function id='27'>glBindVertexArray</function>(rock.meshes[i].VAO);
     <function id='99'><function id='2'>glDrawElements</function>Instanced</function>(
         GL_TRIANGLES, rock.meshes[i].indices.size(), GL_UNSIGNED_INT, 0, amount
     );
 }  
 </code></pre>
 
 <p>
   Here we draw the same <var>amount</var> of asteroids as the previous example, but this time with instanced rendering. The results should be exactly the same, but once we increase the <var>amount</var> you'll really start to see the power of instanced rendering. Without instanced rendering we were able to smoothly render around <code>1000</code> to <code>1500</code> asteroids. With instanced rendering we can now set this value to <code>100000</code>. This, with the rock model having <code>576</code> vertices, would equal around <code>57</code> million vertices drawn each frame without significant performance drops; and only 2 draw calls!
 </p>
 
 <img src="/img/advanced/instancing_asteroids_quantity.png" class="clean" alt="Image of asteroid field in OpenGL drawn using instanced rendering"/>
 
 <p>
   This image was rendered with <code>100000</code> asteroids with a radius of <code>150.0f</code> and an offset equal to <code>25.0f</code>. You can find the source code of the instanced rendering demo <a href="/code_viewer_gh.php?code=src/4.advanced_opengl/10.3.asteroids_instanced/asteroids_instanced.cpp" target="_blank">here</a>.
 </p>
 
 <note>
   On different machines an asteroid count of <code>100000</code> may be a bit too high, so try tweaking the values till you reach an acceptable framerate.
 </note>
 
 <p>
   As you can see, with the right type of environments, instanced rendering can make an enormous difference to the rendering capabilities of your application. For this reason, instanced rendering is commonly used for grass, flora, particles, and scenes like this - basically any scene with many repeating shapes can benefit from instanced rendering.
 </p>       
 
     </div>