Graphics Reference
In-Depth Information
To satisfy the need for model representation,
4
there are two approaches.
• Create a custom scene-graph module, duplicating functionality found in
a typical RM layer (see Section 16.4), in terms of both storage (such as
a hierarchical component graph, and a database of transform values) and
processing (traversal and generation of the IM instructions).
• Use the program's call-graph hierarchy to represent the model's structure,
by writing a distinct function for each type of node (grouping or primitive),
with the functions for higher-level nodes calling the functions for lower-
level ones.
In the online resources for this chapter, we examine the latter approach in
detail, including source code for a complete working example.
One of the advantages of an RM platform is its support for
pick correlation,
the
determination of the primitive that is the target of a user-initiated mouse click or
other equivalent device action. For example, WPF converts a given 2D viewport
pick point's coordinates into a
pick path
that identifies the entire path from the
root of the scene graph down to the leaf primitive.
Of course, an IM platform cannot automate such functionality since it does
not retain the scene. Thus, an IM application often uses custom correlation logic,
running an algorithm such as ray casting (Chapter 15) while traversing through the
application's scene data store. OpenGL offers an alternative technique that uses
the name stack to efficiently automate hierarchical pick correlation. This technique
is described in the online materials for this chapter.
Programmable Pipeline
At its core, real-time graphics is still done using lights, meshes, materials, trans-
formations for viewing and modeling, etc. The progression from fixed-function
to programmable has not changed its essence. But where these types of objects
reside in the application source code has shifted to programs written in shader
languages and installed in the GPU, as described in detail in Chapter 33.
Let's examine an abstract view of a programmable pipeline, shown in Figure 16.5
and explained in the next few paragraphs. To keep this model simple, we omit
texture data/operations, show only vertex and fragment shaders, and omit feed-
back loops. We use OpenGL terminology, but this is also applicable to Direct3D.
If this diagram seems to be a bit incomplete, you're on the right track! Where
are the lights, materials, and camera? They are all present, but only “in spirit”:
4. Here, we are concerned with a model that has only the geometric data necessary to
generate the target image, but the focus of a typical real-world application is an “appli-
cation model” (see Section 16.4) that encapsulates many different data types, graphical
and nongraphical.
