i
i
i
i
i
i
i
i
9.10. Precomputed Occlusion 427
techniques are rather storage intensive, but the basic idea can probably be
used in a more lightweight manner and still produce good results.
Precomputed data can also be used to model the ambient occlusion
effects of objects on each other. Kontkanen and Laine [688, 689] store
the ambient occlusion effect of an object on its surroundings in a cube
map, called an ambient occlusion field. Each texel contains seven scalar
coefficients (so in practice, two cube maps must be used, since a single
cube map can store at most four scalars in a texel). These coefficients, in
combination with the distance to the occluding object’s center, are used to
compute the ambient occlusion.
Malmer et al. [813] show improved results by storing the ambient occlu-
sion factors (and optionally the bent normal) directly in a three-dimensional
grid. The computation requirements are lower, since the ambient occlusion
factor is read directly. Fewer scalars are stored compared to Kontkanen and
Laine’s approach, and the textures in both methods have low resolutions,
so the overall storage requirements are similar.
Figure 9.66. On the top, objects cast shadows on the floor but with no ambient effect.
On the bottom, ambient occlusion fields from the objects cause the floor to darken near
them. These subtle touches give a richness to the lighting in the scene. (Images courtesy
of Emergent Game Technologies and Third Degree Games.)
i
i
i
i
i
i
i
i
428 9. Global Illumination
Both methods work for rigid objects and can be extended to articulated
objects with small numbers of moving parts. Deformable objects are not
discussed, but they could presumably be approximated in many cases as
articulated objects. An example of the use of such methods can be seen in
Figure 9.66.
9.10.2 Precomputed Directional Occlusion
Similar to ambient occlusion, directional shadowing can also benefit from
precomputed information. Max [827] introduced the concept of horizon
mapping to describe self-occlusion of a heightfield surface. In horizon map-
ping, for each point on the surface, the altitude angle of the horizon is de-
termined for some set of azimuth directions (e.g., eight: north, northeast,
east, southeast, etc.). Soft shadowing can also be supported by tracking
the angular extents of the light source; see the left side of Figure 9.67.
Sloan [1185] describes a horizon mapping implementation on early graph-
ics hardware. Forsyth [353] gives an alternative implementation that is
better suited to modern GPUs, using volume textures to store the horizon
angles. In the case of a light source (such as the sun) that moves along
a predetermined arc, a single pair of horizon angles suffices [555]. In this
restricted case, it is also straightforward to extend the horizon map concept
to non-heightfield geometry by storing multiple angle intervals [270]; see
the right side of Figure 9.67. An example of horizon mapping used for soft
shadowing of a terrain heightfield can be seen in Figure 9.68.
θ
hor
Figure 9.67. On the left: The horizon angle in the direction of an area light source is
shown in relation to the upper and lower extents of the light source. These values can
be used to generate a partial occlusion value for soft shadowing. On the right: Storing a
sequence of occluded angle intervals, instead of a single horizon angle, enables modeling
non-heightfield geometry.
i
i
i
i
i
i
i
i
9.10. Precomputed Occlusion 429
Figure 9.68. A terrain heightfield, lit with normal and horizon mapping. Note the soft
shadows.
Instead of storing horizon angles for some given compass directions, the
set of unoccluded three-dimensional directions as a whole can be modeled
as an elliptical [536, 629] or circular [954, 955] cone (the latter technique
is called ambient aperture lighting). These techniques have lower storage
requirements than horizon maps, but may result in incorrect shadows when
the set of unoccluded directions does not resemble an ellipse or circle. For
example, a flat plane from which tall spikes protrude at regular intervals
has star-shaped, unoccluded direction sets.
Although they can be used for heightfield geometry such as terrain,
the most common use of heightfield shadowing techniques is to model self-
shadowing of bump maps. In this case, large-scale shadowing by (and on)
the geometric meshes must be performed with some other method, such as
shadow maps. Handling shadows separately at macroscale and mesoscale
can lead to higher performance than attempting to model both with the
same approach. The problem with this approach is that it cannot account
for some effects. Imagine a column and floor, both with a brick bump
map. The column will cast a smooth shadow on the floor, unaffected by
the bumps on either object.
The optimized form of the Half-Life 2 lighting basis shown in Equa-
tion 9.39 (on page 421) can be modified to include a directional occlusion
factor [440]. If each of the three stored values is attenuated, based on oc-
clusion in the direction of its basis vector, the result is similar to ambient
occlusion, but with some directionality. Notably, this is achieved without
further modifying the shader or increasing its cost.
i
i
i
i
i
i
i
i
430 9. Global Illumination
Landis [728] describes the concept of reflection occlusion,wherearay
cast in the direction of the reflected view vector is tested for occlusion
against the object or scene. The result is then used to attenuate specular
or glossy environment map reflections. Landis does not describe a way to
accelerate the ray casts, since the technique was not intended for real time
rendering. To compute reflection occlusion in real time, Green et al. [443]
propose precomputing directional visibility functions at various surface lo-
cations and projecting them into a spherical harmonic basis. The spherical
harmonic coefficients are stored in textures or vertices. During rendering,
the visibility function is evaluated for the reflection direction. The result is
then used to attenuate the environment map. For the precomputed visibil-
ity results to remain valid, the object must not deform significantly during
rendering. Kozlowski and Kautz [695] found that this type of directional
occlusion is the most effective occlusion approach for environment maps,
in terms of cost versus perceived realism.
As with lighting, occlusion can also be precomputed over a volume.
Zhou et al. [1407] propose storing shadow fields—directional visibility sam-
pled on multiple spherical shells—around an object. For low-frequency
shadowing effects, their representation consumes about 380 kilobytes of
storage per object. Only rigid objects are supported, although the method
may be extended to articulated objects by storing a separate shadow field
for each rigid part. This method models the shadowing of one object by
another, but not self-shadowing. Tamura et al. [1238] propose a
more compact representation for the shadow fields, as well as a GPU
implementation.
9.11 Precomputed Radiance Transfer
Precomputed occlusion models how an object blocks incoming light, but it
does not model other global illumination effects, such as interreflection or
subsurface scattering. All these effects together comprise the object’s ra-
diance transfer. The function that represents the transference of incoming
radiance on an object to outgoing radiance is called the transfer function.
The idea behind precomputed radiance transfer (PRT) is that some rep-
resentation of the transfer function of the object is computed ahead of time
and stored. At rendering time, the transfer function is applied to the in-
coming radiance to generate the outgoing radiance from the object. It is
usually assumed that the scene or object is lit only by distant lighting.
13
The incoming radiance then depends only on incoming direction, and not
on position. It is convenient to represent the domain of such functions as
13
This is the same assumption used in environment mapping.
i
i
i
i
i
i
i
i
9.11. Precomputed Radiance Transfer 431
points on the unit sphere. The x/y/z coordinates of these points are also
the coordinates of normalized vectors, which can thus represent directions.
Precomputed radiance transfer techniques require that the incoming
radiance be projected into an appropriate basis. For computation and
storage reasons, the number of basis functions used must be small. This
restricts the possible incoming radiance situations to a low-dimensional
space.
The first precomputed radiance transfer technique, proposed by Sloan
et al. [1186] used the real spherical harmonics for this purpose (see Sec-
tion 8.6.1 for more information on this basis). In this technique, the trans-
fer function is represented as a set of spherical harmonic (SH) coefficients.
The outgoing radiance from each location is assumed to be the same for all
outgoing directions, i.e., the surface is a diffuse reflector, so radiance can
be represented by a single value.
For each location, the transfer function SH coefficients describe how
much illumination is received, dependent on the incoming light’s direction.
A more direct way of thinking of this function is to consider each spherical
harmonic element as a lighting situation to be evaluated. See Figure 9.69,
which shows the computation of the transfer function coefficients. At the
top, we see the object for which the transfer function will be computed.
Below it are visualizations of the first four spherical harmonic basis func-
tions. We will focus on the leftmost one, which is the simplest spherical
harmonic basis function, y
0
0
. This function has a constant value over the
sphere. The green color indicates that this value is positive. Light color
is ignored for simplicity, so all values shown are scalars (RGB light will be
discussed later).
Under this type of lighting situation, equal illumination comes from
all directions. Say, by some offline process, we precisely compute the out-
going radiance from each location due to direct illumination, reflection,
scattering, etc. The leftmost blue arrow shows the result of this lighting
computation, on the bottom left corner of Figure 9.69. We can see that the
computed amount varies over the object. This amount is the coefficient,
i.e., the multiplier, that says how much light reaches the location and is
reflected outward. Locations in crevices are dimmer, and therefore have a
lower coefficient, than those fully exposed. This coefficient is similar to the
ambient occlusion factor, but it takes the entire radiance transfer process
into account, not just occlusion.
Now take the other three spherical harmonic basis functions shown in
Figure 9.69, and treat each as a lighting situation. For example, the third
basis function from the left (y
0
1
) can be thought of as lights above and below
the object, fading off toward the horizon. Say this lighting situation is then
perfectly evaluated for the vertices (or, really, any given set of locations)
on the object. The coefficient stored at each location will then perfectly
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.