Graphics Reference
In-Depth Information
For now we'll use the more intuitive choice of distance from
P
to the origin,
|
.
The depth buffer has the same dimensions as the image, so it consumes a
potentially significant amount of memory. It must also be accessed atomically
under a parallel implementation, so it is a potentially slow synchronization point.
Chapter 36 describes alternative algorithms for resolving visibility under raster-
ization that avoid these drawbacks. However, depth buffers are by far the most
widely used method today. They are extremely efficient in practice and have pre-
dictable performance characteristics. They also offer advantages beyond the sam-
pling process. For example, the known depth at each pixel at the end of 3D ren-
dering yields a “2.5D” result that enables compositing of multiple render passes
and post-processing filters, such as artificial defocus blur.
This depth comparison turns out to be a fundamental idea, and it is now
supported by special fixed-function units in graphics hardware. A huge leap in
computer graphics performance occurred when this feature emerged in the early
1980s.
P
−
O
|
The kinds of choices discussed in this section are important. We want to intro-
duce them now, and we want them all in one place so that you can refer to them
later. Many of them will only seem natural to you after you've worked with graph-
ics for a while. So read this section now, set it aside, and then read it again in
a month.
In your studies of computer graphics you will likely learn many APIs and
software design patterns. For example, Chapters 2, 4, 6, and 16 teach the 2D and
3D WPF APIs and some infrastructure built around them.
Teaching that kind of content is expressly
not
a goal of this chapter. This chap-
ter is about creating algorithms for sampling light. The implementation serves
to make the algorithms concrete and provide a test bed for later exploration.
Although learning a specific platform is not a goal, learning the issues to con-
sider when evaluating a platform
is
a goal; in this section we describe those
issues.
We select one specific platform, a subset of the G3D Innovation Engine
[
http://g3d.sf.net]
Version 9, for the code examples. You may use this one, or
some variation chosen after considering the same issues weighed by your own
goals and computing environment. In many ways it is better if your platform—
language, compiler, support classes, hardware API—is
not
precisely the same as
the one described here. The platform we select includes only a minimalist set of
support classes. This keeps the presentation simple and generic, as suits a text-
book. But you're developing software on today's technology, not writing a text-
book that must serve independent of currently popular tools.
Since you're about to invest a lot of work on this renderer, a richer set of sup-
port classes will make both implementation and debugging easier. You can com-
pile our code directly against the support classes in G3D. However, if you have to
rewrite it slightly for a different API or language, this will force you to actually
read every line and consider why it was written in a particular manner. Maybe your
chosen language has a different syntax than ours for passing a parameter by value
