Graphics Reference
In-Depth Information
to
P
, but can see
P
through a mirror or see its shadow, we still say that there is no
direct visibility:
V
(
P
,
Q
)=
0.
Let
X
be the first scene point encountered along a ray with origin
P
in direction
Q
P
)
. Point
X
partitions the ray into two visibility ranges. To see
this, define
f
to be visibility as a function of distance from
Q
, that is, let
f
(
t
)=
V
(
P
,
P
+ ˆ
ˆ
=
S
(()
Q
−
v
X
P
t
)
. Between
X
and
P
,0
≤
t
≤|
X
−
P
|
, there is visibility, so
f
(
t
)=
1
v
as shown in Figure 36.3. Beyond
X
,
t
> ||
X
−
P
||
. For that domain there is no
visibility because
X
is an occluder, so
f
(
t
)=
0.
Figure 36.3: Visibility parameter-
ized by distance along a ray.
Evaluating the visibility function is mathematically equivalent to finding that
first occluding point
X
, given a starting point
P
and ray direction
ˆ
. The first
occluding point along a ray is the solution to a ray
intersection query.
Chapter 37
presents data structures for efficiently solving ray intersection queries. It is not
surprising that a common way to evaluate
V
(
P
,
Q
)
is to solve for
X
.If
X
exists
and lies on the line segment
PQ
, then
V
(
P
,
Q
)=
0; otherwise,
V
(
P
,
Q
)=
1.
Some rendering algorithms explicitly evaluate the visibility function between
pairs of points by testing for
any
intersection between a line segment and the
surfaces in a scene. Examples include direct illumination shadow tests in a ray
tracer and transport path testing in bidirectional path tracing [LW93, VG94], and
Metropolis light transport [VG97].
Others solve for the first intersection along a ray instead, thus implicitly evalu-
ating visibility by only generating the visible set of points. Examples include pri-
mary and recursive rays in a ray tracer and deferred-shading rasterizers. These are
all algorithms with explicit visibility determination. They resolve visibility before
computing transport (often called “shading” in the real-time rendering commu-
nity) between points, thus avoiding the cost of scattering computations for points
with no net transport. Simpler renderers compute transport first and rely on order-
ing to implicitly resolve visibility. For example, a naive ray tracer might shade
every
intersection encountered along a ray, but only retain the radiance computed
at the one closest to the ray origin. This is equivalent to an (also naive) rasteri-
zation renderer that does not make a depth prepass. Obviously it is preferable to
evaluate visibility before shading in cases where the cost of shading is relatively
high, but whether to evaluate that visibility explicitly or implicitly greatly depends
on the particular machine architecture and scene data structure. For example, ras-
terization renderers prefer a depth prepass today because the memory to store a
depth buffer is now relatively inexpensive. Were the cost of a full-screen buffer
very expensive compared to the cost of computation (as it once was, and might
again become if resolution or manufacturing changes significantly), then a visibil-
ity prepass might be the naive choice and some kind of spatial data structure again
dominate rasterization rendering.
Observe that following conventions from the literature, we defined the visi-
bility function on the
open
line segment that does not include its endpoints. This
means that if the ray from
P
to
Q
first meets scene geometry at a point
X
dif-
ferent from
P
, then
V
(
P
,
X
)=
1. This is a convenient definition given that the
function is typically applied to points
on
surfaces. Were we to consider the closed
line segment, then there would never be any visibility between the surfaces of
a scene—they would all occlude themselves. We would have to consider points
slightly offset from the surfaces in light transport equations.
In practice, the distinction between open and closed visibility only simpli-
fies the notation of transport equations, not implementations in programs. That is
because rounding operations implicitly occur after every operation when working
v
