Graphics Reference
In-Depth Information
first round vertices to some imposed precision (say, one-quarter of a pixel width),
and must then choose a representation and maximum screen size that provide
exact storage.
The fundamental operation in the rasterizer is a 2D dot product to determine
the side of the line on which a point lies. So we care about the precision of a mul-
tiplication and an addition. If our screen resolution is
w
×
h
and we want
k
×
k
subpixel positions for snapping or antialiasing, then we need
log
2
(
k
·
max(
w
,
h
))
bits to store each scalar value. At 1920
×
1080 (i.e., effectively 2048
×
2048) with
4
4 subpixel precision, that's 14 bits. To store the product, we need twice as
many bits. In our example, that's 28 bits. This is too large for the 23-bit man-
tissa portion of the IEEE 754 32-bit floating-point format, which means that we
cannot implement the rasterizer using the single-precision
float
data type. We
can use a 32-bit integer, representing a 24.4 fixed-point value. In fact, within that
integer's space limitations we can increase screen resolution to 8192
×
×
8192 at
4
4 subpixel resolution. This is actually a fairly low-resolution subpixel grid,
however. In contrast, DirectX 11 mandates eight bits of subpixel precision in each
dimension. That is because under low subpixel precision, the aliasing pattern of a
diagonal edge moving slowly across the screen appears to jump in discrete steps
rather than evolve slowly with motion.
×
Although we are now rasterizing primary visibility, our
shade
routine still deter-
mines the locations of shadows by casting rays. Shadowing from a local point
source is equivalent to “visibility” from the perspective of that source. So we can
apply rasterization to that visibility problem as well.
A
shadow map
[Wil78] is an auxiliary depth buffer rendered from a cam-
era placed at the light's location. This contains the same distance information as
obtained by casting rays from the light to selected points in the scene. The shadow
map can be rendered in one pass over the scene geometry
before
the camera's
view is rendered. Figure 15.14 shows a visualization of a shadow map, which is a
common debugging aid.
When a shadowing computation arises during rendering from the camera's
view, the renderer uses the shadow map to resolve it. For a rendered point to be
unshadowed, it must be simultaneously visible to both the light and the camera.
Recall that we are assuming a pinhole camera and a point light source, so the
Figure 15.14: Left: A shadow map visualized with black = near the light and white
=
far
from the light. Right: The camera's view of the scene with shadows.
