Graphics Reference
In-Depth Information
So far, we implemented rasterization by simply inverting the order of the for-
each-triangle and for-each-pixel loops in a ray tracer. This performs many ray-
triangle intersection tests that will fail. This is referred to as
poor sample test
efficiency
.
We can significantly improve sample test efficiency, and therefore perfor-
mance, on small triangles by only considering pixels whose centers are near the
projection of the triangle. To do this we need a heuristic for efficiently bound-
ing each triangle's projection. The bound must be conservative so that we never
miss an intersection. The initial implementation already used a very conservative
bound. It assumed that every triangle's projection was “near”
every
pixel on the
screen. For large triangles, that may be true. For triangles whose true projection is
small in screen space, that bound is too conservative.
The best bound would be a triangle's true projection, and many rasterizers
in fact use that. However, there are significant amounts of boilerplate and corner
cases in iterating over a triangular section of an image, so here we will instead
use a more conservative but still reasonable bound: the 2D axis-aligned bounding
box about the triangle's projection. For a large nondegenerate triangle, this covers
about twice the number of pixels as the triangle itself.
Inline Exercise 15.9:
Why is it true that a large-area triangle covers at most
about half of the samples of its bounding box? What happens for a
small
triangle, say, with an area smaller than one pixel? What are the implications
for sample test efficiency if you know the size of triangles that you expect to
render?
The axis-aligned bounding box, however, is straightforward to compute and
will produce a significant speedup for many scenes. It is also the method favored
by many hardware rasterization designs because the performance is very pre-
dictable, and for very small triangles the cost of computing a more accurate bound
might dominate the ray-triangle intersection test.
The code in Listing 15.23 determines the bounding box of a triangle
T
.The
code projects each vertex from the camera's 3D reference frame onto the plane
z
=
1, and then maps those vertices into the screen space 2D reference frame.
This operation is handled entirely by the
perspectiveProject
helper function.
The code then computes the minimum and maximum screen-space positions of
the vertices and rounds them (by adding 0.5 and then casting the floating-point
values to integers) to integer pixel locations to use as the for-each-pixel bounds.
The interesting work is performed by
perspectiveProject
. This inverts
the process that
computeEyeRay
performed to find the eye-ray origin (before
advancing it to the near plane). A direct implementation following that deriva-
tion is given in Listing 15.24. Chapter 13 gives a derivation for this operation as a
matrix-vector product followed by a homogeneous division operation. That imple-
mentation is more appropriate when the perspective projection follows a series of
other transformations that are also expressed as matrices so that the cost of the
matrix-vector product can be amortized over all transformations. This version is
potentially more computationally efficient (assuming that the constant subexpres-
sions are precomputed) for the case where there are no other transformations; we
also give this version to remind you of the derivation of the perspective projection
matrix.
−
