Graphics Reference
In-Depth Information
been computed. When the desired result is not available (or is out of date, as in the
dirty rectangle case) the algorithm has already invested the time for checking the
data structure and must now pay the additional time cost of computing the desired
result and storing it. Storing results of course increases the space cost of an algo-
rithm. Thus, reuse strategies can actually increase the total cost of rendering when
an animation fails to exhibit frame coherence.
When reuse produces a net time savings, it is reducing the
amortized
cost of
rendering each frame. The worst-case time may still be very high. This is problem-
atic in interactive applications, where inconsistent frame intervals can break the
sense of immersion and generally hampers continuous interaction. One solution is
to simply terminate rendering a frame early when this occurs. For example, the set
of materials (i.e., textures) used in a scene typically changes very little between
frames, so the cost of loading them is amortized over many frames. Occasionally,
the material set radically changes. This happens, for example, when the camera
crests a hill and a valley is revealed. One can design a renderer that simply renders
parts of the scene for which materials are not yet available with some default or
low-resolution material. This will later cause a visual pop (violating coherence of
the final image) when these materials are replaced with the correct ones, but it
maintains the frame rate. The worst case is often the first frame of animation, for
which there is no previous frame with which to exhibit coherence.
The first frame of animation is typically the most expensive. It may cost orders of
magnitude more time to render than subsequent frames because the system needs
to load all of the geometry and material data, which may be on disk or across a
network connection. Shaders have not yet been dynamically compiled by the GPU
driver, and all of the hardware caches are empty. Most significantly, the initial
“steady state” lighting and physics solution for a scene is often very expensive to
compute compared to later incremental updates.
Today's video games render most frames at 1
60 s intervals. Yet the
first
frame might take about one minute to render. This time is often concealed
by loading data on a separate thread in the background while displaying a loading
screen, prerendered cinematic, or menus. Some applications continuously stream
data from disk.
If we consider the cost of precomputed lighting, some games take
hours
to
render the first frame. This is because computing the global illumination solu-
tion is very expensive. The result is stored on disk and global illumination is
then approximated for subsequent frames by the simple strategy of assuming
it did not change significantly. Although games increasingly use some form
of dynamic global illumination approximation, this kind of precomputation for
priming the memoization structure is a common technique throughout computer
graphics.
Offline rendering for film is typically limited by exactly these “first frame”
problems. Render farms for films typically assign individual frames to different
computers, which breaks coherence on each computer. Unlike interactive appli-
cations, at render time films have prescripted motion, so the “working set” for a
frame contains only elements that directly affect that frame. This means that even
within a single shot, the working set may exhibit much less coherence than for
an interactive application. Because of this system architecture and pipeline, a film
/
30 s or 1
/
