1.1.5. VolumeViz LDM

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:

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.

LDM tiles loaded to display one slice of the volume.

Figure 1.10. LDM tiles loaded to display one slice of the volume.


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.

Different resolution levels (low to high).

Figure 1.11. Different resolution levels (low to high).


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.

Full data compared to LDM managed data.

Figure 1.12. Full data compared to LDM managed data.


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”.