Strip comments and inline ids onto h*

64-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 Visible-Surface Determination</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 Visible-Surface Determination</title>
   <meta name="chapter" content="64" />
   <meta name="pages" content="1181-1185" />
-  <!--UNASSIGNED1//-->
-  <!--UNASSIGNED2//-->
 </head>
 
 <body>
@@ -37,23 +30,21 @@
 
   <p><br /></p>
 
-  <h3><a id="Heading4"></a>The Structure of Quake Levels</h3>
+  <h3 id="Heading4">The Structure of Quake Levels</h3>
 
   <p>Before diving into VSD, let me note that each Quake level is stored as a single huge 3-D BSP tree. This BSP tree, like any BSP, subdivides space, in this case along the planes of the polygons. However, unlike the BSP tree I presented in Chapter 62, Quake&rsquo;s BSP tree does not store polygons in the tree nodes, as part of the splitting planes, but rather in the empty (non-solid) leaves, as shown in overhead view in Figure 64.1.</p>
 
   <p>Correct drawing order can be obtained by drawing the leaves in front-to-back or back-to-front BSP order, again as discussed in Chapter 62. Also, because BSP leaves are always convex and the polygons are on the boundaries of the BSP leaves, facing inward, the polygons in a given leaf can never obscure one another and can be drawn in any order. (This is a general property of convex polyhedra.)</p>
 
-  <h3><a id="Heading5"></a>Culling and Visible Surface Determination</h3>
+  <h3 id="Heading5">Culling and Visible Surface Determination</h3>
 
   <p>The process of VSD would ideally work as follows: First, you would cull all polygons that are completely outside the view frustum (view pyramid), and would clip away the irrelevant portions of any polygons that are partially outside. Then, you would draw only those pixels of each polygon that are actually visible from the current viewpoint, as shown in overhead view in Figure 64.2, wasting no time overdrawing pixels multiple times; note how little of the polygon sets in Figure 64.2 actually need to be drawn. Finally, in a perfect world, the tests to figure out what parts of which polygons are visible would be free, and the processing time would be the same for all possible viewpoints, giving the game a smooth visual flow.</p>
 
-  <p><a id="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/64-01.jpg',406,226 )"> --><img src="images/64-01.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/64-01.jpg',406,226)"> --><b>Figure 64.1</b></a>&nbsp;&nbsp;<i>Quake&rsquo;s polygons are stored as empty leaves.</i></p>
+  <p><a id="Fig1"><img src="images/64-01.jpg" /><br />
+  <b>Figure 64.1</b></a>&nbsp;&nbsp;<i>Quake&rsquo;s polygons are stored as empty leaves.</i></p>
 
-  <p><a id="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/64-02.jpg',405,243 )"> --><img src="images/64-02.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/64-02.jpg',405,243)"> --><b>Figure 64.2</b></a>&nbsp;&nbsp;<i>Pixels visible from the current viewpoint.</i></p>
+  <p><a id="Fig2"><img src="images/64-02.jpg" /><br />
+  <b>Figure 64.2</b></a>&nbsp;&nbsp;<i>Pixels visible from the current viewpoint.</i></p>
 
   <p>As it happens, it is easy to determine which polygons are outside the frustum or partially clipped, and it&rsquo;s quite possible to figure out precisely which pixels need to be drawn. Alas, the world is far from perfect, and those tests are far from free, so the real trick is how to accelerate or skip various tests and still produce the desired result.</p>
 
@@ -61,19 +52,18 @@
 
   <p>For relatively simple worlds, it is perfectly acceptable. It doesn&rsquo;t scale very well, though. One problem is that as you add more polygons in the world, more transformations and tests have to be performed to cull polygons that aren&rsquo;t visible; at some point, that will bog considerably performance down.</p>
 
-  <h4 align="left"><a id="Heading6"></a>Nodes Inside and Outside the View Frustum</h4>
+  <h4 align="left" id="Heading6">Nodes Inside and Outside the View Frustum</h4>
 
   <p>Happily, there&rsquo;s a good workaround for this particular problem. As discussed earlier, each leaf of a BSP tree represents a convex subspace, with the nodes that bound the leaf delimiting the space. Perhaps less obvious is that each node in a BSP tree also describes a subspace&mdash;the subspace composed of all the node&rsquo;s children, as shown in Figure 64.3. Another way of thinking of this is that each node splits the subspace into two pieces created by the nodes above it in the tree, and the node&rsquo;s children then further carve that subspace into all the leaves that descend from the node.</p>
 
-  <p><a id="Fig3"><!-- </A><A HREF="javascript:displayWindow('images/64-03.jpg',410,214 )"> --><img src="images/64-03.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/64-03.jpg',410,214)"> --><b>Figure 64.3</b></a>&nbsp;&nbsp;<i>The substance described by node E.</i></p>
+  <p><a id="Fig3"><img src="images/64-03.jpg" /><br />
+  <b>Figure 64.3</b></a>&nbsp;&nbsp;<i>The substance described by node E.</i></p>
 
   <p>Since a node&rsquo;s subspace is bounded and convex, it is possible to test whether it is entirely outside the frustum. If it is, <i>all</i> of the node&rsquo;s children are certain to be fully clipped and can be rejected without any additional processing. Since most of the world is typically outside the frustum, many of the polygons in the world can be culled almost for free, in huge, node-subspace chunks. It&rsquo;s relatively expensive to perform a perfect test for subspace clipping, so instead bounding spheres or boxes are often maintained for each node, specifically for culling tests.</p>
 
   <p>So culling to the frustum isn&rsquo;t a problem, and the BSP can be used to draw back-to- front. What, then, <i>is</i> the problem?</p>
 
-  <h3><a id="Heading7"></a>Overdraw</h3>
+  <h3 id="Heading7">Overdraw</h3>
 
   <p>The problem John Carmack, the driving technical force behind DOOM and Quake, faced when he designed Quake was that in a complex world, many scenes have an awful lot of polygons in the frustum. Most of those polygons are partially or entirely obscured by other polygons, but the painter&rsquo;s algorithm described earlier requires that every pixel of every polygon in the frustum be drawn, often only to be overdrawn. In a 10,000-polygon Quake level, it would be easy to get a worst-case overdraw level of 10 times or more; that is, in some frames each pixel could be drawn 10 times or more, on average. No rasterizer is fast enough to compensate for an order of such magnitude and more work than is actually necessary to show a scene; worse still, the painter&rsquo;s algorithm will cause a vast difference between best-case and worst-case performance, so the frame rate can vary wildly as the viewer moves around.</p>
 
@@ -100,10 +90,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>