Strip comments and inline ids onto h*

68-01.html

@@ -10,16 +10,9 @@
   <meta name="vspubdate" content="07/01/97" />
   <meta name="vscategory" content="Web and Software Development: Game Development,Web and Software Development: Graphics and Multimedia Development" />
 
-  <title>Michael Abrash's Graphics Programming Black Book Special Edition: Quake's Lighting Model</title><!-- HEADER -->
-  <!-- Empty Reference Subhead -->
-  <!--ISBN=1576101746//-->
-  <!--TITLE=Michael Abrash's Graphics Programming Black Book Special Edition//-->
-  <!--AUTHOR=Michael Abrash//-->
-  <!--PUBLISHER=The Coriolis Group, Inc.//-->
+  <title>Michael Abrash's Graphics Programming Black Book Special Edition: Quake's Lighting Model</title>
   <meta name="chapter" content="68" />
   <meta name="pages" content="1243-1247" />
-  <!--UNASSIGNED1//-->
-  <!--UNASSIGNED2//-->
 </head>
 
 <body>
@@ -37,10 +30,10 @@
 
   <p><br /></p>
 
-  <h2><a id="Heading1"></a>Chapter 68<br />
+  <h2 id="Heading1">Chapter 68<br />
   Quake&rsquo;s Lighting Model</h2>
 
-  <h3><a id="Heading2"></a>A Radically Different Approach to Lighting Polygons</h3>
+  <h3 id="Heading2">A Radically Different Approach to Lighting Polygons</h3>
 
   <p>It was during my senior year in college that I discovered computer games. Not Wizardry, or Choplifter, or Ultima, because none of those existed yet&mdash;the game that hooked me was the original Star Trek game, in which you navigated from one 8x8 quadrant to another in search of starbases, occasionally firing phasers or photon torpedoes. This was less exciting than it sounds; after each move, the current quadrant had to be reprinted from scratch, along with the current stats&mdash;and the output device was a 10 cps printball console. A typical game took over an hour, during which nothing particularly stimulating ever happened (Klingons appeared periodically, but they politely waited for your next move before attacking, and your photon torpedoes never missed, so the outcome was never in doubt), but none of that mattered; nothing could detract from the sheer thrill of being in a computer-simulated universe.</p>
 
@@ -50,13 +43,13 @@
 
   <p>It&rsquo;s important to keep it that way. I&rsquo;ve seen far too many people start to treat programming like a job, forgetting the joy of doing it, and burn out. So keep an eye on how you feel about the programming you&rsquo;re doing, and if it&rsquo;s getting stale, it&rsquo;s time to learn something new; there&rsquo;s plenty of interesting programming of all sorts to be done. Follow your interests&mdash;and don&rsquo;t forget to have fun!</p>
 
-  <h3><a id="Heading3"></a>The Lighting Conundrum</h3>
+  <h3 id="Heading3">The Lighting Conundrum</h3>
 
   <p>I spent about two years working with John Carmack on Quake&rsquo;s 3-D graphics engine. John faced several fundamental design issues while architecting Quake. I&rsquo;ve written in earlier chapters about some of those issues, including eliminating non-visible polygons quickly via a precalculated potentially visible set (PVS), and improving performance by inserting potentially visible polygons into a global edge list and scanning out only the nearest polygon at each pixel.</p>
 
   <p>In this chapter, I&rsquo;m going to talk about another, equally crucial design issue: how we developed our lighting approach for the part of the Quake engine that draws the world itself, the static walls and floors and ceilings. Monsters and players are drawn using completely different rendering code, with speed the overriding factor. A primary goal for the world, on the other hand, was to be as precise as possible, getting everything right so that polygons, textures, and sophisticated lighting would be pegged in place, with no visible shifting or distortion under all viewing conditions, for maximum player immersion&mdash;all with good performance, of course. As I&rsquo;ll discuss, the twin goals of performance and rock-solid, complex lighting proved to be difficult to achieve with traditional lighting approaches; ultimately, a dramatically different approach was required.</p>
 
-  <h3><a id="Heading4"></a>Gouraud Shading</h3>
+  <h3 id="Heading4">Gouraud Shading</h3>
 
   <p>The traditional way to do realistic lighting in polygon pipelines is Gouraud shading (also known as <i>smooth shading</i>). Gouraud shading involves generating a lighting value at each polygon vertex by applying all relevant world lighting, linearly interpolating between lighting values down the edges of the polygon, and then linearly interpolating between the edges of the polygon across each span. If texture mapping is desired (and all polygons are texture mapped in Quake), then at each pixel in each span, the pixel&rsquo;s corresponding texture map location (texel) is determined, and the interpolated lighting is applied to the texel to generate a final, lit pixel. Texels are generally taken from a 32x32 or 64x64 texture that&rsquo;s tiled repeatedly across the polygon, for several reasons: performance (a 64x64 texture sits nicely in the 486 or Pentium cache), database size, and less artwork.</p>
 
@@ -64,7 +57,7 @@
 
   <p>Gouraud shading allows for decent lighting effects with a relatively small amount of calculation and a compact data set that&rsquo;s a simple extension of the basic polygon model. However, there are several important drawbacks to Gouraud shading, as well.</p>
 
-  <h4 align="left"><a id="Heading5"></a>Problems with Gouraud Shading</h4>
+  <h4 align="left" id="Heading5">Problems with Gouraud Shading</h4>
 
   <p>The quality of Gouraud shading depends heavily on the average size of the polygons being drawn. Linear interpolation is used, so highlights can only occur at vertices, and color gradients are monotonic across the face of each polygon. This can make for bland lighting effects if polygons are large, and makes it difficult to do spotlights and other detailed or dramatic lighting effects. After John brought the initial, primitive Quake engine up using Gouraud shading for lighting, the first thing he tried to improve lighting quality was adding a single vertex and creating new polygons wherever a spotlight was directly overhead a polygon, with the new vertex added directly underneath the light, as shown in Figure 68.1. This produced fairly attractive highlights, but simultaneously made evident several problems.</p>
 
@@ -85,10 +78,6 @@
 
   <div align="center">
     Graphics Programming Black Book &copy; 2001 Michael Abrash
-  </div><!-- all of the reference materials (books) have the footer and subfoot reveresed -->
-  <!-- reference_subfoot = footer -->
-  <!-- reference_footer = subfoot -->
-  <!-- BEGIN SUB FOOTER -->
-  <!-- END FOOTER -->
+  </div>
 </body>
 </html>