Strip comments and inline ids onto h*

66-02.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 Hidden-Surface Removal</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 Hidden-Surface Removal</title>
   <meta name="chapter" content="66" />
   <meta name="pages" content="1213-1217" />
-  <!--UNASSIGNED1//-->
-  <!--UNASSIGNED2//-->
 </head>
 
 <body>
@@ -51,15 +44,14 @@
 
   <p>And indeed there is.</p>
 
-  <h3><a id="Heading7"></a>Sorted Spans</h3>
+  <h3 id="Heading7">Sorted Spans</h3>
 
   <p>The ideal final HSR stage for Quake would reject all the polygons in the PVS that are actually invisible, and draw only the visible pixels of the remaining polygons, with no overdraw, that is, with every pixel drawn exactly once, all at no performance cost, of course. One way to do that (although certainly not at zero cost) would be to draw the polygons from front-to-back, maintaining a region describing the currently occluded portions of the screen and clipping each polygon to that region before drawing it. That sounds promising, but it is in fact nothing more or less than the beam tree approach I described in Chapter 64, an approach that we found to have considerable overhead and serious leveling problems.</p>
 
   <p>We can do much better if we move the final HSR stage from the polygon level to the span level and use a sorted-spans approach. In essence, this approach consists of turning each polygon into a set of spans, as shown in Figure 66.1, and then sorting and clipping the spans against each other until only the visible portions of visible spans are left to be drawn, as shown in Figure 66.2. This may sound a lot like z-buffering (which is simply too slow for use in drawing the world, although it&rsquo;s fine for smaller moving objects, as described earlier), but there are crucial differences.</p>
 
-  <p><a id="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/66-01.jpg',410,212 )"> --><img src="images/66-01.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/66-01.jpg',410,212)"> --><b>Figure 66.1</b></a>&nbsp;&nbsp;<i>Span generation.</i></p>
+  <p><a id="Fig1"><img src="images/66-01.jpg" /><br />
+  <b>Figure 66.1</b></a>&nbsp;&nbsp;<i>Span generation.</i></p>
 
   <p>By contrast with z-buffering, only visible portions of visible spans are scanned out pixel by pixel (although all polygon edges must still be rasterized). Better yet, the sorting that z-buffering does at each pixel becomes a per-span operation with sorted spans, and because of the coherence implicit in a span list, each edge is sorted only against some of the spans on the same line and is clipped only to the few spans that it overlaps horizontally. Although complex scenes still take longer to process than simple scenes, the worst case isn&rsquo;t as bad as with the beam tree or back-to-front approaches, because there&rsquo;s no overdraw or scanning of hidden pixels, because complexity is limited to pixel resolution and because span coherence tends to limit the worst-case sorting in any one area of the screen. As a bonus, the output of sorted spans is in precisely the form that a low-level rasterizer needs, a set of span descriptors, each consisting of a start coordinate and a length.</p>
 
@@ -67,15 +59,14 @@
 
   <p>So we&rsquo;ve found the approach we need; now it&rsquo;s just a matter of writing some code and we&rsquo;re on our way, right? Well, yes and no. Conceptually, the sorted-spans approach is simple, but it&rsquo;s surprisingly difficult to implement, with a couple of major design choices to be made, a subtle mathematical element, and some tricky gotchas that I&rsquo;ll have to defer until Chapter 67. Let&rsquo;s look at the design choices first.</p>
 
-  <h3><a id="Heading8"></a>Edges versus Spans</h3>
+  <h3 id="Heading8">Edges versus Spans</h3>
 
   <p>The first design choice is whether to sort spans or edges (both of which fall into the general category of &ldquo;sorted spans&rdquo;). Although the results are the same both ways, a list of spans to be drawn, with no overdraw, the implementations and performance implications are quite different, because the sorting and clipping are performed using very different data structures.</p>
 
   <p>With span-sorting, spans are stored in x-sorted, linked list buckets, typically with one bucket per scan line. Each polygon in turn is rasterized into spans, as shown in Figure 66.1, and each span is sorted and clipped into the bucket for the scan line the span is on, as shown in Figure 66.2, so that at any time each bucket contains the nearest spans encountered thus far, always with no overlap. This approach involves generating all spans for each polygon in turn, with each span immediately being sorted, clipped, and added to the appropriate bucket.</p>
 
-  <p><a id="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/66-02.jpg',405,518 )"> --><img src="images/66-02.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/66-02.jpg',405,518)"> --><b>Figure 66.2</b></a>&nbsp;&nbsp;<i>Two sets of spans sorted and clipped against one another.</i></p>
+  <p><a id="Fig2"><img src="images/66-02.jpg" /><br />
+  <b>Figure 66.2</b></a>&nbsp;&nbsp;<i>Two sets of spans sorted and clipped against one another.</i></p>
 
   <p>With edge-sorting, edges are stored in x-sorted, linked list buckets according to their start scan line. Each polygon in turn is decomposed into edges, cumulatively building a list of all the edges in the scene. Once all edges for all polygons in the view frustum have been added to the edge list, the whole list is scanned out in a single top-to-bottom, left-to-right pass. An active edge list (AEL) is maintained. With each step to a new scan line, edges that end on that scan line are removed from the AEL, active edges are stepped to their new x coordinates, edges starting on the new scan line are added to the AEL, and the edges are sorted by current x coordinate.</p>
 
@@ -96,10 +87,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>