Strip comments and inline ids onto h*

59-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: The Idea of BSP Trees</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: The Idea of BSP Trees</title>
   <meta name="chapter" content="59" />
   <meta name="pages" content="1099-1102" />
-  <!--UNASSIGNED1//-->
-  <!--UNASSIGNED2//-->
 </head>
 
 <body>
@@ -41,11 +34,10 @@
 
   <p>It&rsquo;s hard to get cheaper sorting than linear time, and BSP-based rendering stacks up well against alternatives such as z-buffering, octrees, z-scan sorting, and polygon sorting. Better yet, a scene database represented as a BSP tree can be clipped to the view pyramid very efficiently; huge chunks of a BSP tree can be lopped off when clipping to the view pyramid, because if the entire area or volume of a node lies entirely outside the view volume, then <i>all</i> nodes and leaves that are children of that node must likewise be outside the view volume, for reasons that will become clear as we delve into the workings of BSP trees.</p>
 
-  <p><a id="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/59-01.jpg',408,212 )"> --><img src="images/59-01.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/59-01.jpg',408,212)"> --><b>Figure 59.1</b></a>&nbsp;&nbsp;<i>The painter&rsquo;s algorithm.</i></p>
+  <p><a id="Fig1"><img src="images/59-01.jpg" /><br />
+  <b>Figure 59.1</b></a>&nbsp;&nbsp;<i>The painter&rsquo;s algorithm.</i></p>
 
-  <h4 align="left"><a id="Heading5"></a>Limitations of BSP Trees</h4>
+  <h4 align="left" id="Heading5">Limitations of BSP Trees</h4>
 
   <p>Powerful as they are, BSP trees aren&rsquo;t perfect. By far the greatest limitation of BSP trees is that they&rsquo;re time-consuming to build, enough so that, for all practical purposes, BSP trees must be precalculated, and cannot be built dynamically at runtime. In fact, a BSP-tree compiler that attempts to perform some optimization (limiting the number of surfaces that need to be split, for example) can easily take minutes or even hours to process large world databases.</p>
 
@@ -57,7 +49,7 @@
 
   <p>The only other drawbacks of BSP trees that I know of are the memory required to store the tree, which amounts to a few pointers per node, and the relative complexity of debugging BSP-tree compilation and usage; debugging a large data set being processed by recursive code (which BSP code tends to be) can be quite a challenge. Tools like the BSP compiler I&rsquo;ll present in the next chapter, which visually depicts the process of spatial subdivision as a BSP tree is constructed, help a great deal with BSP debugging.</p>
 
-  <h3><a id="Heading6"></a>Building a BSP Tree</h3>
+  <h3 id="Heading6">Building a BSP Tree</h3>
 
   <p>Now that we know a good bit about what a BSP tree is, how it helps in visible surface determination, and what its strengths and weaknesses are, let&rsquo;s take a look at how a BSP tree actually works to provide front-to-back or back-to-front ordering. This chapter&rsquo;s discussion will be at a conceptual level, with plenty of figures; in the next chapter we&rsquo;ll get into mechanisms and implementation details.</p>
 
@@ -65,9 +57,8 @@
 
   <p>First, let&rsquo;s construct a simple BSP tree. Figure 59.2 shows a set of four lines that will constitute our sample world. I&rsquo;ll refer to these as walls, because that&rsquo;s one easily-visualized context in which a 2-D BSP tree would be useful in a game. Think of Figure 59.2 as depicting vertical walls viewed from directly above, so they&rsquo;re lines for the purpose of the BSP tree. Note that each wall has a front side, denoted by a normal (perpendicular) vector, and a back side. To make a BSP tree for this sample set, we need to split the world in two, then each part into two again, and so on, until each wall resides in its own unique subspace. An obvious question, then, is how should we carve up the world of Figure 59.2?</p>
 
-  <p><a id="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/59-02.jpg',410,113 )"> --><img src="images/59-02.jpg" /><br />
-  <!-- </A>
-<BR><A HREF="javascript:displayWindow('images/59-02.jpg',410,113)"> --><b>Figure 59.2</b></a>&nbsp;&nbsp;<i>A sample set of walls, viewed from above.</i></p>
+  <p><a id="Fig2"><img src="images/59-02.jpg" /><br />
+  <b>Figure 59.2</b></a>&nbsp;&nbsp;<i>A sample set of walls, viewed from above.</i></p>
 
   <p>There are infinitely valid ways to carve up Figure 59.2, but the simplest is just to carve along the lines of the walls themselves, with each node containing one wall. This is not necessarily optimal, in the sense of producing the smallest tree, but it has the virtue of generating the splitting lines without expensive analysis. It also saves on data storage, because the data for the walls can do double duty in describing the splitting lines as well. (Putting one wall on each splitting line doesn&rsquo;t actually create a unique subspace for each wall, but it does create a unique subspace <i>boundary</i> for each wall; as we&rsquo;ll see, that spatial organization provides for the same unambiguous visibility ordering as a unique subspace would.)</p>
 
@@ -88,10 +79,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>