One of the most powerful features of VolumeViz is inside the library and requires no special action to enable. This is the volume data management system called LDM. The benefits of LDM include:
Adaptive data management for small to extremely large volumes
Any portion of the volume, up to the full volume, can be displayed immediately.
Automatically refines the displayed image up to limits of memory and GPU.
Does not load unnecessary data (maximizes use of available memory).
Adaptive performance management for low- to high-end machines
Interactive navigation of extremely large volumes, i.e. slices, probes, camera, etc can be moved smoothly at all times.
Multi-threading and GPU computing used to full advantage.
Scalable performance (improves with more memory, more cores, more GPU, etc).
Supports computation in addition to rendering.
The LDM data manager manages blocks of data called tiles, which are typically 64 or 128 voxel cubes. This allows for efficient random access to any part of the volume, but avoids loading unnecessary data. In the figure below you can see conceptually how tiles are loaded to display a single slice of the volume. The slab of tiles shown can be used to display any slice within that range of voxels. However LDM continues working in the background to load additional tiles (up to the specified memory limit) that may be needed to display other slices or other primitives. LDM data is multi-threaded and asynchronous so it can (optionally) continue even while rendering and interacting with the scene. We will be referring to tiles of data frequently when we discuss some of the advanced rendering options. Note that VolumeViz still allows the application to access data, on the CPU or GPU, as if it was a contiguous block of data.
In addition to managing the tiles of original data, what LDM calls the full resolution data, LDM also manages multiple levels of reduced resolution data. This allows a small but important improvement to the application user’s experience. An initial image can be displayed very quickly even for a very large volume because VolumeViz initially loads a low resolution version of the data. However the real value of multi-resolution data management is that it allows rendering to adapt to the available memory and GPU performance. For example when viewing the full volume and the volume is very large, it is often the case that multiple voxels map to each pixel on the screen, so VolumeViz can effectively render the same image using lower resolution data which uses less memory and renders faster. VolumeViz can also use multiple levels of resolution in the same image in order to prioritize the use of available memory toward the most important primitives or regions in the scene. For example, when volume rendering, VolumeViz can automatically use lower resolution data (if necessary) for the portions of the volume that are farthest away from the camera (mostly obscured by nearer data). Similarly VolumeViz can automatically give higher priority to tiles needed for rendering slices compared to volume rendering (or the reverse). All these options can be controlled by the application.
The different levels of resolution form a hierarchy where full resolution data is at the bottom and each level higher contains one-eighth as many tiles and therefore one-eighth as many voxels. This data structure is called an “octree” in computer science. The tiles at the bottom of the hierarchy, called resolution level 0, are the octree “leaves” and contain full resolution data. The tiles in intermediate levels of the hierarchy are the octree “nodes” and contain sub-sampled data. The single tile at the top of the hierarchy is the octree “root” and contains a very low resolution representation of the entire volume. This is what allows VolumeViz to very quickly display an initial image of any size volume, because the initial image is based on loading this single tile at the top of the hierarchy. VolumeViz then rapidly loads tiles at higher and higher levels of resolution until the best possible image, given the available memory and GPU constraints, is displayed. As the view changes, primitives are added and removed, slices and probes are moved, etc, VolumeViz continually refines the best possible set of tiles in memory to optimize image quality. In the figure below you can see conceptually how the number of tiles decreases at each level, although each level spans the same extent in 3D space.
Information about the tile hierarchy can be queried using the utility class SoLDMTopoOctree, including the position of a specified tile, the id of the tile containing a specific voxel and so on. We will discuss this in more detail in Section 1.10, “Data Access and Computing”.