LearnOpenGL

Advanced-GLSL.html (36293B)

---

     <div id="content">
     <h1 id="content-title">Advanced GLSL</h1>
 <h1 id="content-url" style='display:none;'>Advanced-OpenGL/Advanced-GLSL</h1>
 <p>
   This chapter won't really show you super advanced cool new features that give an enormous boost to your scene's visual quality. This chapter goes more or less into some interesting aspects of GLSL and some nice tricks that may help you in your future endeavors. Basically some <em>good to knows</em> and <em>features that may make your life easier</em> when creating OpenGL applications in combination with GLSL.
 </p>
 
 <p>
   We'll discuss some interesting <def>built-in variables</def>, new ways to organize shader input and output, and a very useful tool called <def>uniform buffer objects</def>.
 </p>
 
 <h1>GLSL's built-in variables</h1>
 <p>
   Shaders are extremely pipelined, if we need data from any other source outside of the current shader we'll have to pass data around. We learned to do this via vertex attributes, uniforms, and samplers. There are however a few extra variables defined by GLSL prefixed with <code>gl_</code> that give us an extra means to gather and/or write data. We've already seen two of them in the chapters so far: <var>gl_Position</var> that is the output vector of the vertex shader, and the fragment shader's <var>gl_FragCoord</var>.  
 </p>
 
 <p>
   We'll discuss a few interesting built-in input and output variables that are built-in in GLSL and explain how they may benefit us. Note that we won't discuss all built-in variables that exist in GLSL so if you want to see all built-in variables you can check OpenGL's <a href="https://www.khronos.org/opengl/wiki/Built-in_Variable_(GLSL)" target="_blank">wiki</a>.
 </p>
 
 <h2>Vertex shader variables</h2>
 <p>
   We've already seen <var>gl_Position</var> which is the clip-space output position vector of the vertex shader. Setting <var>gl_Position</var> in the vertex shader is a strict requirement if you want to render anything on the screen. Nothing we haven't seen before.
 </p>
 
 <h3>gl_PointSize</h3>
 <p>
   One of the render primitives we're able to choose from is <var>GL_POINTS</var> in which case each single vertex is a primitive and rendered as a point. It is possible to set the size of the points being rendered via OpenGL's <fun>glPointSize</fun> function, but we can also influence this value in the vertex shader.
 </p>
 
 <p>
   One output variable defined by GLSL is called <var>gl_PointSize</var> that is a <fun>float</fun> variable where you can set the point's width and height in pixels. By setting the point's size in the vertex shader we get per-vertex control over this point's dimensions.
 </p>
 
 <p>
   Influencing the point sizes in the vertex shader is disabled by default, but if you want to enable this you'll have to enable OpenGL's <var>GL_PROGRAM_POINT_SIZE</var>:
 </p>
 
 <pre><code>
 <function id='60'>glEnable</function>(GL_PROGRAM_POINT_SIZE);  
 </code></pre>
 
 <p>
   A simple example of influencing point sizes is by setting the point size equal to the clip-space position's z value which is equal to the vertex's distance to the viewer. The point size should then increase the further we are from the vertices as the viewer.
 </p>
 
 <pre><code>
 void main()
 {
     gl_Position = projection * view * model * vec4(aPos, 1.0);    
     gl_PointSize = gl_Position.z;    
 }  
 </code></pre>
 
 <p>
   The result is that the points we've drawn are rendered larger the more we move away from them:
 </p>
 
 <img src="/img/advanced/advanced_glsl_pointsize.png" class="clean" alt="Points in OpenGL drawn with their gl_PointSize influenced in the vertex shader"/>
 
 <p>
   You can imagine that varying the point size per vertex is interesting for techniques like particle generation.
 </p>
 
 <h3>gl_VertexID</h3>
 <p>
   The <var>gl_Position</var> and <var>gl_PointSize</var> are <em>output variables</em> since their value is read as output from the vertex shader; we can influence the result by writing to them. The vertex shader also gives us an interesting <em>input variable</em>, that we can only read from, called <var>gl_VertexID</var>.
 </p>
 
 <p>
   The integer variable <var>gl_VertexID</var> holds the current ID of the vertex we're drawing. When doing <em>indexed rendering</em> (with <fun><function id='2'>glDrawElements</function></fun>) this variable holds the current index of the vertex we're drawing. When drawing without indices (via <fun><function id='1'>glDrawArrays</function></fun>) this variable holds the number of the currently processed vertex since the start of the render call.
 </p>
 
 <h2>Fragment shader variables</h2>
 <p>
   Within the fragment shader we also have access to some interesting variables. GLSL gives us two interesting input variables called <var>gl_FragCoord</var> and <var>gl_FrontFacing</var>.
 </p>
 
 <h3>gl_FragCoord</h3>
 <p>
   We've seen the <var>gl_FragCoord</var> a couple of times before during the discussion of depth testing, because the <code>z</code> component of the <var>gl_FragCoord</var> vector is equal to the depth value of that particular fragment. However, we can also use the x and y component of that vector for some interesting effects.
 </p>
 
 <p>
   The <var>gl_FragCoord</var>'s <code>x</code> and <code>y</code> component are the window- or screen-space coordinates of the fragment, originating from the bottom-left of the window. We specified a render window of 800x600 with <fun><function id='22'>glViewport</function></fun> so the screen-space coordinates of the fragment will have <code>x</code> values between 0 and 800, and <code>y</code> values between 0 and 600.
 </p>
 
 <p>
   Using the fragment shader we could calculate a different color value based on the screen coordinate of the fragment. A common usage for the <var>gl_FragCoord</var> variable is for comparing visual output of different fragment calculations, as usually seen in tech demos. We could for example split the screen in two by rendering one output to the left side of the window and another output to the right side of the window. An example fragment shader that outputs a different color based on the fragment's screen coordinates is given below:
 </p>
 
 <pre><code>
 void main()
 {             
     if(gl_FragCoord.x &lt; 400)
         FragColor = vec4(1.0, 0.0, 0.0, 1.0);
     else
         FragColor = vec4(0.0, 1.0, 0.0, 1.0);        
 }  
 </code></pre>
 
 <p>
   Because the width of the window is equal to 800, whenever a pixel's x-coordinate is less than 400 it must be at the left side of the window and we'll give that fragment a different color.
 </p>
 
 <img src="/img/advanced/advanced_glsl_fragcoord.png" class="clean" alt="Cube in OpenGL drawn with 2 colors using gl_FragCoord"/>
 
 <p>
   We can now calculate two completely different fragment shader results and display each of them on a different side of the window. This is great for testing out different lighting techniques for example.
 </p>
 
 <h3>gl_FrontFacing</h3>
 <p>
   Another interesting input variable in the fragment shader is the <var>gl_FrontFacing</var> variable. In the <a href="https://learnopengl.com/Advanced-OpenGL/Face-culling" target="_blank">face culling</a> chapter we mentioned that OpenGL is able to figure out if a face is a front or back face due to the winding order of the vertices. The <var>gl_FrontFacing</var> variable tells us if the current fragment is part of a front-facing or a back-facing face. We could, for example, decide to output different colors for all back faces.
 </p>
 
 <p>
   The <var>gl_FrontFacing</var> variable is a <fun>bool</fun> that is <code>true</code> if the fragment is part of a front face and <code>false</code> otherwise. We could create a cube this way with a different texture on the inside than on the outside:
 </p>
 
 <pre><code>
 #version 330 core
 out vec4 FragColor;
   
 in vec2 TexCoords;
 
 uniform sampler2D frontTexture;
 uniform sampler2D backTexture;
 
 void main()
 {             
     if(gl_FrontFacing)
         FragColor = texture(frontTexture, TexCoords);
     else
         FragColor = texture(backTexture, TexCoords);
 }  
 </code></pre>
 
 <p>
   If we take a peek inside the container we can now see a different texture being used.
 </p>
 
 <img src="/img/advanced/advanced_glsl_frontfacing.png" class="clean" alt="OpenGL container using two different textures via gl_FrontFacing"/>
 
 <p>
   Note that if you enabled face culling you won't be able to see any faces inside the container and using <var>gl_FrontFacing</var> would then be pointless.
 </p>
 
 <h3>gl_FragDepth</h3>
 <p>
   The input variable <var>gl_FragCoord</var> is an input variable that allows us to read screen-space coordinates and get the depth value of the current fragment, but it is a <def>read-only</def> variable. We can't influence the screen-space coordinates of the fragment, but it is possible to set the depth value of the fragment. GLSL gives us an output variable called <var>gl_FragDepth</var> that we can use to manually set the depth value of the fragment within the shader.
 </p>
 
 <p>
   To set the depth value in the shader we write any value between <code>0.0</code> and <code>1.0</code> to the output variable:
 </p>
 
 <pre><code>
 gl_FragDepth = 0.0; // this fragment now has a depth value of 0.0
 </code></pre>
 
 <p>
   If the shader does not write anything to <var>gl_FragDepth</var>, the variable will automatically take its value from <code>gl_FragCoord.z</code>.
 </p>
 
 <p>
   Setting the depth value manually has a major disadvantage however. That is because OpenGL disables <def>early depth testing</def> (as discussed in the <a href="https://learnopengl.com/Advanced-OpenGL/Depth-testing" target="_blank">depth testing</a> chapter) as soon as we write to <var>gl_FragDepth</var> in the fragment shader. It is disabled, because OpenGL cannot know what depth value the fragment will have <em>before</em> we run the fragment shader, since the fragment shader may actually change this value.
 </p>
 
 <p>
   By writing to <var>gl_FragDepth</var> you should take this performance penalty into consideration. From OpenGL 4.2 however, we can still sort of mediate between both sides by redeclaring the <var>gl_FragDepth</var> variable at the top of the fragment shader with a <def>depth condition</def>:
 </p>
 
 <pre><code>
 layout (depth_&ltcondition&gt;) out float gl_FragDepth;
 </code></pre>
 
 <p>
   This <code>condition</code> can take the following values:
 </p>
 
 <table>
   <tr>
   	<th>Condition</th>
   	<th>Description</th>
   </tr>  
   <tr>
     <td><code>any</code></td>
  	<td>The default value. Early depth testing is disabled.</td>
   </tr>
   <tr>
     <td><code>greater</code></td>
     <td>You can only make the depth value larger compared to <code>gl_FragCoord.z</code>.</td>
   </tr>
   <tr>
     <td><code>less</code></td>
  	<td>You can only make the depth value smaller compared to <code>gl_FragCoord.z</code>.</td>
   </tr>
   <tr>
     <td><code>unchanged</code></td>
     <td>If you write to <code>gl_FragDepth</code>, you will write exactly <code>gl_FragCoord.z</code>.</td>
   </tr>
 </table>
 
 <p>
   By specifying <code>greater</code> or <code>less</code> as the depth condition, OpenGL can make the assumption that you'll only write depth values larger or smaller than the fragment's depth value. This way OpenGL is still able to do early depth testing when the depth buffer value is part of the other direction of <code>gl_FragCoord.z</code>.  
 </p>
 
 <p>
   An example of where we increase the depth value in the fragment shader, but still want to preserve some of the early depth testing is shown in the fragment shader below:
 </p>
 
 <pre><code>
 #version 420 core // note the GLSL version!
 out vec4 FragColor;
 layout (depth_greater) out float gl_FragDepth;
 
 void main()
 {             
     FragColor = vec4(1.0);
     gl_FragDepth = gl_FragCoord.z + 0.1;
 }  
 </code></pre>
 
 <p>
   Do note that this feature is only available from OpenGL version 4.2 or higher.
 </p>
 
 <h1>Interface blocks</h1>
 <p>
   So far, every time we sent data from the vertex to the fragment shader we declared several matching input/output variables. Declaring these one at a time is the easiest way to send data from one shader to another, but as applications become larger you probably want to send more than a few variables over.
 </p>
 
 <p>
   To help us organize these variables GLSL offers us something called <def>interface blocks</def> that allows us to group variables together. The declaration of such an interface block looks a lot like a <fun>struct</fun> declaration, except that it is now declared using an <fun>in</fun> or <fun>out</fun> keyword based on the block being an input or an output block.
 </p>
 
 <pre><code>
 #version 330 core
 layout (location = 0) in vec3 aPos;
 layout (location = 1) in vec2 aTexCoords;
 
 uniform mat4 model;
 uniform mat4 view;
 uniform mat4 projection;
 
 out VS_OUT
 {
     vec2 TexCoords;
 } vs_out;
 
 void main()
 {
     gl_Position = projection * view * model * vec4(aPos, 1.0);    
     vs_out.TexCoords = aTexCoords;
 }  
 </code></pre>
 
 <p>
   This time we declared an interface block called <var>vs_out</var> that groups together all the output variables we want to send to the next shader. This is kind of a trivial example, but you can imagine that this helps organize your shaders' inputs/outputs. It is also useful when we want to group shader input/output into arrays as we'll see in the <a href="https://learnopengl.com/Advanced-OpenGL/Geometry-Shader" target="_blank">next</a> chapter about geometry shaders.
 </p>
 
 <p>
   Then we also need to declare an input interface block in the next shader which is the fragment shader. The <def>block name</def> (<fun>VS_OUT</fun>) should be the same in the fragment shader, but the <def>instance name</def> (<var>vs_out</var> as used in the vertex shader) can be anything we like - avoiding confusing names like <var>vs_out</var> for a fragment struct containing input values.
 </p>
 
 <pre><code>
 #version 330 core
 out vec4 FragColor;
 
 in VS_OUT
 {
     vec2 TexCoords;
 } fs_in;
 
 uniform sampler2D texture;
 
 void main()
 {             
     FragColor = texture(texture, fs_in.TexCoords);   
 } 
 </code></pre>
 
 <p>
   As long as both interface block names are equal, their corresponding input and output is matched together. This is another useful feature that helps organize your code and proves useful when crossing between certain shader stages like the geometry shader.
 </p>
 
 <h1>Uniform buffer objects</h1>
 <p>
   We've been using OpenGL for quite a while now and learned some pretty cool tricks, but also a few annoyances. For example, when using more than one shader we continuously have to set uniform variables where most of them are exactly the same for each shader.
 </p>
 
 <p>
   OpenGL gives us a tool called <def>uniform buffer objects</def> that allow us to declare a set of <em>global</em> uniform variables that remain the same over any number of shader programs. When using uniform buffer objects we set the relevant uniforms only <strong>once</strong> in fixed GPU memory. We do still have to manually set the uniforms that are unique per shader. Creating and configuring a uniform buffer object requires a bit of work though.
 </p>
 
 <p>
   Because a uniform buffer object is a buffer like any other buffer we can create one via <fun><function id='12'>glGenBuffers</function></fun>, bind it to the <var>GL_UNIFORM_BUFFER</var> buffer target and store all the relevant uniform data into the buffer. There are certain rules as to how the data for uniform buffer objects should be stored and we'll get to that later. First, we'll take a simple vertex shader and store our <var>projection</var> and <var>view</var> matrix in a so called <def>uniform block</def>:
 </p>
 
 <pre><code>
 #version 330 core
 layout (location = 0) in vec3 aPos;
 
 layout (std140) uniform Matrices
 {
     mat4 projection;
     mat4 view;
 };
 
 uniform mat4 model;
 
 void main()
 {
     gl_Position = projection * view * model * vec4(aPos, 1.0);
 }  
 </code></pre>
 
 <p>
   In most of our samples we set a projection and view uniform matrix every frame for each shader we're using. This is a perfect example of where uniform buffer objects become useful since now we only have to store these matrices once. 
 </p>
 
 <p>
   Here we declared a uniform block called <var>Matrices</var> that stores two 4x4 matrices. Variables in a uniform block can be directly accessed without the block name as a prefix. Then we store these matrix values in a buffer somewhere in the OpenGL code and each shader that declares this uniform block has access to the matrices.
 </p> 
 
 <p>
   You're probably wondering right now what the <code>layout</code> <code>(std140)</code> statement means. What this says is that the currently defined uniform block uses a specific memory layout for its content; this statement sets the <def>uniform block layout</def>.
 </p>
 
 <h2>Uniform block layout</h2>
 <p>
   The content of a uniform block is stored in a buffer object, which is effectively nothing more than a reserved piece of global GPU memory. Because this piece of memory holds no information on what kind of data it holds, we need to tell OpenGL what parts of the memory correspond to which uniform variables in the shader. 
 </p>
 
 <p>
   Imagine the following uniform block in a shader:
 </p>
 
 <pre><code>
 layout (std140) uniform ExampleBlock
 {
     float value;
     vec3  vector;
     mat4  matrix;
     float values[3];
     bool  boolean;
     int   integer;
 };  
 </code></pre>
 
 <p>
   What we want to know is the size (in bytes) and the offset (from the start of the block) of each of these variables so we can place them in the buffer in their respective order. The size of each of the elements is clearly stated in OpenGL and directly corresponds to C++ data types; vectors and matrices being (large) arrays of floats. What OpenGL doesn't clearly state is the <def>spacing</def> between the variables. This allows the hardware to position or pad variables as it sees fit. The hardware is able to place a <fun>vec3</fun> adjacent to a <fun>float</fun> for example. Not all hardware can handle this and pads the <fun>vec3</fun> to an array of 4 floats before appending the <fun>float</fun>. A great feature, but inconvenient for us.
 </p>
 
 <p>
   By default, GLSL uses a uniform memory layout called a <def>shared</def> layout - shared because once the offsets are defined by the hardware, they are consistently <em>shared</em> between multiple programs. With a shared layout GLSL is allowed to reposition the uniform variables for optimization as long as the variables' order remains intact. Because we don't know at what offset each uniform variable will be we don't know how to precisely fill our uniform buffer. We can query this information with functions like <fun>glGetUniformIndices</fun>, but that's not the approach we're going to take in this chapter.
 </p>
 
 <p>
   While a shared layout gives us some space-saving optimizations, we'd need to query the offset for each uniform variable which translates to a lot of work. The general practice however is to not use the shared layout, but to use the <def>std140</def> layout. The std140 layout <strong>explicitly</strong> states the memory layout for each variable type by standardizing their respective offsets governed by a set of rules. Since this is standardized we can manually figure out the offsets for each variable. 
 </p>
 
 <p>
   Each variable has a <def>base alignment</def> equal to the space a variable takes (including padding) within a uniform block using the std140 layout rules. For each variable, we calculate its <def>aligned offset</def>: the byte offset of a variable from the start of the block. The aligned byte offset of a variable <strong>must</strong> be equal to a multiple of its base alignment. This is a bit of a mouthful, but we'll get to see some examples soon enough to clear things up.
 </p>
 
 <p>
   The exact layout rules can be found at OpenGL's uniform buffer specification <a href="http://www.opengl.org/registry/specs/ARB/uniform_buffer_object.txt" target="_blank">here</a>, but we'll list the most common rules below. Each variable type in GLSL such as <fun>int</fun>, <fun>float</fun> and <fun>bool</fun> are defined to be four-byte quantities with each entity of 4 bytes represented as <code>N</code>. 
 </p>
 
 <table>
   <tr>
     <th>Type</th>
     <th>Layout rule</th>
   </tr>
   
   <tr>
     <td>Scalar e.g. <fun>int</fun> or <fun>bool</fun></td>
     <td>Each scalar has a base alignment of N.</td>
   </tr>
   <tr>
     <td>Vector</td>
     <td>Either 2N or 4N. This means that a <fun>vec3</fun> has a base alignment of 4N.</td>
   </tr>
   <tr>
     <td>Array of scalars or vectors</td>
     <td>Each element has a base alignment equal to that of a <fun>vec4</fun>.</td>
   </tr>
   <tr>
     <td>Matrices</td>
     <td>Stored as a large array of column vectors, where each of those vectors has a base alignment of <fun>vec4</fun>.</td>
   </tr>
   <tr>
     <td>Struct</td>
     <td>Equal to the computed size of its elements according to the previous rules, but padded to a multiple of the size of a <fun>vec4</fun>.</td>
   </tr>    
 </table>
 
 <p>
   Like most of OpenGL's specifications it's easier to understand with an example. We're taking the uniform block called <var>ExampleBlock</var> we introduced earlier and calculate the aligned offset for each of its members using the std140 layout:
 </p>
 
 <pre><code>
 layout (std140) uniform ExampleBlock
 {
                      // base alignment  // aligned offset
     float value;     // 4               // 0 
     vec3 vector;     // 16              // 16  (offset must be multiple of 16 so 4->16)
     mat4 matrix;     // 16              // 32  (column 0)
                      // 16              // 48  (column 1)
                      // 16              // 64  (column 2)
                      // 16              // 80  (column 3)
     float values[3]; // 16              // 96  (values[0])
                      // 16              // 112 (values[1])
                      // 16              // 128 (values[2])
     bool boolean;    // 4               // 144
     int integer;     // 4               // 148
 }; 
 </code></pre>
 
 <p>
   As an exercise, try to calculate the offset values yourself and compare them to this table. With these calculated offset values, based on the rules of the std140 layout, we can fill the buffer with data at the appropriate offsets using functions like <fun><function id='90'>glBufferSubData</function></fun>. While not the most efficient, the std140 layout does guarantee us that the memory layout remains the same over each program that declared this uniform block.
 </p>
 
 <p>
   By adding the statement <code>layout</code> <code>(std140)</code> in the definition of the uniform block we tell OpenGL that this uniform block uses the std140 layout. There are two other layouts to choose from that require us to query each offset before filling the buffers. We've already seen the <code>shared</code> layout, with the other remaining layout being <code>packed</code>. When using the <code>packed</code> layout, there is no guarantee that the layout remains the same between programs (not shared) because it allows the compiler to optimize uniform variables away from the uniform block which may differ per shader.
 </p>
 
 <h2>Using uniform buffers</h2>
 <p>
   We've defined uniform blocks and specified their memory layout, but we haven't discussed how to actually use them yet.
 </p>
 
 <p>
   First, we need to create a uniform buffer object which is done via the familiar <fun><function id='12'>glGenBuffers</function></fun>. Once we have a buffer object we bind it to the <var>GL_UNIFORM_BUFFER</var> target and allocate enough memory by calling <fun><function id='31'>glBufferData</function></fun>.
 </p>
 
 <pre><code>
 unsigned int uboExampleBlock;
 <function id='12'>glGenBuffers</function>(1, &uboExampleBlock);
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, uboExampleBlock);
 <function id='31'>glBufferData</function>(GL_UNIFORM_BUFFER, 152, NULL, GL_STATIC_DRAW); // allocate 152 bytes of memory
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, 0);
 </code></pre>
 
 <p>
   Now whenever we want to update or insert data into the buffer, we bind to <var>uboExampleBlock</var> and use <fun><function id='90'>glBufferSubData</function></fun> to update its memory. We only have to update this uniform buffer once, and all shaders that use this buffer now use its updated data. But, how does OpenGL know what uniform buffers correspond to which uniform blocks?
 </p>
 
 <p>
   In the OpenGL context there is a number of <def>binding points</def> defined where we can link a uniform buffer to. Once we created a uniform buffer we link it to one of those binding points and we also link the uniform block in the shader to the same binding point, effectively linking them together. The following diagram illustrates this:
 </p>
 
 <img src="/img/advanced/advanced_glsl_binding_points.png" class="clean" alt="Diagram of uniform binding points in OpenGL"/>
 
 <p>
   As you can see we can bind multiple uniform buffers to different binding points. Because shader A and shader B both have a uniform block linked to the same binding point <code>0</code>, their uniform blocks share the same uniform data found in <var>uboMatrices</var>; a requirement being that both shaders defined the same <var>Matrices</var> uniform block.
 </p>
 
 <p>
   To set a shader uniform block to a specific binding point we call <fun><function id='95'><function id='44'>glUniform</function>BlockBinding</function></fun> that takes a program object, a uniform block index, and the binding point to link to. The <def>uniform block index</def> is a location index of the defined uniform block in the shader. This can be retrieved via a call to <fun><function id='94'>glGetUniformBlockIndex</function></fun> that accepts a program object and the name of the uniform block. We can set the <var>Lights</var> uniform block from the diagram to binding point <code>2</code> as follows:
 </p>
 
 <pre><code>
 unsigned int lights_index = <function id='94'>glGetUniformBlockIndex</function>(shaderA.ID, "Lights");   
 <function id='95'><function id='44'>glUniform</function>BlockBinding</function>(shaderA.ID, lights_index, 2);
 </code></pre>
 
 <p>
   Note that we have to repeat this process for <strong>each</strong> shader.
 </p>
 
 <note>
   From OpenGL version 4.2 and onwards it is also possible to store the binding point of a uniform block explicitly in the shader by adding another layout specifier, saving us the calls to <fun><function id='94'>glGetUniformBlockIndex</function></fun> and <fun><function id='95'><function id='44'>glUniform</function>BlockBinding</function></fun>. The following code sets the binding point of the <var>Lights</var> uniform block explicitly:	
 <pre class="cpp"><code>
 layout(std140, binding = 2) uniform Lights { ... };
 </code></pre>  
 </note>
 
 <p>
   Then we also need to bind the uniform buffer object to the same binding point and this can be accomplished with either <fun><function id='96'><function id='32'>glBindBuffer</function>Base</function></fun> or <fun><function id='97'><function id='32'>glBindBuffer</function>Range</function></fun>.
 </p>
 
 <pre><code>
 <function id='96'><function id='32'>glBindBuffer</function>Base</function>(GL_UNIFORM_BUFFER, 2, uboExampleBlock); 
 // or
 <function id='97'><function id='32'>glBindBuffer</function>Range</function>(GL_UNIFORM_BUFFER, 2, uboExampleBlock, 0, 152);
 </code></pre>
 
 <p>
   The function <fun><function id='96'><function id='32'>glBindbuffer</function>Base</function></fun> expects a target, a binding point index and a uniform buffer object. This function links <var>uboExampleBlock</var> to binding point <code>2</code>; from this point on, both sides of the binding point are linked. You can also use <fun><function id='97'><function id='32'>glBindBuffer</function>Range</function></fun> that expects an extra offset and size parameter - this way you can bind only a specific range of the uniform buffer to a binding point. Using <fun><function id='97'><function id='32'>glBindBuffer</function>Range</function></fun> you could have multiple different uniform blocks linked to a single uniform buffer object.
 </p>
 
 <p>
   Now that everything is set up, we can start adding data to the uniform buffer. We could add all the data as a single byte array, or update parts of the buffer whenever we feel like it using  <fun><function id='90'>glBufferSubData</function></fun>. To update the uniform variable <var>boolean</var> we could update the uniform buffer object as follows:
 </p>
 
 <pre><code>
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, uboExampleBlock);
 int b = true; // bools in GLSL are represented as 4 bytes, so we store it in an integer
 <function id='90'>glBufferSubData</function>(GL_UNIFORM_BUFFER, 144, 4, &b); 
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, 0);
 </code></pre>
 
 <p>
   And the same procedure applies for all the other uniform variables inside the uniform block, but with different range arguments.
 </p>
 
 <h2>A simple example</h2>
 <p>
   So let's demonstrate a real example of uniform buffer objects. If we look back at all the previous code samples we've continually been using 3 matrices: the projection, view and model matrix. Of all those matrices, only the model matrix changes frequently. If we have multiple shaders that use this same set of matrices, we'd probably be better off using uniform buffer objects.
 </p>
 
 <p>
   We're going to store the projection and view matrix in a uniform block called <var>Matrices</var>. We're not going to store the model matrix in there since the model matrix tends to change frequently between shaders, so we wouldn't really benefit from uniform buffer objects.
 </p>
 
 <pre><code>
 #version 330 core
 layout (location = 0) in vec3 aPos;
 
 layout (std140) uniform Matrices
 {
     mat4 projection;
     mat4 view;
 };
 uniform mat4 model;
 
 void main()
 {
     gl_Position = projection * view * model * vec4(aPos, 1.0);
 }  
 </code></pre>
 
 <p>
   Not much going on here, except that we now use a uniform block with a std140 layout. What we're going to do in our sample application is display 4 cubes where each cube is displayed with a different shader program. Each of the 4 shader programs uses the same vertex shader, but has a unique fragment shader that only outputs a single color that differs per shader.
 </p>
 
 <p>
   First, we set the uniform block of the vertex shaders equal to binding point <code>0</code>. Note that we have to do this for each shader:
 </p>
 
 <pre><code>
 unsigned int uniformBlockIndexRed    = <function id='94'>glGetUniformBlockIndex</function>(shaderRed.ID, "Matrices");
 unsigned int uniformBlockIndexGreen  = <function id='94'>glGetUniformBlockIndex</function>(shaderGreen.ID, "Matrices");
 unsigned int uniformBlockIndexBlue   = <function id='94'>glGetUniformBlockIndex</function>(shaderBlue.ID, "Matrices");
 unsigned int uniformBlockIndexYellow = <function id='94'>glGetUniformBlockIndex</function>(shaderYellow.ID, "Matrices");  
   
 <function id='95'><function id='44'>glUniform</function>BlockBinding</function>(shaderRed.ID,    uniformBlockIndexRed, 0);
 <function id='95'><function id='44'>glUniform</function>BlockBinding</function>(shaderGreen.ID,  uniformBlockIndexGreen, 0);
 <function id='95'><function id='44'>glUniform</function>BlockBinding</function>(shaderBlue.ID,   uniformBlockIndexBlue, 0);
 <function id='95'><function id='44'>glUniform</function>BlockBinding</function>(shaderYellow.ID, uniformBlockIndexYellow, 0);
 </code></pre>
 
 <p>
   Next we create the actual uniform buffer object and bind that buffer to binding point <code>0</code>:
 </p>
 
 <pre><code>
 unsigned int uboMatrices
 <function id='12'>glGenBuffers</function>(1, &uboMatrices);
   
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, uboMatrices);
 <function id='31'>glBufferData</function>(GL_UNIFORM_BUFFER, 2 * sizeof(glm::mat4), NULL, GL_STATIC_DRAW);
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, 0);
   
 <function id='97'><function id='32'>glBindBuffer</function>Range</function>(GL_UNIFORM_BUFFER, 0, uboMatrices, 0, 2 * sizeof(glm::mat4));
 </code></pre>
 
 <p>
   First we allocate enough memory for our buffer which is equal to 2 times the size of <fun>glm::mat4</fun>. The size of GLM's matrix types correspond directly to <fun>mat4</fun> in GLSL. Then we link a specific range of the buffer, in this case the entire buffer, to binding point <code>0</code>.
 </p>
 
 <p>
   Now all that's left to do is fill the buffer. If we keep the <em>field of view</em> value constant of the projection matrix (so no more camera zoom) we only have to update it once in our application - this means we only have to insert this into the buffer only once as well. Because we already allocated enough memory in the buffer object we can use <fun><function id='90'>glBufferSubData</function></fun> to store the projection matrix before we enter the render loop:
 </p>
 
 <pre><code>
 glm::mat4 projection = <function id='58'>glm::perspective</function>(<function id='63'>glm::radians</function>(45.0f), (float)width/(float)height, 0.1f, 100.0f);
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, uboMatrices);
 <function id='90'>glBufferSubData</function>(GL_UNIFORM_BUFFER, 0, sizeof(glm::mat4), glm::value_ptr(projection));
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, 0);  
 </code></pre>
 
 <p>
   Here we store the first half of the uniform buffer with the projection matrix. Then before we render the objects each frame we update the second half of the buffer with the view matrix:
 </p>
 
 <pre><code>
 glm::mat4 view = camera.GetViewMatrix();	       
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, uboMatrices);
 <function id='90'>glBufferSubData</function>(GL_UNIFORM_BUFFER, sizeof(glm::mat4), sizeof(glm::mat4), glm::value_ptr(view));
 <function id='32'>glBindBuffer</function>(GL_UNIFORM_BUFFER, 0);  
 </code></pre>
 
 <p>
   And that's it for uniform buffer objects. Each vertex shader that contains a <var>Matrices</var> uniform block will now contain the data stored in <var>uboMatrices</var>. So if we now were to draw 4 cubes using 4 different shaders, their projection and view matrix should be the same:
 </p>
 
 <pre><code>
 <function id='27'>glBindVertexArray</function>(cubeVAO);
 shaderRed.use();
 glm::mat4 model = glm::mat4(1.0f);
 model = <function id='55'>glm::translate</function>(model, glm::vec3(-0.75f, 0.75f, 0.0f));	// move top-left
 shaderRed.setMat4("model", model);
 <function id='1'>glDrawArrays</function>(GL_TRIANGLES, 0, 36);        
 // ... draw Green Cube
 // ... draw Blue Cube
 // ... draw Yellow Cube	  
 </code></pre>
 
 <p>
   The only uniform we still need to set is the <var>model</var> uniform. Using uniform buffer objects in a scenario like this saves us from quite a few uniform calls per shader. The result looks something like this:
 </p>
 
 <img src="/img/advanced/advanced_glsl_uniform_buffer_objects.png" class="clean" alt="Image of 4 cubes with their uniforms set via OpenGL's uniform buffer objects"/>
 
 <p>
   Each of the cubes is moved to one side of the window by translating the model matrix and, thanks to the different fragment shaders, their colors differ per object. This is a relatively simple scenario of where we could use uniform buffer objects, but any large rendering application can have over hundreds of shader programs active which is where uniform buffer objects really start to shine.
 </p>
 
 <p>
   You can find the full source code of the uniform example application <a href="/code_viewer_gh.php?code=src/4.advanced_opengl/8.advanced_glsl_ubo/advanced_glsl_ubo.cpp" target="_blank">here</a>.
 </p>
 
 <p>
   Uniform buffer objects have several advantages over single uniforms. First, setting a lot of uniforms at once is faster than setting multiple uniforms one at a time. Second, if you want to change the same uniform over several shaders, it is much easier to change a uniform once in a uniform buffer. One last advantage that is not immediately apparent is that you can use a lot more uniforms in shaders using uniform buffer objects. OpenGL has a limit to how much uniform data it can handle which can be queried with <var>GL_MAX_VERTEX_UNIFORM_COMPONENTS</var>. When using uniform buffer objects, this limit is much higher. So whenever you reach a maximum number of uniforms (when doing skeletal animation for example) there's always uniform buffer objects.
 </p>       
 
     </div>