Graphics Reference
In-Depth Information
• The tasks are not necessarily sequential; the use of parallel computation
may be possible for some tasks.
• The order in which we show these tasks is conceptual and not necessarily
adhered to by actual software/hardware.
• Some types of tasks may be split across several software/hardware mod-
ules, and (for extremely high scalability) across multiple CPUs and GPUs.
• We've not discussed GPU internals here; consult Chapter 38 for a discus-
sion of modern graphics hardware.
With this in mind, let's next turn our attention to the CPU-side software stack,
in particular the four-level stack, which includes a retained-mode middleware
layer designed to handle a large proportion of the AMIP's duties.
You have now been introduced to two abstraction levels for 3D graphics specifica-
tion: immediate mode (IM) and the higher-level retained mode (RM). You already
know that two key responsibilities of the RM layer are to provide for storage of a
scene graph, and to provide functionality to traverse the scene graph to generate
the instructions to be sent to the IM layer to produce the image.
Additionally, in Section 16.2.9, we noted that an application built directly
atop the IM layer typically necessarily contains custom-built modules duplicat-
ing basic RM functionality, simply because scene storage (and converting such
into an image) is so commonly needed in graphics applications.
Let's take a more complete look at the functionality of RM middleware. An
RM-based application extracts information from the application model, and uses
the RM API to construct the scene graph that resides in the middleware layer.
Some of the programmer conveniences gained by the middleware's maintenance
of the scene description include
• Object-oriented representation of key 3D graphics concepts (primitives,
transforms, materials, textures, camera, lights), providing programmers
with an intuitive API for setting up scenes
• Support for hierarchical modeling
• Support for dynamics through incremental editing of the scene description
• Support for hierarchical pick correlation
These conveniences are found in virtually all RM middleware; however, in
addition to these features, RM middleware designed for optimal performance
optionally can perform any of the post-application-model AMIP optimization
tasks listed in Section 16.4.2, as shown in Figure 16.10. Many RM layers per-
form very little optimization, some are designed for optimal scalability and per-
formance, and some are simply conveniences offering no optimization at all. (For
specifics, visit the online materials for this chapter, which contain a curated list of
scene-graph platforms.)
16.4.3.1 Optimization via Acceleration Data Structures
To achieve performance gains, some RM implementations build acceleration data
structures (described in Section 16.4.2.3) to store information useful for optimiza-
tion. Designing the software logic that maintains these data structures—illustrated
in Figure 16.11 and covered throughout Chapters 36 and 37—is a nontrivial task,
