Normal quotes
This commit is contained in:
parent
5e10794a24
commit
18011c595a
352 changed files with 6040 additions and 6040 deletions
30
51-02.md
30
51-02.md
|
|
@ -2,7 +2,7 @@
|
|||
[Previous](51-01.html) [Table of Contents](index.html) [Next](51-03.html)
|
||||
------------------------ --------------------------------- --------------------
|
||||
|
||||
For a single convex polyhedron, removal of polygons that aren’t facing
|
||||
For a single convex polyhedron, removal of polygons that aren't facing
|
||||
the viewer would solve all hidden surface problems. In a convex
|
||||
polyhedron, any polygon facing the viewer can never be obscured by any
|
||||
other polygon in that polyhedron; this falls out of the definition of a
|
||||
|
|
@ -13,7 +13,7 @@ the viewer, everything will work out properly, with no additional
|
|||
checking for overlap and hidden surfaces needed.
|
||||
|
||||
Unfortunately, backface removal completely solves the hidden surface
|
||||
problem for convex polyhedrons *only*, and only if there’s a single
|
||||
problem for convex polyhedrons *only*, and only if there's a single
|
||||
convex polyhedron involved; when convex polyhedrons overlap, other
|
||||
methods must be used. Nonetheless, backface removal does instantly halve
|
||||
the number of polygons to be handled in rendering any particular scene.
|
||||
|
|
@ -22,20 +22,20 @@ built out of convex polyhedrons. In this chapter, though, we have only
|
|||
one convex polyhedron to deal with, so backface removal alone will do
|
||||
the trick.
|
||||
|
||||
Given that I’ve convinced you that backface removal would be a handy
|
||||
Given that I've convinced you that backface removal would be a handy
|
||||
thing to have, how do we actually do it? A logical approach, often
|
||||
implemented in the PC literature, would be to calculate the plane
|
||||
equation for the plane in which the polygon lies, and see which way the
|
||||
normal (perpendicular) vector to the plane points. That works, but
|
||||
there’s a more efficient way to calculate the normal to the polygon: as
|
||||
the cross-product of two of the polygon’s edges.
|
||||
there's a more efficient way to calculate the normal to the polygon: as
|
||||
the cross-product of two of the polygon's edges.
|
||||
|
||||
The cross-product of two vectors is defined as the vector shown in
|
||||
Figure 51.1. One interesting property of the cross-product vector is
|
||||
that it is perpendicular to the plane in which the two original vectors
|
||||
lie. If we take the cross-product of the vectors that form two edges of
|
||||
a polygon, the result will be a vector perpendicular to the polygon;
|
||||
then, we’ll know that the polygon is visible if and only if the
|
||||
then, we'll know that the polygon is visible if and only if the
|
||||
cross-product vector points toward the viewer. We need one more thing to
|
||||
make the cross-product approach work, though. The cross-product can
|
||||
actually point either way, depending on which edges of the polygon we
|
||||
|
|
@ -46,22 +46,22 @@ cross-product.
|
|||
\
|
||||
**Figure 51.1** *The cross-product of two vectors.*
|
||||
|
||||
We’ll define only convex polygons, with the vertices defined in
|
||||
clockwise order, as viewed from the outside; that is, if you’re looking
|
||||
We'll define only convex polygons, with the vertices defined in
|
||||
clockwise order, as viewed from the outside; that is, if you're looking
|
||||
at the visible side of the polygon, the vertices will appear in the
|
||||
polygon definition in clockwise order. With those assumptions, the
|
||||
cross-product becomes a quick and easy indicator of polygon orientation
|
||||
with respect to the viewer; we’ll calculate it as the cross-product of
|
||||
with respect to the viewer; we'll calculate it as the cross-product of
|
||||
the first and last vectors in a polygon, as shown in Figure 51.2, and if
|
||||
it’s pointing toward the viewer, we’ll know that the polygon is visible.
|
||||
Actually, we don’t even have to calculate the entire cross-product
|
||||
it's pointing toward the viewer, we'll know that the polygon is visible.
|
||||
Actually, we don't even have to calculate the entire cross-product
|
||||
vector, because the Z component alone suffices to tell us which way the
|
||||
polygon is facing: positive Z means visible, negative Z means not. The Z
|
||||
component can be calculated very efficiently, with only two multiplies
|
||||
and a subtraction.
|
||||
|
||||
The question remains of the proper space in which to perform backface
|
||||
removal. There’s a temptation to perform it in view space, which is,
|
||||
removal. There's a temptation to perform it in view space, which is,
|
||||
after all, the space defined with respect to the viewer, but view space
|
||||
is not a good choice. Screen space—the space in which perspective
|
||||
projection has been performed—is the best choice. The purpose of
|
||||
|
|
@ -77,15 +77,15 @@ normal.*
|
|||
Backface removal may also be performed using the polygon vertices in
|
||||
screen coordinates, which are integers. This is less accurate than using
|
||||
the screen space coordinates, which are floating point, but is, by the
|
||||
same token, faster. In Listing 51.3, which we’ll discuss shortly,
|
||||
same token, faster. In Listing 51.3, which we'll discuss shortly,
|
||||
backface removal is performed in screen coordinates in the interests of
|
||||
speed.
|
||||
|
||||
Backface removal, as implemented in Listing 51.3, will not work reliably
|
||||
if the polygon is not convex, if the vertices don’t appear in clockwise
|
||||
if the polygon is not convex, if the vertices don't appear in clockwise
|
||||
order, if either the first or last edge in a polygon has zero length, or
|
||||
if the first and last edges are collinear. These latter two points are
|
||||
the reason it’s preferable to work in screen space rather than screen
|
||||
the reason it's preferable to work in screen space rather than screen
|
||||
coordinates (which suffer from rounding problems), speed considerations
|
||||
aside.
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue