Misc/abrash-black-book
Watch
1
0
Fork
You've already forked abrash-black-book
 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Retidy, removing align=left from headings and empty paragraphs

Browse source
This commit is contained in:
James Gregory 2013-12-30 15:37:13 +11:00
commit a96a114403
362 changed files with 8472 additions and 5040 deletions
Download patch file Download diff file Expand all files Collapse all files

41
64-03.html
View file

@ -1,5 +1,4 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
@ -19,17 +18,21 @@
<center>
<table border="1">
<tr>
<td><a href="64-02.html">Previous</a></td>
<td>
<a href="64-02.html">Previous</a>
</td>
<td><a href="index.html">Table of Contents</a></td>
<td>
<a href="index.html">Table of Contents</a>
</td>
<td><a href="64-04.html">Next</a></td>
<td>
<a href="64-04.html">Next</a>
</td>
</tr>
</table>
</center>
<p><br /></p>
<h3 id="Heading8">The Beam Tree</h3>
<p>John&rsquo;s original Quake design was to draw front-to-back, using a second BSP tree to keep track of what parts of the screen were already drawn and which were still empty and therefore drawable by the remaining polygons. Logically, you can think of this BSP tree as being a 2-D region describing solid and empty areas of the screen, as shown in Figure 64.4, but in fact it is a 3-D tree, of the sort known as a <i>beam tree.</i> A beam tree is a collection of 3-D wedges (beams), bounded by planes, projecting out from some center point, in this case the viewpoint, as shown in Figure 64.5.</p>
@ -50,23 +53,23 @@
<p>Once the beam tree was working, John relentlessly worked at speeding up the 3-D engine, always trying to improve the design, rather than tweaking the implementation. At least once a week, and often every day, he would walk into my office and say &ldquo;Last night I couldn&rsquo;t get to sleep, so I was thinking...&rdquo; and I&rsquo;d know that I was about to get my mind stretched yet again. John tried many ways to improve the beam tree, with some success, but more interesting was the profusion of wildly different approaches that he generated, some of which were merely discussed, others of which were implemented in overnight or weekend-long bursts of coding, in both cases ultimately discarded or further evolved when they turned out not to meet the design criteria well enough. Here are some of those approaches, presented in minimal detail in the hopes that, like Tom Wilson with the Paradise FIFO, your imagination will be sparked.</p>
<h4 align="left" id="Heading10">Subdividing Raycast</h4>
<h4 id="Heading10">Subdividing Raycast</h4>
<p>Rays are cast in an 8x8 screen-pixel grid; this is a highly efficient operation because the first intersection with a surface can be found by simply clipping the ray into the BSP tree, starting at the viewpoint, until a solid leaf is reached. If adjacent rays don&rsquo;t hit the same surface, then a ray is cast halfway between, and so on until all adjacent rays either hit the same surface or are on adjacent pixels; then the block around each ray is drawn from the polygon that was hit. This scales very well, being limited by the number of pixels, with no overdraw. The problem is dropouts; it&rsquo;s quite possible for small polygons to fall between rays and vanish.</p>
<h4 align="left" id="Heading11">Vertex-Free Surfaces</h4>
<h4 id="Heading11">Vertex-Free Surfaces</h4>
<p>The world is represented by a set of surface planes. The polygons are implicit in the plane intersections, and are extracted from the planes as a final step before drawing. This makes for fast clipping and a very small data set (planes are far more compact than polygons), but it&rsquo;s time-consuming to extract polygons from planes.</p>
<h4 align="left" id="Heading12">The Draw-Buffer</h4>
<h4 id="Heading12">The Draw-Buffer</h4>
<p>Like a z-buffer, but with 1 bit per pixel, indicating whether the pixel has been drawn yet. This eliminates overdraw, but at the cost of an inner-loop buffer test, extra writes and cache misses, and, worst of all, considerable complexity. Variations include testing the draw-buffer a byte at a time and completely skipping fully-occluded bytes, or branching off each draw-buffer byte to one of 256 unrolled inner loops for drawing 0-8 pixels, in the process possibly taking advantage of the ability of the x86 to do the perspective floating-point divide in parallel while 8 pixels are processed.</p>
<h4 align="left" id="Heading13">Span-Based Drawing</h4>
<h4 id="Heading13">Span-Based Drawing</h4>
<p>Polygons are rasterized into spans, which are added to a global span list and clipped against that list so that only the nearest span at each pixel remains. Little sorting is needed with front-to-back walking, because if there&rsquo;s any overlap, the span already in the list is nearer. This eliminates overdraw, but at the cost of a lot of span arithmetic; also, every polygon still has to be turned into spans.</p>
<h4 align="left" id="Heading14">Portals</h4>
<h4 id="Heading14">Portals</h4>
<p>The holes where polygons are missing on surfaces are tracked, because it&rsquo;s only through such portals that line-of-sight can extend. Drawing goes front-to-back, and when a portal is encountered, polygons and portals behind it are clipped to its limits, until no polygons or portals remain visible. Applied recursively, this allows drawing only the visible portions of visible polygons, but at the cost of a considerable amount of portal clipping.</p>
@ -74,16 +77,20 @@
<p>In the end, John decided that the beam tree was a sort of second-order structure, reflecting information already implicitly contained in the world BSP tree, so he tackled the problem of extracting visibility information directly from the world BSP tree. He spent a week on this, as a byproduct devising a perfect DOOM (2-D) visibility architecture, whereby a single, linear walk of a DOOM BSP tree produces zero-overdraw 2-D visibility. Doing the same in 3-D turned out to be a much more complex problem, though, and by the end of the week John was frustrated by the increasing complexity and persistent glitches in the visibility code. Although the direct-BSP approach was getting closer to working, it was taking more and more tweaking, and a simple, clean design didn&rsquo;t seem to be falling out. When I left work one Friday, John was preparing to try to get the direct-BSP approach working properly over the weekend.</p>
<p><br /></p>
<center>
<table border="1">
<tr>
<td><a href="64-02.html">Previous</a></td>
<td>
<a href="64-02.html">Previous</a>
</td>
<td><a href="index.html">Table of Contents</a></td>
<td>
<a href="index.html">Table of Contents</a>
</td>
<td><a href="64-04.html">Next</a></td>
<td>
<a href="64-04.html">Next</a>
</td>
</tr>
</table>
</center>