Graphics Reference
In-Depth Information
2. The acceleration structures/caches used internally by the middleware's
optimization modules use CPU-side memory and can be nontrivial in size
for highly complex scenes.
It is interesting to reexamine our camel-modeling application, and com-
pare our OpenGL function-based approach with a scene-graph approach such as
that presented in Chapter 6. Consider a desert scene with 100 camels moving as
a caravan. What are the CPU-side memory requirements for each of these
strategies?
In Section 6.6.4, we showed how reuse of the composite components at dif-
ferent levels of the hierarchy affected the number of nodes in the scene graph. We
saw that component reuse resulted in resource savings at the cost of loss of detail
in the animation control. Ultimately, if our target animation quality requires indi-
vidual control over every joint in the scene, reuse of composite components is not
possible and the cost of the scene-graph storage is at its highest. (Of course, the
mesh data associated with the atomic components can be shared without any loss
of control over joint animation.)
By contrast, it would at first glance appear that the function-based approach of
Section 16.2.9 is highly scalable. The cost of the representation of the hierarchy's
design
is indeed constant, since it lives in the compiled executable and is unrelated
to camel count. Indeed, if the goal was to render 100 camels in random locations
for a still-frame rendering, one could write a program calling the
Camel()
function
100 times with random nonretained instance and joint transforms. The CPU RAM
cost would be truly a constant, unrelated to camel count. However, if animation
of the caravan is required, at the very least the application model must include
per-camel location/orientation status. And if complete control over each joint is
required for high-quality animation, this AM-resident storage of camel informa-
tion (with location, orientation, and status at all joints) starts looking more and
more like a scene graph. The higher the requirement for control over the scene's
details, the more the AM will start having many of the qualities of scene graph,
and the more time the development team will spend building what is essentially a
custom scene graph and custom AMIP.
A development team choosing between constructing a custom AMIP and
using a middleware platform to offload a lot of responsibility should take these
costs into account. As noted, some of the costs (e.g., acceleration data structures)
are unavoidable; however, a custom AMIP does offer the possibility of avoiding
duplication of AM data. The redundancy of a middleware-resident copy of AM
data, and its CPU-side cost in terms of both memory and processing cycles, is seen
by many as a fundamental problem with general-purpose, domain-independent
scene-graph middleware technology.
Yet, the conveniences of a hierarchical scene-graph and the automation of
AMIP optimization are highly beneficial, and thus a more efficient platform archi-
tecture (described in the next section), which merges the AM and scene-graph
data, has become popular in some specialized domains.
In a few key application domains with large developer communities, the need for
the convenience and optimizations of a scene-description database, coupled with
the need for solutions to other problems common to that domain, have led to the
development of what we call
graphics application platforms.
