Graphics Reference
In-Depth Information
User input
Simulate
(includes AI & Physics)
Dynamic 3D geometry
Pose
Static 3D geometry
Texture
Cull
Reduced 3D geometry
Camera Transformations
& Projection
2D geometry
Rasterize
2D pixels
Performed
in hardware
Shade
Combine
2D radiance
Post-process
Displayable 2D image
Figure 33.1: The steps involved in a basic rasterizing renderer.
There are many operations—transforming objects from object space to world
space to camera space, shading, placing pixel values in a buffer for later use (either
in environment mapping, for instance, or in compositing with some other precom-
puted imagery)—that occur in both pipelines.
As software engineers, we know that when there's commonality, there's an
opportunity for abstraction and the development of an interface to the common
portions of the code. The particular
form
of the interface can vary: Some designs
employ virtual methods, others use callbacks, etc. In some cases the thing being
abstracted is complex enough that the way in which it's used is itself complex.
In these cases, it makes sense to create a language in which the use pattern is
described via small programs. We've seen an example of this with WPF in ear-
lier chapters: XAML provides a language for describing objects, their geometric
properties, their relationships, and how data is passed among them, for instance.
A C# program usually combines with XAML code to constitute an entire graphics
project.
In the case of the graphics pipelines shown in the preceding figures, there's a
common structure: The geometric and material descriptions of objects in a scene
undergo similar transformations, for instance, in a similar order in both pipelines.
But the details of what goes on at certain stages vary.
Shaders
are small programs
that specify how the duties of certain portions of the pipeline are to be carried out.
The sidebar in this chapter describes informally how we got from individ-
ual renderers written in research laboratories to the software design of packages
like GL 4.
