Light-casters.html (29534B)
1 <h1 id="content-title">Light casters</h1> 2 <h1 id="content-url" style='display:none;'>Lighting/Light-casters</h1> 3 <p> 4 All the lighting we've used so far came from a single source that is a single point in space. It gives good results, but in the real world we have several types of light that each act different. A light source that <em>casts</em> light upon objects is called a <def>light caster</def>. In this chapter we'll discuss several different types of light casters. Learning to simulate different light sources is yet another tool in your toolbox to further enrich your environments. 5 </p> 6 7 <p> 8 We'll first discuss a directional light, then a point light which is an extension of what we had before, and lastly we'll discuss spotlights. In the <a href="https://learnopengl.com/Lighting/Multiple-lights" target="_blank">next</a> chapter we'll combine several of these different light types into one scene. 9 </p> 10 11 <h1>Directional Light</h1> 12 <p> 13 When a light source is far away the light rays coming from the light source are close to parallel to each other. It looks like all the light rays are coming from the same direction, regardless of where the object and/or the viewer is. When a light source is modeled to be <em>infinitely</em> far away it is called a <def>directional light</def> since all its light rays have the same direction; it is independent of the location of the light source. 14 </p> 15 16 <p> 17 A fine example of a directional light source is the sun as we know it. The sun is not infinitely far away from us, but it is so far away that we can perceive it as being infinitely far away in the lighting calculations. All the light rays from the sun are then modeled as parallel light rays as we can see in the following image: 18 </p> 19 20 <img src="/img/lighting/light_casters_directional.png" class="clean"/> 21 22 <p> 23 Because all the light rays are parallel it does not matter how each object relates to the light source's position since the light direction remains the same for each object in the scene. Because the light's direction vector stays the same, the lighting calculations will be similar for each object in the scene. 24 </p> 25 26 <p> 27 We can model such a directional light by defining a light direction vector instead of a position vector. The shader calculations remain mostly the same except this time we directly use the light's <var>direction</var> vector instead of calculating the <var>lightDir</var> vector using the light's <var>position</var> vector: 28 </p> 29 30 <pre><code> 31 struct Light { 32 // vec3 position; // no longer necessary when using directional lights. 33 vec3 direction; 34 35 vec3 ambient; 36 vec3 diffuse; 37 vec3 specular; 38 }; 39 [...] 40 void main() 41 { 42 vec3 lightDir = normalize(-light.direction); 43 [...] 44 } 45 </code></pre> 46 47 <p> 48 Note that we first negate the <var>light.direction</var> vector. The lighting calculations we used so far expect the light direction to be a direction from the fragment <strong>towards</strong> the light source, but people generally prefer to specify a directional light as a global direction pointing <strong>from</strong> the light source. Therefore we have to negate the global light direction vector to switch its direction; it's now a direction vector pointing towards the light source. Also, be sure to normalize the vector since it is unwise to assume the input vector to be a unit vector. 49 </p> 50 51 <p> 52 The resulting <var>lightDir</var> vector is then used as before in the diffuse and specular computations. 53 </p> 54 55 <p> 56 To clearly demonstrate that a directional light has the same effect on multiple objects we revisit the container party scene from the end of the <a href="https://learnopengl.com/Getting-started/Coordinate-Systems" target="_blank">Coordinate systems</a> chapter. In case you missed the party we defined 10 different <a href="/code_viewer.php?code=lighting/light_casters_container_positions" target="_blank">container positions</a> and generated a different model matrix per container where each model matrix contained the appropriate local-to-world transformations: 57 </p> 58 59 <pre><code> 60 for(unsigned int i = 0; i < 10; i++) 61 { 62 glm::mat4 model = glm::mat4(1.0f); 63 model = <function id='55'>glm::translate</function>(model, cubePositions[i]); 64 float angle = 20.0f * i; 65 model = <function id='57'>glm::rotate</function>(model, <function id='63'>glm::radians</function>(angle), glm::vec3(1.0f, 0.3f, 0.5f)); 66 lightingShader.setMat4("model", model); 67 68 <function id='1'>glDrawArrays</function>(GL_TRIANGLES, 0, 36); 69 } 70 </code></pre> 71 72 <p> 73 Also, don't forget to actually specify the direction of the light source (note that we define the direction as a direction <strong>from</strong> the light source; you can quickly see the light's direction is pointing downwards): 74 </p> 75 76 <pre><code> 77 lightingShader.setVec3("light.direction", -0.2f, -1.0f, -0.3f); 78 </code></pre> 79 80 <note> 81 <p> 82 We've been passing the light's position and direction vectors as <code>vec3</code>s for a while now, but some people tend to prefer to keep all the vectors defined as <code>vec4</code>. When defining position vectors as a <code>vec4</code> it is important to set the <code>w</code> component to <code>1.0</code> so translation and projections are properly applied. However, when defining a direction vector as a <code>vec4</code> we don't want translations to have an effect (since they just represent directions, nothing more) so then we define the <code>w</code> component to be <code>0.0</code>. 83 </p> 84 85 <p> 86 Direction vectors can then be represented as: <code>vec4(-0.2f, -1.0f, -0.3f, 0.0f)</code>. This can also function as an easy check for light types: you could check if the <code>w</code> component is equal to <code>1.0</code> to see that we now have a light's position vector and if <code>w</code> is equal to <code>0.0</code> we have a light's direction vector; so adjust the calculations based on that: 87 </p> 88 89 <pre><code> 90 if(lightVector.w == 0.0) // note: be careful for floating point errors 91 // do directional light calculations 92 else if(lightVector.w == 1.0) 93 // do light calculations using the light's position (as in previous chapters) 94 </code></pre> 95 96 <p> 97 Fun fact: this is actually how the old OpenGL (fixed-functionality) determined if a light source was a directional light or a positional light source and adjusted its lighting based on that. 98 </p> 99 </note> 100 101 <p> 102 If you'd now compile the application and fly through the scene it looks like there is a sun-like light source casting light on all the objects. Can you see that the diffuse and specular components all react as if there was a light source somewhere in the sky? It'll look something like this: 103 </p> 104 105 <img src="/img/lighting/light_casters_directional_light.png" class="clean"/> 106 107 <p> 108 You can find the full source code of the application <a href="/code_viewer_gh.php?code=src/2.lighting/5.1.light_casters_directional/light_casters_directional.cpp" target="_blank">here</a>. 109 </p> 110 111 <h1>Point lights</h1> 112 <p> 113 Directional lights are great for global lights that illuminate the entire scene, but we usually also want several <def>point lights</def> scattered throughout the scene. A point light is a light source with a given position somewhere in a world that illuminates in all directions, where the light rays fade out over distance. Think of light bulbs and torches as light casters that act as a point light. 114 </p> 115 116 <img src="/img/lighting/light_casters_point.png" class="clean"/> 117 118 <p> 119 In the earlier chapters we've been working with a simplistic point light. We had a light source at a given position that scatters light in all directions from that given light position. However, the light source we defined simulated light rays that never fade out thus making it look like the light source is extremely strong. In most 3D applications we'd like to simulate a light source that only illuminates an area close to the light source and not the entire scene. 120 </p> 121 122 <p> 123 If you'd add the 10 containers to the lighting scene from the previous chapters, you'd notice that the container all the way in the back is lit with the same intensity as the container in front of the light; there is no logic yet that diminishes light over distance. We want the container in the back to only be slightly lit in comparison to the containers close to the light source. 124 </p> 125 126 <h2>Attenuation</h2> 127 <p> 128 To reduce the intensity of light over the distance a light ray travels is generally called <def>attenuation</def>. One way to reduce the light intensity over distance is to simply use a linear equation. Such an equation would linearly reduce the light intensity over the distance thus making sure that objects at a distance are less bright. However, such a linear function tends to look a bit fake. In the real world, lights are generally quite bright standing close by, but the brightness of a light source diminishes quickly at a distance; the remaining light intensity then slowly diminishes over distance. We are thus in need of a different equation for reducing the light's intensity. 129 </p> 130 131 <p> 132 Luckily some smart people already figured this out for us. The following formula calculates an attenuation value based on a fragment's distance to the light source which we later multiply with the light's intensity vector: 133 </p> 134 135 \begin{equation} F_{att} = \frac{1.0}{K_c + K_l * d + K_q * d^2} \end{equation} 136 137 <p> 138 Here \(d\) represents the distance from the fragment to the light source. Then to calculate the attenuation value we define 3 (configurable) terms: a <def>constant</def> term \(K_c\), a <def>linear</def> term \(K_l\) and a <def>quadratic</def> term \(K_q\). 139 <ul> 140 <li>The constant term is usually kept at <code>1.0</code> which is mainly there to make sure the denominator never gets smaller than <code>1</code> since it would otherwise boost the intensity with certain distances, which is not the effect we're looking for.</li> 141 <li>The linear term is multiplied with the distance value that reduces the intensity in a linear fashion.</li> 142 <li>The quadratic term is multiplied with the quadrant of the distance and sets a quadratic decrease of intensity for the light source. The quadratic term will be less significant compared to the linear term when the distance is small, but gets much larger as the distance grows. </li> 143 </ul> 144 Due to the quadratic term the light will diminish mostly at a linear fashion until the distance becomes large enough for the quadratic term to surpass the linear term and then the light intensity will decrease a lot faster. The resulting effect is that the light is quite intense when at a close range, but quickly loses its brightness over distance until it eventually loses its brightness at a more slower pace. The following graph shows the effect such an attenuation has over a distance of <code>100</code>: 145 </p> 146 147 <img src="/img/lighting/attenuation.png" class="clean"/> 148 149 <p> 150 You can see that the light has the highest intensity when the distance is small, but as soon as the distance grows its intensity is significantly reduced and slowly reaches <code>0</code> intensity at around a distance of <code>100</code>. This is exactly what we want. 151 </p> 152 153 <h3>Choosing the right values</h3> 154 <p> 155 But at what values do we set those 3 terms? Setting the right values depend on many factors: the environment, the distance you want a light to cover, the type of light etc. In most cases, it simply is a question of experience and a moderate amount of tweaking. The following table shows some of the values these terms could take to simulate a realistic (sort of) light source that covers a specific radius (distance). The first column specifies the distance a light will cover with the given terms. These values are good starting points for most lights, with courtesy of <a href="http://www.ogre3d.org/tikiwiki/tiki-index.php?page=-Point+Light+Attenuation" target="_blank">Ogre3D's wiki</a>: 156 </p> 157 158 <table> 159 <tr> 160 <th>Distance</th> 161 <th>Constant</th> 162 <th>Linear</th> 163 <th>Quadratic</th> 164 </tr> 165 <tr> 166 <td><code>7</code></td> 167 <td><code>1.0</code></td> 168 <td><code>0.7</code></td> 169 <td><code>1.8</code></td> 170 </tr> 171 <tr> 172 <td><code>13</code></td> 173 <td><code>1.0</code></td> 174 <td><code>0.35</code></td> 175 <td><code>0.44</code></td> 176 </tr> 177 <tr> 178 <td><code>20</code></td> 179 <td><code>1.0</code></td> 180 <td><code>0.22</code></td> 181 <td><code>0.20</code></td> 182 </tr> 183 <tr> 184 <td><code>32</code></td> 185 <td><code>1.0</code></td> 186 <td><code>0.14</code></td> 187 <td><code>0.07</code></td> 188 </tr><tr> 189 <td><code>50</code></td> 190 <td><code>1.0</code></td> 191 <td><code>0.09</code></td> 192 <td><code>0.032</code></td> 193 </tr> 194 <tr> 195 <td><code>65</code></td> 196 <td><code>1.0</code></td> 197 <td><code>0.07</code></td> 198 <td><code>0.017</code></td> 199 </tr><tr> 200 <td><code>100</code></td> 201 <td><code>1.0</code></td> 202 <td><code>0.045</code></td> 203 <td><code>0.0075</code></td> 204 </tr><tr> 205 <td><code>160</code></td> 206 <td><code>1.0</code></td> 207 <td><code>0.027</code></td> 208 <td><code>0.0028</code></td> 209 </tr> 210 <tr> 211 <td><code>200</code></td> 212 <td><code>1.0</code></td> 213 <td><code>0.022</code></td> 214 <td><code>0.0019</code></td> 215 </tr><tr> 216 <td><code>325</code></td> 217 <td><code>1.0</code></td> 218 <td><code>0.014</code></td> 219 <td><code>0.0007</code></td> 220 </tr> 221 <tr> 222 <td><code>600</code></td> 223 <td><code>1.0</code></td> 224 <td><code>0.007</code></td> 225 <td><code>0.0002</code></td> 226 </tr> 227 <tr> 228 <td><code>3250</code></td> 229 <td><code>1.0</code></td> 230 <td><code>0.0014</code></td> 231 <td><code>0.000007</code></td> 232 </tr> 233 </table> 234 235 <p> 236 As you can see, the constant term \(K_c\) is kept at <code>1.0</code> in all cases. The linear term \(K_l\) is usually quite small to cover larger distances and the quadratic term \(K_q\) is even smaller. Try to experiment a bit with these values to see their effect in your implementation. In our environment a distance of <code>32</code> to <code>100</code> is generally enough for most lights. 237 </p> 238 239 <h3>Implementing attenuation</h3> 240 <p> 241 To implement attenuation we'll be needing 3 extra values in the fragment shader: namely the constant, linear and quadratic terms of the equation. These are best stored in the <fun>Light</fun> struct we defined earlier. Note that we need to calculate <var>lightDir</var> again using <var>position</var> as this is a point light (as we did in the previous chapter) and not a directional light. 242 </p> 243 244 <pre><code> 245 struct Light { 246 vec3 position; 247 248 vec3 ambient; 249 vec3 diffuse; 250 vec3 specular; 251 252 float constant; 253 float linear; 254 float quadratic; 255 }; 256 </code></pre> 257 258 <p> 259 Then we set the terms in our application: we want the light to cover a distance of <code>50</code> so we'll use the appropriate constant, linear and quadratic terms from the table: 260 </p> 261 262 <pre><code> 263 lightingShader.setFloat("light.constant", 1.0f); 264 lightingShader.setFloat("light.linear", 0.09f); 265 lightingShader.setFloat("light.quadratic", 0.032f); 266 </code></pre> 267 268 <p> 269 Implementing attenuation in the fragment shader is relatively straightforward: we simply calculate an attenuation value based on the equation and multiply this with the ambient, diffuse and specular components. 270 </p> 271 272 <p> 273 We do need the distance to the light source for the equation to work though. Remember how we can calculate the length of a vector? We can retrieve the distance term by calculating the difference vector between the fragment and the light source and take that resulting vector's length. We can use GLSL's built-in <fun>length</fun> function for that purpose: 274 </p> 275 276 <pre><code> 277 float distance = length(light.position - FragPos); 278 float attenuation = 1.0 / (light.constant + light.linear * distance + 279 light.quadratic * (distance * distance)); 280 </code></pre> 281 282 <p> 283 Then we include this attenuation value in the lighting calculations by multiplying the attenuation value with the ambient, diffuse and specular colors. 284 </p> 285 286 <note> 287 We could leave the ambient component alone so ambient lighting is not decreased over distance, but if we were to use more than 1 light source all the ambient components will start to stack up. In that case we want to attenuate ambient lighting as well. Simply play around with what's best for your environment. 288 </note> 289 290 <pre><code> 291 ambient *= attenuation; 292 diffuse *= attenuation; 293 specular *= attenuation; 294 </code></pre> 295 296 <p> 297 If you'd run the application you'd get something like this: 298 </p> 299 300 <img src="/img/lighting/light_casters_point_light.png" class="clean"/> 301 302 <p> 303 You can see that right now only the front containers are lit with the closest container being the brightest. The containers in the back are not lit at all since they're too far from the light source. You can find the source code of the application <a href="/code_viewer_gh.php?code=src/2.lighting/5.2.light_casters_point/light_casters_point.cpp" target="_blank">here</a>. 304 </p> 305 306 <p> 307 A point light is thus a light source with a configurable location and attenuation applied to its lighting calculations. Yet another type of light for our lighting arsenal. 308 </p> 309 310 <h1>Spotlight</h1> 311 <p> 312 The last type of light we're going to discuss is a <def>spotlight</def>. A spotlight is a light source that is located somewhere in the environment that, instead of shooting light rays in all directions, only shoots them in a specific direction. The result is that only the objects within a certain radius of the spotlight's direction are lit and everything else stays dark. A good example of a spotlight would be a street lamp or a flashlight. 313 </p> 314 315 <p> 316 A spotlight in OpenGL is represented by a world-space position, a direction and a <def>cutoff</def> angle that specifies the radius of the spotlight. For each fragment we calculate if the fragment is between the spotlight's cutoff directions (thus in its cone) and if so, we lit the fragment accordingly. The following image gives you an idea of how a spotlight works: 317 </p> 318 319 <img src="/img/lighting/light_casters_spotlight_angles.png" class="clean"/> 320 321 <p> 322 <ul> 323 <li><code>LightDir</code>: the vector pointing from the fragment to the light source.</li> 324 <li><code>SpotDir</code>: the direction the spotlight is aiming at.</li> 325 <li><code>Phi</code> \(\phi\): the cutoff angle that specifies the spotlight's radius. Everything outside this angle is not lit by the spotlight.</li> 326 <li><code>Theta</code> \(\theta\): the angle between the <var>LightDir</var> vector and the <var>SpotDir</var> vector. The \(\theta\) value should be smaller than \(\Phi\) to be inside the spotlight. </li> 327 </ul> 328 </p> 329 330 <p> 331 So what we basically need to do, is calculate the dot product (returns the cosine of the angle between two unit vectors) between the <var>LightDir</var> vector and the <var>SpotDir</var> vector and compare this with the cutoff angle \(\phi\). Now that you (sort of) understand what a spotlight is all about we're going to create one in the form of a flashlight. 332 </p> 333 334 <h2>Flashlight</h2> 335 <p> 336 A flashlight is a spotlight located at the viewer's position and usually aimed straight ahead from the player's perspective. A flashlight is basically a normal spotlight, but with its position and direction continually updated based on the player's position and orientation. 337 </p> 338 339 <p> 340 So, the values we're going to need for the fragment shader are the spotlight's position vector (to calculate the fragment-to-light's direction vector), the spotlight's direction vector and the cutoff angle. We can store these values in the <fun>Light</fun> struct: 341 </p> 342 343 <pre><code> 344 struct Light { 345 vec3 position; 346 vec3 direction; 347 float cutOff; 348 ... 349 }; 350 </code></pre> 351 352 <p> 353 Next we pass the appropriate values to the shader: 354 </p> 355 356 <pre><code> 357 lightingShader.setVec3("light.position", camera.Position); 358 lightingShader.setVec3("light.direction", camera.Front); 359 lightingShader.setFloat("light.cutOff", glm::cos(<function id='63'>glm::radians</function>(12.5f))); 360 </code></pre> 361 362 <p> 363 As you can see we're not setting an angle for the cutoff value but calculate the cosine value based on an angle and pass the cosine result to the fragment shader. The reason for this is that in the fragment shader we're calculating the dot product between the <code>LightDir</code> and the <code>SpotDir</code> vector and the dot product returns a cosine value and not an angle; and we can't directly compare an angle with a cosine value. To get the angle in the shader we then have to calculate the inverse cosine of the dot product's result which is an expensive operation. So to save some performance we calculate the cosine value of a given cutoff angle beforehand and pass this result to the fragment shader. Since both angles are now represented as cosines, we can directly compare between them without expensive operations. 364 </p> 365 366 <p> 367 Now what's left to do is calculate the theta \(\theta\) value and compare this with the cutoff \(\phi\) value to determine if we're in or outside the spotlight: 368 </p> 369 370 <pre><code> 371 float theta = dot(lightDir, normalize(-light.direction)); 372 373 if(theta > light.cutOff) 374 { 375 // do lighting calculations 376 } 377 else // else, use ambient light so scene isn't completely dark outside the spotlight. 378 color = vec4(light.ambient * vec3(texture(material.diffuse, TexCoords)), 1.0); 379 </code></pre> 380 381 <p> 382 We first calculate the dot product between the <var>lightDir</var> vector and the negated <var>direction</var> vector (negated, because we want the vectors to point towards the light source, instead of from). Be sure to normalize all the relevant vectors. 383 </p> 384 385 <note> 386 <p> 387 You may be wondering why there is a <code>></code> sign instead of a <code><</code> sign in the <code>if</code> guard. Shouldn't <var>theta</var> be smaller than the light's cutoff value to be inside the spotlight? That is right, but don't forget angle values are represented as cosine values and an angle of <code>0</code> degrees is represented as the cosine value of <code>1.0</code> while an angle of <code>90</code> degrees is represented as the cosine value of <code>0.0</code> as you can see here: 388 </p> 389 390 <img src="/img/lighting/light_casters_cos.png"/> 391 392 <p> 393 You can now see that the closer the cosine value is to <code>1.0</code> the smaller its angle. Now it makes sense why <var>theta</var> needs to be larger than the cutoff value. The cutoff value is currently set at the cosine of <code>12.5</code> which is equal to <code>0.976</code> so a cosine <var>theta</var> value between <code>0.976</code> and <code>1.0</code> would result in the fragment being lit as if inside the spotlight. 394 </p> 395 </note> 396 397 <p> 398 Running the application results in a spotlight that only lights the fragments that are directly inside the cone of the spotlight. It'll look something like this: 399 </p> 400 401 <img src="/img/lighting/light_casters_spotlight_hard.png" class="clean"/> 402 403 <p> 404 You can find the full source code <a href="/code_viewer_gh.php?code=src/2.lighting/5.3.light_casters_spot/light_casters_spot.cpp" target="_blank">here</a>. 405 </p> 406 407 <p> 408 It still looks a bit fake though, mostly because the spotlight has hard edges. Wherever a fragment reaches the edge of the spotlight's cone it is shut down completely instead of with a nice smooth fade. A realistic spotlight would reduce the light gradually around its edges. 409 </p> 410 411 <h2>Smooth/Soft edges</h2> 412 <p> 413 To create the effect of a smoothly-edged spotlight we want to simulate a spotlight having an <def>inner</def> and an <def>outer</def> cone. We can set the inner cone as the cone defined in the previous section, but we also want an outer cone that gradually dims the light from the inner to the edges of the outer cone. 414 </p> 415 416 <p> 417 To create an outer cone we simply define another cosine value that represents the angle between the spotlight's direction vector and the outer cone's vector (equal to its radius). Then, if a fragment is between the inner and the outer cone it should calculate an intensity value between <code>0.0</code> and <code>1.0</code>. If the fragment is inside the inner cone its intensity is equal to <code>1.0</code> and <code>0.0</code> if the fragment is outside the outer cone. 418 </p> 419 420 <p> 421 We can calculate such a value using the following equation: 422 423 \begin{equation} I = \frac{\theta - \gamma}{\epsilon} \end{equation} 424 425 Here \(\epsilon\) (epsilon) is the cosine difference between the inner (\(\phi\)) and the outer cone (\(\gamma\)) (\(\epsilon = \phi - \gamma\)). The resulting \(I\) value is then the intensity of the spotlight at the current fragment. 426 </p> 427 428 <p> 429 It is a bit hard to visualize how this formula actually works so let's try it out with a few sample values: 430 </p> 431 432 433 <table> 434 <tr> 435 <th>\(\theta\)</th> 436 <th>\(\theta\) in degrees</th> 437 <th>\(\phi\) (inner cutoff)</th> 438 <th>\(\phi\) in degrees</th> 439 <th>\(\gamma\) (outer cutoff)</th> 440 <th>\(\gamma\) in degrees</th> 441 <th>\(\epsilon\)</th> 442 <th>\(I\)</th> 443 </tr> 444 <tr> 445 <td><code>0.87</code></td> 446 <td><code>30</code></td> 447 <td><code>0.91</code></td> 448 <td><code>25</code></td> 449 <td><code>0.82</code></td> 450 <td><code>35</code></td> 451 <td><code>0.91 - 0.82 = 0.09</code></td> 452 <td><code>0.87 - 0.82 / 0.09 = 0.56</code></td> 453 </tr> 454 <tr> 455 <td><code>0.9</code></td> 456 <td><code>26</code></td> 457 <td><code>0.91</code></td> 458 <td><code>25</code></td> 459 <td><code>0.82</code></td> 460 <td><code>35</code></td> 461 <td><code>0.91 - 0.82 = 0.09</code></td> 462 <td><code>0.9 - 0.82 / 0.09 = 0.89</code></td> 463 </tr> 464 <tr> 465 <td><code>0.97</code></td> 466 <td><code>14</code></td> 467 <td><code>0.91</code></td> 468 <td><code>25</code></td> 469 <td><code>0.82</code></td> 470 <td><code>35</code></td> 471 <td><code>0.91 - 0.82 = 0.09</code></td> 472 <td><code>0.97 - 0.82 / 0.09 = 1.67</code></td> 473 </tr> 474 <tr> 475 <td><code>0.83</code></td> 476 <td><code>34</code></td> 477 <td><code>0.91</code></td> 478 <td><code>25</code></td> 479 <td><code>0.82</code></td> 480 <td><code>35</code></td> 481 <td><code>0.91 - 0.82 = 0.09</code></td> 482 <td><code>0.83 - 0.82 / 0.09 = 0.11</code></td> 483 </tr> 484 <tr> 485 <td><code>0.64</code></td> 486 <td><code>50</code></td> 487 <td><code>0.91</code></td> 488 <td><code>25</code></td> 489 <td><code>0.82</code></td> 490 <td><code>35</code></td> 491 <td><code>0.91 - 0.82 = 0.09</code></td> 492 <td><code>0.64 - 0.82 / 0.09 = -2.0</code></td> 493 </tr> 494 <tr> 495 <td><code>0.966</code></td> 496 <td><code>15</code></td> 497 <td><code>0.9978</code></td> 498 <td><code>12.5</code></td> 499 <td><code>0.953</code></td> 500 <td><code>17.5</code></td> 501 <td><code>0.9978 - 0.953 = 0.0448</code></td> 502 <td><code>0.966 - 0.953 / 0.0448 = 0.29</code></td> 503 </tr> 504 </table> 505 506 <p> 507 As you can see we're basically interpolating between the outer cosine and the inner cosine based on the \(\theta\) value. If you still don't really see what's going on, don't worry, you can simply take the formula for granted and return here when you're much older and wiser. 508 </p> 509 510 <p> 511 We now have an intensity value that is either negative when outside the spotlight, higher than <code>1.0</code> when inside the inner cone, and somewhere in between around the edges. If we properly clamp the values we don't need an <code>if-else</code> in the fragment shader anymore and we can simply multiply the light components with the calculated intensity value: 512 </p> 513 514 <pre><code> 515 float theta = dot(lightDir, normalize(-light.direction)); 516 float epsilon = light.cutOff - light.outerCutOff; 517 float intensity = clamp((theta - light.outerCutOff) / epsilon, 0.0, 1.0); 518 ... 519 // we'll leave ambient unaffected so we always have a little light. 520 diffuse *= intensity; 521 specular *= intensity; 522 ... 523 </code></pre> 524 525 <p> 526 Note that we use the <fun>clamp</fun> function that <def>clamps</def> its first argument between the values <code>0.0</code> and <code>1.0</code>. This makes sure the intensity values won't end up outside the [<code>0</code>, <code>1</code>] range. 527 </p> 528 529 <p> 530 Make sure you add the <var>outerCutOff</var> value to the <fun>Light</fun> struct and set its uniform value in the application. For the following image an inner cutoff angle of <code>12.5</code> and an outer cutoff angle of <code>17.5</code> was used: 531 </p> 532 533 <img src="/img/lighting/light_casters_spotlight.png" class="clean"/> 534 535 <p> 536 Ahhh, that's much better. Play around with the inner and outer cutoff angles and try to create a spotlight that better suits your needs. You can find the source code of the application <a href="/code_viewer_gh.php?code=src/2.lighting/5.4.light_casters_spot_soft/light_casters_spot_soft.cpp" target="_blank">here</a>. 537 </p> 538 539 <p> 540 Such a flashlight/spotlight type of lamp is perfect for horror games and combined with directional and point lights the environment will really start to light up. 541 </p> 542 543 <h2>Exercises</h2> 544 <ul> 545 <li>Try experimenting with all the different light types and their fragment shaders. Try inverting some vectors and/or use < instead of >. Try to explain the different visual outcomes.</li> 546 </ul> 547 548 </div> 549