Graphics Reference
In-Depth Information
Many classic approximation algorithms were developed decades ago, when
the power of computing and graphics hardware was a tiny fraction of what is
available today, to meet two key goals: minimizing processing and storage require-
ments, and maximizing parallelism (especially in GPUs). These algorithms had
their roots in software implementations that began in the late 1960s, grew in gen-
erality through the 1970s and 1980s, and were then implemented in increasingly
more powerful commercial GPU hardware starting in the 1990s.
A particular sequence of the most successful of these algorithms, commonly
called the
fixed-function 3D graphics pipeline,
has been in use for three decades
and was dominant in GPU design until the late 1990s. This pipeline renders trian-
gular meshes, approximating both polyhedral objects and curved surfaces, using
simple surface lighting equations (for calculating reflected intensity at triangle
vertices, as described in Sections 6.2.2 and 6.5) and shading rules (for estimating
reflected intensity at interior points, as described in Sections 6.3.1 and 6.3.2). An
application uses the fixed-function pipeline via software APIs of the type found in
classic commodity 3D packages such as earlier versions of OpenGL and Direct3D.
WPF is one of the newer APIs providing a fixed-function pipeline, and as we
present its basic feature set throughout the rest of this chapter, we will provide
a brief introduction to the classic approximation techniques, how well they “fool
the eye,” and what their limitations are.
Although the fixed-function pipeline is an excellent way to start experimenting
with the use of 3D graphics platforms (thus our choice of WPF here), it is no
longer de rigueur in modern graphics applications, for which the programmable
pipeline (introduced in Sections 16.1.1 and 16.3) is now the workhorse. As GPU
technology continues its rapid evolution, higher-quality approximations become
more feasible in real time, and the ability to simulate the physics of light-object
interaction in real time becomes ever more feasible.
WPF's 3D support is closely integrated with the 2D feature set described in Chap-
ter 2, and is accessed in the same way. XAML can be used to initialize scenes
and implement simple animation, and procedural code can be used for interac-
tivity and runtime dynamics. To include a 3D scene in a WPF application, you
create an instance of
Viewport3D
(which acts as a rectangular canvas on which
3D scenes are displayed) and use a layout manager to integrate it into the rest of
your application (e.g., alongside any panel of UI controls).
A
Viewport3D
is similar to a WPF
Canvas
in that it is blank until given a
scene to display. To specify and render a scene, you must create and position a set
of geometric objects, specify their appearance attributes, place and configure one
or more lights, and place and configure a camera.
The 3D equivalent of the 2D abstract application coordinate system is the
world coordinate system,
with
x
-,
y
-, and
z
-axes in a right-handed orientation (as
explained later in Figure 7.8). The unit of measurement is abstract; the application
designer can choose to use a physical unit of measurement (such as millimeter,
inch, etc.), or to assign no semantics to the coordinates. The scene's objects, the
camera, and the lights are placed and oriented using world coordinates.
The use of physical units is optional, but can be helpful to accurately emulate
some kind of physical reality (e.g., meters for modeling an actual neighborhood's
houses and streets, or millimicrons for modeling molecules). The WPF platform
itself is not informed of any semantics the application might attach to the units.
