Remove colour attributes from body and strip most of the font tags out
This commit is contained in:
James Gregory
parent
7e957c0bb4
commit
c1f88ddb41
362 changed files with 1632 additions and 1706 deletions
10
66-03.html
10
66-03.html
|
|
@ -24,7 +24,7 @@
|
|||
<!--CHAPTER=66//-->
|
||||
<!--PAGES=1217-1220//-->
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//--></HEAD><BODY LINK=#0000FF ALINK=#000099 VLINK=#0000FF BGCOLOR=#FFFFFF>
|
||||
<!--UNASSIGNED2//--></HEAD><body>
|
||||
|
||||
<CENTER>
|
||||
<TABLE BORDER>
|
||||
|
|
@ -42,16 +42,16 @@
|
|||
<P>The spans that are generated with edge-sorting are exactly the same spans that ultimately emerge from span-sorting; the difference lies in the intermediate data structures that are used to sort the spans in the scene. With edge-sorting, the spans are kept implicit in the edges until the final set of visible spans is generated, so the sorting, clipping, and span emission is done as each edge adds or removes a polygon, based on the span state implied by the edge and the set of active polygons. With span-sorting, spans are immediately made explicit when each polygon is rasterized, and those intermediate spans are then sorted and clipped against other the spans on the scan line to generate the final spans, so the states of the spans are explicit at all times, and all work is done directly with spans.</P>
|
||||
<P>Both span-sorting and edge-sorting work well, and both have been employed successfully in commercial projects. We’ve chosen to use edge-sorting in Quake partly because it seems inherently more efficient, with excellent horizontal coherence that makes for minimal time spent sorting, in contrast with the potentially costly sorting into linked lists that span-sorting can involve. A more important reason, though, is that with edge-sorting we’re able to share edges between adjacent polygons, and that cuts the work involved in sorting, clipping, and rasterizing edges nearly in half, while also shrinking the world database quite a bit due to the sharing.</P>
|
||||
<P><A NAME="Fig3"><!-- </A><A HREF="javascript:displayWindow('images/66-03.jpg',404,432 )"> --><IMG SRC="images/66-03.jpg"><BR><!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/66-03.jpg',404,432)"> --><FONT COLOR="#000077"><B>Figure 66.3</B></FONT></A> <I>Activating a polygon when a leading edge is encountered in the AEL.</I>
|
||||
<BR><A HREF="javascript:displayWindow('images/66-03.jpg',404,432)"> --><B>Figure 66.3</B></A> <I>Activating a polygon when a leading edge is encountered in the AEL.</I>
|
||||
</P>
|
||||
<P>One final advantage of edge-sorting is that it makes no distinction between convex and concave polygons. That’s not an important consideration for most graphics engines, but in Quake, edge clipping, transformation, projection, and sorting have become a major bottleneck, so we’re doing everything we can to get the polygon and edge counts down, and concave polygons help a lot in that regard. While it’s possible to handle concave polygons with span-sorting, that can involve significant performance penalties.
|
||||
</P>
|
||||
<P><A NAME="Fig4"><!-- </A><A HREF="javascript:displayWindow('images/66-04.jpg',407,395 )"> --><IMG SRC="images/66-04.jpg"><BR><!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/66-04.jpg',407,395)"> --><FONT COLOR="#000077"><B>Figure 66.4</B></FONT></A> <I>Deactivating a polygon when a trailing edge is encountered in the AEL.</I>
|
||||
<BR><A HREF="javascript:displayWindow('images/66-04.jpg',407,395)"> --><B>Figure 66.4</B></A> <I>Deactivating a polygon when a trailing edge is encountered in the AEL.</I>
|
||||
</P>
|
||||
<P>Nonetheless, there’s no cut-and-dried answer as to which approach is better. In the end, span-sorting and edge-sorting amount to the same functionality, and the choice between them is a matter of whatever you feel most comfortable with. In Chapter 67, I’ll go into considerable detail about edge-sorting, complete with a full implementation. I’m going the spend the rest of this chapter laying the foundation for Chapter 67 by discussing sorting keys and 1/z calculation. In the process, I’m going to have to make a few forward references to aspects of edge-sorting that I haven’t yet covered in detail; my apologies, but it’s unavoidable, and all should become clear by the end of Chapter 67.
|
||||
</P>
|
||||
<H3><A NAME="Heading9"></A><FONT COLOR="#000077">Edge-Sorting Keys</FONT></H3>
|
||||
<H3><A NAME="Heading9"></A>Edge-Sorting Keys</H3>
|
||||
<P>Now that we know we’re going to sort edges, using them to emit spans for the polygons nearest the viewer, the question becomes: How can we tell which polygons are nearest? Ideally, we’d just store a sorting key in each polygon, and whenever a new edge came along, we’d compare its surface’s key to the keys of other currently active polygons, and could easily tell which polygon was nearest.
|
||||
</P>
|
||||
<P>That sounds too good to be true, but it is possible. If, for example, your world database is stored as a BSP tree, with all polygons clipped into the BSP leaves, then BSP walk order is a valid drawing order. So, for example, if you walk the BSP back-to-front, assigning each polygon an incrementally higher key as you reach it, polygons with higher keys are guaranteed to be in front of polygons with lower keys. This is the approach Quake used for a while, although a different approach is now being used, for reasons I’ll explain shortly.</P>
|
||||
|
|
@ -70,7 +70,7 @@
|
|||
|
||||
<hr width="90%" size="1" noshade>
|
||||
<div align="center">
|
||||
<font face="Verdana,sans-serif" size="1">Graphics Programming Black Book © 2001 Michael Abrash</font>
|
||||
Graphics Programming Black Book © 2001 Michael Abrash
|
||||
</div>
|
||||
<!-- all of the reference materials (books) have the footer and subfoot reveresed -->
|
||||
<!-- reference_subfoot = footer -->
|
||||
|
|
|
|||
Loading…
Reference in a new issue