Strip comments and inline ids onto h*
This commit is contained in:
James Gregory
parent
1997a7846d
commit
0f5f617adb
362 changed files with 2519 additions and 6694 deletions
33
40-01.html
33
40-01.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: Of Songs, Taxes, and the Simplicity of Complex Polygons</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: Of Songs, Taxes, and the Simplicity of Complex Polygons</title>
|
||||
<meta name="chapter" content="40" />
|
||||
<meta name="pages" content="739-744" />
|
||||
<!--UNASSIGNED1//-->
|
||||
<!--UNASSIGNED2//-->
|
||||
</head>
|
||||
|
||||
<body>
|
||||
|
|
@ -37,10 +30,10 @@
|
|||
|
||||
<p><br /></p>
|
||||
|
||||
<h2><a id="Heading1"></a>Chapter 40<br />
|
||||
<h2 id="Heading1">Chapter 40<br />
|
||||
Of Songs, Taxes, and the Simplicity of Complex Polygons</h2>
|
||||
|
||||
<h3><a id="Heading2"></a>Dealing with Irregular Polygonal Areas</h3>
|
||||
<h3 id="Heading2">Dealing with Irregular Polygonal Areas</h3>
|
||||
|
||||
<p>Every so often, my daughter asks me to sing her to sleep. (If you’ve ever heard me sing, this may cause you concern about either her hearing or her judgement, but love knows no bounds.) As any parent is well aware, singing a young child to sleep can easily take several hours, or until sunrise, whichever comes last. One night, running low on children’s songs, I switched to a Beatles medley, and at long last her breathing became slow and regular. At the end, I softly sang “A Hard Day’s Night,” then quietly stood up to leave. As I tiptoed out, she said, in a voice not even faintly tinged with sleep, “Dad, what do they mean, ‘working like a dog’? Chasing a stick? That doesn’t make sense; people don’t chase sticks.”</p>
|
||||
|
||||
|
|
@ -50,7 +43,7 @@
|
|||
|
||||
<p>Filling arbitrary polygons is such a case.</p>
|
||||
|
||||
<h3><a id="Heading3"></a>Filling Arbitrary Polygons</h3>
|
||||
<h3 id="Heading3">Filling Arbitrary Polygons</h3>
|
||||
|
||||
<p>In Chapter 38, I described three types of polygons: convex, nonconvex, and complex. <i>The RenderMan Companion</i>, a terrific book by Steve Upstill (Addison-Wesley, 1990) has an intuitive definition of <i>convex</i>: If a rubber band stretched around a polygon touches all vertices in the order they’re defined, then the polygon is convex. If a polygon has intersecting edges, it’s complex. If a polygon doesn’t have intersecting edges but isn’t convex, it’s nonconvex. Nonconvex is a special case of complex, and convex is a special case of nonconvex. (Which, I’m well aware, makes nonconvex a lousy name—noncomplex would have been better—but I’m following X Window System nomenclature here.)</p>
|
||||
|
||||
|
|
@ -58,21 +51,19 @@
|
|||
|
||||
<p>Before we dive into complex polygon filling, I’d like to point out that the code in this chapter, like all polygon filling code I’ve ever seen, requires that the caller describe the type of the polygon to be filled. Often, however, the caller doesn’t know what type of polygon it’s passing, or specifies complex for simplicity, because that will work for all polygons; in such a case, the polygon filler will use the slow complex-fill code even if the polygon is, in fact, a convex polygon. In Chapter 41, I’ll discuss one way to improve this situation.</p>
|
||||
|
||||
<h4 align="left"><a id="Heading4"></a>Active Edges</h4>
|
||||
<h4 align="left" id="Heading4">Active Edges</h4>
|
||||
|
||||
<p>The basic premise of filling a complex polygon is that for a given scan line, we determine all intersections between the polygon’s edges and that scan line and then fill the spans between the intersections, as shown in Figure 40.1. (Section 3.6 of Foley and van Dam’s <i>Computer Graphics</i>, Second Edition provides an overview of this and other aspects of polygon filling.) There are several rules that might be used to determine which spans are drawn and which aren’t; we’ll use the odd/even rule, which specifies that drawing turns on after odd-numbered intersections (first, third, and so on) and off after even-numbered intersections.</p>
|
||||
|
||||
<p>The question then becomes how can we most efficiently determine which edges cross each scan line and where? As it happens, there is a great deal of coherence from one scan line to the next in a polygon edge list, because each edge starts at a given Y coordinate and continues unbroken until it ends. In other words, edges don’t leap about and stop and start randomly; the X coordinate of an edge at one scan line is a consistent delta from that edge’s X coordinate at the last scan line, and that is consistent for the length of the line.</p>
|
||||
|
||||
<p><a id="Fig1"><!-- </A><A HREF="javascript:displayWindow('images/40-01.jpg',409,221 )"> --><img src="images/40-01.jpg" /><br />
|
||||
<!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/40-01.jpg',409,221)"> --><b>Figure 40.1</b></a> <i>Filling one scan line by finding intersecting edges.</i></p>
|
||||
<p><a id="Fig1"><img src="images/40-01.jpg" /><br />
|
||||
<b>Figure 40.1</b></a> <i>Filling one scan line by finding intersecting edges.</i></p>
|
||||
|
||||
<p>This allows us to reduce the number of edges that must be checked for intersection; on any given scan line, we only need to check for intersections with the currently active edges—edges that start on that scan line, plus all edges that start on earlier (above) scan lines and haven’t ended yet—as shown in Figure 40.2. This suggests that we can proceed from the top scan line of the polygon to the bottom, keeping a running list of currently active edges—called the <i>active edge table</i> (AET)—with the edges sorted in order of ascending X coordinate of intersection with the current scan line. Then, we can simply fill each scan line in turn according to the list of active edges at that line.</p>
|
||||
|
||||
<p><a id="Fig2"><!-- </A><A HREF="javascript:displayWindow('images/40-02.jpg',409,194 )"> --><img src="images/40-02.jpg" /><br />
|
||||
<!-- </A>
|
||||
<BR><A HREF="javascript:displayWindow('images/40-02.jpg',409,194)"> --><b>Figure 40.2</b></a> <i>Checking currently active edges (solid lines).</i></p>
|
||||
<p><a id="Fig2"><img src="images/40-02.jpg" /><br />
|
||||
<b>Figure 40.2</b></a> <i>Checking currently active edges (solid lines).</i></p>
|
||||
|
||||
<p>Maintaining the AET from one scan line to the next involves three steps: First, we must add to the AET any edges that start on the current scan line, making sure to keep the AET X-sorted for efficient odd/even scanning. Second, we must remove edges that end on the current scan line. Third, we must advance the X coordinates of active edges with the same sort of error term-based, Bresenham’s-like approach we used for convex polygons, again ensuring that the AET is X-sorted after advancing the edges.</p>
|
||||
|
||||
|
|
@ -93,10 +84,6 @@
|
|||
|
||||
<div align="center">
|
||||
Graphics Programming Black Book © 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>
|
||||
|
|
|
|||
Loading…
Reference in a new issue