ARUP; ISBN: 978-0-9562121-5-3 - CMBBE 2012 - Cardiff University

found that it is extremely difficult to identify useful transfer functions in this 4D space. The
importance function more naturally fits the natural methodology which people utilize when
confronted with the problem of visualizing time-dependent data. Namely, the extraction and
display of features of interest are utilized just as they are in existing packages for 3D
visualization, and then after this step, the user adjusts the parameters to explore the time
dimension. Currently, we enforce that the importance function maps to opacity or color
saturation. While we can of course define any such mapping, limited choice in this domain
seems to be more useful than the complex mappings available through the more general 4D
representation.
4 IMPLEMENTATION
As mentioned earlier, a problem with existing chronophotographic visualization methods is that
they require reconstruction of the entire volume on each change of the window function. This
effectively makes it impossible to explore a data set’s temporal evolution interactively. To
circumvent this drawback we propose a different approach which reconstructs the volume on the
fly while performing the ray cast traversal. This approach is based on a novel volume rendering
mode integrated into the out of core volume rendering system ImageVis3D 8 .
4.1. Bricking
The basic idea to visualize large volumes interactively on commodity hardware is to build a
bricked, level of detail (LoD) hierarchy of the data, such as an octree. Therefore, the volume is
first cut into smaller bricks, each representing a cube shaped sub-volume of the original data set.
To visualize a data set that is too large to fit into memory, the renderer traverses the data brick by
brick by submitting them to the graphics processing unit (GPU) and composites the visualizations
of each brick into the final image. This effectively decouples the size of the data set from the
available memory, which makes rendering of arbitrarily sized data possible.
This does not necessarily result in interactive performance, as a large number of bricks may have
to be traversed. To circumvent this issue, the volume is stored at multiple resolutions, a number
of down-sampled versions of the volume are generated in a pre-processing step. At run-time the
renderer first computes the most appropriate resolution based on the size of the volume on screen.
Next, it traverses only the bricks of that down-sampled resolution, considering only those bricks
that are in the view frustum. With this approach the amount of data required to render a frame is
effectively decoupled from the data set size, depending only on the screen resolution.
Our novel traversal is based on the same data structure as described above but instead of predetermining
a resolution to use and then traversing all visible bricks, we generate the list of
required bricks during the ray cast traversal. This allows us to discard many more bricks than
only view frustum culling would allow alone.
4.2. GPU Based LoD traversal
The idea is based on a GPU based multi-grid traversal algorithm, a 3D texture atlas based brick
storage, and a hashing function implemented on the GPU.