Graphics Reference
In-Depth Information
16.4.3.2 Optimization of Static Scene Portions
An initially counterintuitive but then “obvious” maxim about scene graphs, prof-
fered by Henry Sowizral, the designer of Java3D (a pioneering RM platform in
terms of optimization support), is simply:
Traversal of a scene graph is expensive
and should be avoided to the fullest possible extent.
In particular, during real-time animation sequences, it is untenable for the
scene graph to be retraversed for each individual frame of the animation. A scal-
able scene-graph platform thus minimizes traversal by performing tasks of the
type mentioned in Section 16.4.2.3:
• Identifying—either automatically or via application-provided “hints” such
as those in Java3D—graph nodes with static content
• Generating and caching acceleration structures for such “subgraphs”
• And not allowing dynamic components in the scene to affect these cached
acceleration structures (which would lead to a high frequency of unneces-
sary cache invalidations)
When using an RM layer, you can assist the middleware with this task by
isolating static from dynamic components in the scene graph. For example, if
the root node's first child is a node
X
containing all static parts of the scene,
the subgraph rooted by
X
need be traversed only once, and that traversal will
prepare the acceleration data structures that provide for efficient generation of
that part of the scene. The remaining children of the root would be marked as
dynamic and not allowed to alter the acceleration structures for the static portion of
the scene.
In an application that allows the viewer to travel through a static scene the
entire scene graph can be handled in this way—that is, traversed exactly once to
set up the acceleration structures that will efficiently generate each frame of the
animation.
It is interesting to note that the generation and caching of the acceleration
structures often involves “flattening” the scene-graph hierarchy, to eliminate
traversal dependencies. Why? Well, remember Sowizral's admonition:
Avoid
traversal!
The goal of the acceleration structures is to give the optimization
algorithms rapid access to ready-to-use data needed for their operation; to require
the optimization logic to traverse the scene-graph hierarchy in order to interpret
the acceleration data would be a serious slowdown.
16.4.3.3 Costs and Disadvantages of Retained-Mode Middleware
The benefits provided by an RM layer come at a cost. Development-related costs
include the learning curve associated with the package's API, and the time needed
to gain the experience required to efficiently diagnose and repair bugs during
development. (Of course, there is also a financial cost for commercial middleware
products.)
Runtime costs include both CPU-side memory and processor usage, primarily
in these two categories.
1. The scene graph itself is stored on the CPU side and its memory require-
ments can be nontrivial for highly complex scenes. Moreover, if the AM is
predominantly geometric itself, the scene graph might be considered quite
redundant with the AM.
