Jason McKesson avatar Jason McKesson committed ed68323

Corrections to tutorial docs.

Comments (0)

Files changed (2)

Documents/Illumination/Tutorial 12.xml

     </section>
     <section>
         <?dbhtml filename="Tut12 Monitors and Gamma.html" ?>
-        <title>Monitors and Gamma</title>
+        <title>Linearity and Gamma</title>
         <para>There is one major issue left, and it is one that has been glossed over since the
             beginning of our look at lighting: your screen.</para>
-        <para>The fundamental assumption underlying all of our lighting equations is the idea that
-            the surface colors and light intensities are all in a linear
+        <para>The fundamental assumption underlying all of our lighting equations since the very
+            beginning is the idea that the surface colors and light intensities are all in a linear
                 <glossterm>colorspace</glossterm>. A colorspace defines how we translate from a set
             of numerical values to actual, real colors that you can see. A colorspace is a
                 <glossterm>linear colorspace</glossterm> if doubling any value in that colorspace
             we multiplied the sun and ambient intensities by 3 in the last section, we were
             increasing the brightness by 3x. Multiplying the maximum intensity by 3 had the effect
             of reducing the overall brightness by 3x.</para>
-        <para>There's just one problem. Your screen doesn't work that way. Time for a short history
+        <para>There's just one problem: tour screen doesn't work that way. Time for a short history
             of television/monitors.</para>
         <para>The original televisions used an electron gun fired at a phosphor surface to generate
             light and images; this is called a <acronym>CRT</acronym> display (cathode ray tube).
             image.</para>
         <para>The easiest way to deal with that in the earliest days of TV was to simply modify the
             incoming image at the source. TV broadcasts sent image data that was non-linear in the
-            opposite direction of the CRT's normal non-linearity. This resulted in a color
-            reproduction in a linear colorspace.</para>
+            opposite direction of the CRT's normal non-linearity. Thus, the final output was
+            displayed linearly, as it was originally captured by the camera.</para>
         <para>The term for this process, de-linearizing an image to compensate for a non-linear
-            display, is <glossterm>gamma correction</glossterm>.</para>
+            display, is called <glossterm>gamma correction</glossterm>.</para>
         <para>You may be wondering why this matters. After all, odds are, you don't have a CRT-based
             monitor; you probably have some form of LCD, plasma, LED, or similar technology. So what
             does the vagaries of CRT monitors matter to you?</para>
             monitor's gamma-correction circuitry has been mangling.</para>
         <section>
             <title>Gamma Functions</title>
-            <para>A <glossterm>gamma function</glossterm> is the function mapping linear RGB space
+            <para>A <glossterm>gamma function</glossterm> is the function that maps linear RGB space
                 to non-linear RGB space. The gamma function for CRT displays was fairly standard,
                 and all non-CRT displays mimic this standard. It is ultimately based on a math
                 function of CRT displays. The strength of the electron beam is controlled by the
 };</programlisting>
             </example>
             <para>For the sake of clarity in this tutorial, we send the actual gamma value. For
-                performance's sake, we should send 1/gamma, so that we don't have to do it in every
-                fragment.</para>
+                performance's sake, we ought send 1/gamma, so that we don't have to needlessly do a
+                division in every fragment.</para>
             <para>The gamma is applied in the fragment shader as follows:</para>
             <example>
                 <title>Fragment Gamma Correction</title>
 outputColor = pow(accumLighting, gamma);</programlisting>
             </example>
             <para>Otherwise, the code is mostly unchanged from the HDR tutorial. Speaking of which,
-                gamma correction does not require HDR per se, but both are necessary for quality
-                lighting results.</para>
+                gamma correction does not require HDR per se, nor does HDR require gamma correction.
+                However, the combination of the two has the power to create substantial improvements
+                in overall visual quality.</para>
+            <para>One final change in the code is for light values that are written directly,
+                without any lighting computations. The background color is simply the clear color
+                for the framebuffer. Even so, it needs gamma correction too; this is done on the CPU
+                by gamma correcting the color before drawing it. If you have any other colors that
+                are drawn directly, <emphasis>do not</emphasis> forget to do this.</para>
         </section>
         <section>
             <title>Gamma Correct Lighting</title>
-            <para>This is what happens when you apply HDR lighting to a scene who's light properties
-                were defined <emphasis>without</emphasis> gamma correction. Look at the scene at
-                night; the point lights are extremely bright, and their lighting effects seem to go
-                farther than before. This last point bears investigating.</para>
+            <para>What we have seen is what happens when you apply HDR lighting to a scene who's
+                light properties were defined <emphasis>without</emphasis> gamma correction. Look at
+                the scene at night; the point lights are extremely bright, and their lighting
+                effects seem to go much farther than before. This last point bears
+                investigating.</para>
             <para>When we first talked about light attenuation, we said that the correct attenuation
                 function for a point light was an inverse-square relationship with respect to the
                 distance to the light. We also said that this usually looked wrong, so people often
             <para>Gamma is the reason for this. Or rather, lack of gamma correction is the reason.
                 Without correcting for the display's gamma function, the attenuation of <inlineequation>
                     <mathphrase>1/r<superscript>2</superscript></mathphrase>
-                </inlineequation> becomes <inlineequation>
+                </inlineequation> effectively becomes <inlineequation>
                     <mathphrase>(1/r<superscript>2</superscript>)<superscript>2.2</superscript></mathphrase>
                 </inlineequation>, which is <inlineequation>
                     <mathphrase>1/r<superscript>4.4</superscript></mathphrase>
                 attenuation of lights. A simple <inlineequation>
                     <mathphrase>1/r</mathphrase>
                 </inlineequation> relationship looks better without gamma correction because the
-                display's gamma function turns it into something that is much closer to being
-                physically correct: <inlineequation>
+                display's gamma function turns it into something that is much closer to being in a
+                linear colorspace: <inlineequation>
                     <mathphrase>1/r<superscript>2.2</superscript></mathphrase>
                 </inlineequation>.</para>
-            <para>Since this lighting was not designed while looking at gamma correct results, let's
-                look at some scene lighting that was developed that way. Turn on gamma correction
-                and set the gamma value to 2.2 (the default if you did not change it). The press <keycombo>
+            <para>Since this lighting environment was not designed while looking at gamma correct
+                results, let's look at some scene lighting that was developed that way. Turn on
+                gamma correction and set the gamma value to 2.2 (the default if you did not change
+                it). The press <keycombo>
                     <keycap>Shift</keycap>
                     <keycap>L</keycap>
                 </keycombo>:</para>
             <para>If there is one point you should learn from this exercise, it is this: make sure
                 that you implement gamma correction and HDR <emphasis>before</emphasis> trying to
                 light your scenes. If you don't, then you may have to adjust all of the lighting
-                parameters again. In this case, it wasn't even possible to use simple math to make
-                the lighting work right. This lighting environment was developed from
+                parameters again, and you may need to change materials as well. In this case, it
+                wasn't even possible to use simple corrective math on the lighting environment to
+                make it work right. This lighting environment was developed essentially from
                 scratch.</para>
             <para>One thing we can notice when looking at the gamma correct lighting is that proper
                 gamma correction improves shadow details substantially:</para>
                     </imageobject>
                 </mediaobject>
             </figure>
-            <para>These two images use HDR lighting; the one on the left doesn't have gamma
+            <para>These two images use the HDR lighting; the one on the left doesn't have gamma
                 correction, and the one on the right does. Notice how easy it is to make out the
                 details in the hills near the triangle on the right.</para>
             <para>Looking at the gamma function, this makes sense. Without proper gamma correction,
                 fully half of the linearRGB range is shoved into the bottom one-fifth of the
-                available light intensity. That doesn't leave much room for areas that are dark, but
+                available light intensity. That doesn't leave much room for areas that are dark but
                 not too dark to see anything.</para>
             <para>As such, gamma correction is a key process for producing color-accurate rendered
                 images.</para>

Documents/Illumination/Tutorial 13.xml

             <para>Computing the position is also easy. The position of a point on the surface of a
                 sphere is the normal at that position scaled by the radius and offset by the center
                 point of the sphere.</para>
+            <para>One final thing. Notice the square-root at the end, being applied to our
+                accumulated lighting. This effectively simulates a gamma of 2.0, but without the
+                expensive <function>pow</function> function call. A <function>sqrt</function> call
+                is much less expensive and far more likely to be directly built into the shader
+                hardware. Yes, this is not entirely accurate, since most displays simulate the 2.2
+                gamma of CRT displays. But it's a lot less inaccurate than applying no correction at
+                all. We'll discuss a much cheaper way to apply proper gamma correction in future
+                tutorials.</para>
         </section>
     </section>
     <section>
         <?dbhtml filename="Tut13 Correct Chicanery.html" ?>
         <title>Correct Chicanery</title>
-        <para>Our perfect sphere looks pretty nice. However, it is unfortunately very wrong.</para>
+        <para>Our perfect sphere looks pretty nice. It has no polygonal outlines and you can zoom in
+            on it forever. However, it is unfortunately very wrong.</para>
         <para>To see how, toggle back to rendering the mesh on sphere <keycap>1</keycap> (the
             central blue one). Then move the camera so that the sphere is at the left edge of the
             screen. Then toggle back to impostor rendering.</para>
                 </imageobject>
             </mediaobject>
         </figure>
-        <para>The line through the circle represents the square we drew. When viewing the sphere off
-            to the side like this, we shouldn't be able to see the left-edge of the sphere facing
-            perpendicular to the camera. And we should see some of the sphere on the right that is
-            behind the plane.</para>
+        <para>The dark line through the circle represents the square we drew. When viewing the
+            sphere off to the side like this, we shouldn't be able to see the left-edge of the
+            sphere facing perpendicular to the camera. And we should see some of the sphere on the
+            right that is behind the plane.</para>
         <para>So how do we solve this?</para>
         <para>Use better math. Our last algorithm is a decent approximation if the spheres are
             somewhat small. But if the spheres are reasonably large (which also can mean close to
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.