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

Remove colour attributes from body and strip most of the font tags out

Browse source
This commit is contained in:
James Gregory 2013-12-30 13:57:02 +11:00
commit c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
Download patch file Download diff file Expand all files Collapse all files

10
66-04.html
View file

@ -24,7 +24,7 @@
<!--CHAPTER=66//-->
<!--PAGES=1221-1222//-->
<!--UNASSIGNED1//-->
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
<!--UNASSIGNED2//--></HEAD><body>
<CENTER>
<TABLE BORDER>
@ -42,7 +42,7 @@
<P>1/z = (a/d)x&rsquo; - (b/d)y&rsquo; + c/d</P>
<P>where z is the viewspace z coordinate of the point on the plane that projects to screen coordinate (x&rsquo;,y&rsquo;) (the origin for this calculation is the center of projection, the point on the screen straight ahead of the viewpoint), [a b c] is the plane normal in viewspace, and d is the distance from the viewspace origin to the plane along the normal. Division is done only once per plane, because a, b, c, and d are per-plane constants.</P>
<P>The full 1/z calculation requires two multiplies and two adds, all of which should be floating-point to avoid range errors. That much floating-point math sounds expensive but really isn&rsquo;t, especially on a Pentium, where a plane&rsquo;s 1/z value at any point can be calculated in as little as six cycles in assembly language.</P>
<H4 ALIGN="LEFT"><A NAME="Heading10"></A><FONT COLOR="#000077">Where That 1/Z Equation Comes From</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading10"></A>Where That 1/Z Equation Comes From</H4>
<P>For those who are interested, here&rsquo;s a quick derivation of the 1/z equation. The plane equation for a plane is
</P>
<P>ax + by + cz - d = 0</P>
@ -51,12 +51,12 @@
<P>Inverting and distributing yields:</P>
<P>= ax&rsquo;/d - by&rsquo;/d + c/d</P>
<P>We&rsquo;ll see 1/z sorting in action in Chapter 67.</P>
<H4 ALIGN="LEFT"><A NAME="Heading11"></A><FONT COLOR="#000077">Quake and Z-Sorting</FONT></H4>
<H4 ALIGN="LEFT"><A NAME="Heading11"></A>Quake and Z-Sorting</H4>
<P>I mentioned earlier that Quake no longer uses BSP order as the sorting key; in fact, it uses 1/z as the key now. Elegant as the gradients are, calculating 1/z from them is clearly slower than just doing a compare on a BSP-ordered key, so why have we switched Quake to 1/z?
</P>
<P>The primary reason is to reduce the number of polygons. Drawing in BSP order means following certain rules, including the rule that polygons must be split if they cross BSP planes. This splitting increases the numbers of polygons and edges considerably. By sorting on 1/z, we&rsquo;re able to leave polygons unsplit but still get correct drawing order, so we have far fewer edges to process and faster drawing overall, despite the added cost of 1/z sorting.</P>
<P>Another advantage of 1/z sorting is that it solves the sorting issues I mentioned at the start involving moving models that are themselves small BSP trees. Sorting in world BSP order wouldn&rsquo;t work here, because these models are separate BSPs, and there&rsquo;s no easy way to work them into the world BSP&rsquo;s sequence order. We don&rsquo;t want to use z-buffering for these models because they&rsquo;re often large objects such as doors, and we don&rsquo;t want to lose the overdraw-reduction benefits that closed doors provide when drawn through the edge list. With sorted spans, the edges of moving BSP models are simply placed in the edge list (first clipping polygons so they don&rsquo;t cross any solid world surfaces, to avoid complications associated with interpenetration), along with all the world edges, and 1/z sorting takes care of the rest.</P>
<H3><A NAME="Heading12"></A><FONT COLOR="#000077">Decisions Deferred</FONT></H3>
<H3><A NAME="Heading12"></A>Decisions Deferred</H3>
<P>There is, without a doubt, an awful lot of information in the preceding pages, and it may not all connect together yet in your mind. The code and accompanying explanation in the next chapter should help; if you want to peek ahead, the code is available on the CD-ROM as DDJZSORT.ZIP in the directory for Chapter 67. You may also want to take a look at Foley and van Dam&rsquo;s <I>Computer Graphics</I> or Rogers&rsquo; <I>Procedural Elements for Computer Graphics</I>.</P>
<P>As I write this, it&rsquo;s unclear whether Quake will end up sorting edges by BSP order or 1/z. Actually, there&rsquo;s no guarantee that sorted spans in any form will be the final design. Sometimes it seems like we change graphics engines as often as they play Elvis on the &lsquo;50s oldies stations (but, one would hope, with more aesthetically pleasing results!) and no doubt we&rsquo;ll be considering the alternatives right up until the day we ship.</P><P><BR></P>
<CENTER>
@ -71,7 +71,7 @@
<hr width="90%" size="1" noshade>
<div align="center">
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book &copy; 2001 Michael Abrash</font>
Graphics Programming Black Book &copy; 2001 Michael Abrash
</div>
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
<!-- reference_subfoot = footer -->