Initial conversion to markdown

51-01.md

@@ -0,0 +1,96 @@
+  ------------------------ --------------------------------- --------------------
+  [Previous](50-07.html)   [Table of Contents](index.html)   [Next](51-02.html)
+  ------------------------ --------------------------------- --------------------
+
+Chapter 51\
+ Sneakers in Space {#Heading1}
+------------------
+
+### Using Backface Removal to Eliminate Hidden Surfaces {#Heading2}
+
+As I’m fond of pointing out, computer animation isn’t a matter of
+mathematically exact modeling or raw technical prowess, but rather of
+fooling the eye and the mind. That’s especially true for 3-D animation,
+where we’re not only trying to convince viewers that they’re seeing
+objects on a screen—when in truth that screen contains no objects at
+all, only gaggles of pixels—but we’re also trying to create the illusion
+that the objects exist in three-space, possessing four dimensions
+(counting movement over time as a fourth dimension) of their own. To
+make this magic happen, we must provide cues for the eye not only to
+pick out boundaries, but also to detect depth, orientation, and motion.
+This involves perspective, shading, proper handling of hidden surfaces,
+and rapid and smooth screen updates; the whole deal is considerably more
+difficult to pull off on a PC than 2-D animation.
+
+  ------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+  ![](images/i.jpg)   *In some senses, however, 3-D animation is easier than 2-D. Because there’s more going on in 3-D animation, the eye and brain tend to make more assumptions, and so are more apt to see what they expect to see, rather than what’s actually there.*
+  ------------------- ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+If you’re piloting a (virtual) ship through a field of thousands of
+asteroids at high speed, you’re unlikely to notice if the more distant
+asteroids occasionally seem to go right through each other, or if the
+topographic detail on the asteroids’ surfaces sometimes shifts about a
+bit. You’ll be busy viewing the asteroids in their primary role, as
+objects to be navigated around, and the mere presence of topographic
+detail will suffice; without being aware of it, you’ll fill in the
+blanks. Your mind will see the topography peripherally, recognize it for
+what it is supposed to be, and, unless the landscape does something
+really obtrusive such as vanishing altogether or suddenly shooting a
+spike miles into space, you will see what you expect to see: a bunch of
+nicely detailed asteroids tumbling around you.
+
+To what extent can you rely on the eye and mind to make up for
+imperfections in the 3-D animation process? In some areas, hardly at
+all; for example, jaggies crawling along edges stick out like red flags,
+and likewise for flicker. In other areas, though, the human perceptual
+system is more forgiving than you’d think. Consider this: At the end of
+*Return of the Jedi*, in the battle to end all battles around the Death
+Star, there is a sequence of about five seconds in which several
+spaceships are visible in the background. One of those spaceships (and
+it’s not very far in the background, either) looks a bit unusual. What
+it looks like is a sneaker. In fact, it *is* a sneaker—but unless you
+know to look for it, you’ll never notice it, because your mind is busy
+making simplifying assumptions about the complex scene it’s seeing—and
+one of those assumptions is that medium-sized objects floating in space
+are spaceships, unless proven otherwise. (Thanks to Chris Hecker for
+pointing this out. I’d never have noticed the sneaker, myself, without
+being tipped off—which is, of course, the whole point.)
+
+If it’s good enough for George Lucas, it’s good enough for us. And with
+that, let’s resume our quest for realtime 3-D animation on the PC.
+
+### One-sided Polygons: Backface Removal {#Heading3}
+
+In the previous chapter, we implemented the basic polygon drawing
+pipeline, transforming a polygon all the way from its basic definition
+in object space, through the shared 3-D world space, and into the 3-D
+space as seen from the viewpoint, called *view space*. From view space,
+we performed a perspective projection to convert the polygon into screen
+space, then mapped the transformed and projected vertices to the nearest
+screen coordinates and filled the polygon. Armed with code that
+implemented this pipeline, we were able to watch as a polygon rotated
+about its Y axis, and were able to move the polygon around in space
+freely.
+
+One of the drawbacks of the previous chapter’s approach was that the
+polygon had two visible sides. Why is that a drawback? It isn’t,
+necessarily, but in our case we want to use polygons to build solid
+objects with continuous surfaces, and in that context, only one side of
+a polygon is visible; the other side always faces the inside of the
+object, and can never be seen. It would save time and simplify the
+process of hidden surface removal if we could quickly and easily
+determine whether the inside or outside face of each polygon was facing
+us, so that we could draw each polygon only if it were visible (that is,
+had the outside face pointing toward the viewer). On average, half the
+polygons in an object could be instantly rejected by a test of this
+sort. Such testing of polygon visibility goes by a number of names in
+the literature, including backplane culling, backface removal, and
+assorted variations thereon; I’ll refer to it as *backface removal*.
+
+  ------------------------ --------------------------------- --------------------
+  [Previous](50-07.html)   [Table of Contents](index.html)   [Next](51-02.html)
+  ------------------------ --------------------------------- --------------------
+
+* * * * *
+
+Graphics Programming Black Book © 2001 Michael Abrash