An analysis of scalable GPU-based ray-guided volume rendering

Abstract

Volume rendering continues to be a critical method for analyzing large-scale scalar fields, in disciplines as diverse as biomedical engineering and computational fluid dynamics. Commodity desktop hardware has struggled to keep pace with data size increases, challenging modern visualization software to deliver responsive interactions for O(N3) algorithms such as volume rendering. We target the data type common in these domains: regularly-structured data. In this work, we demonstrate that the major limitation of most volume rendering approaches is their inability to switch the data sampling rate (and thus data size) quickly. Using a volume renderer inspired by recent work, we demonstrate that the actual amount of visualizable data for a scene is typically bound considerably lower than the memory available on a commodity GPU. Our instrumented renderer is used to investigate design decisions typically swept under the rug in volume rendering literature. The renderer is freely available, with binaries for all major platforms as well as full source code, to encourage reproduction and comparison with future research.

State‐of‐the‐Art in GPU‐Based Large‐Scale Volume Visualization

“…Choosing the optimal brick size depends on several criteria and has been studied in the literature [HBJP12, FSK13]. Small bricks support fine‐grained culling, which facilitates smaller working sets because less unnecessary data need to be fetched.…”

“…In contrast, modern single‐pass ray‐casters use smaller bricks (e.g. 32 3 voxels), or a hybrid approach where small bricks are used for rendering, and larger bricks are used for storage on disk [HBJP12, FSK13]. For 2D data acquisition modalities such as microscopy, hybrid 2D/3D tiling/bricking strategies have also been employed successfully.…”

“…In the context of large‐scale volume visualization, output‐sensitive approaches are often referred to as being ray‐guided (e.g. [CNLE09, Eng11, FSK13]) or visualization‐driven (e.g. [HBJP12, BHAA*13]).…”

Sparse PDF Volumes for Consistent Multi-Resolution Volume Rendering

“…The most common approach for handling large data in volume visualization is to use multi-resolution techniques [38], usually utilizing hierarchical data structures such as octrees [7, 14, 20, 31, 37] or 3D mipmaps [11, 16, 21]. These representations store iteratively pre-filtered and down-sampled versions of the original volume at discrete resolution levels.…”

“…Our current implementation uses a brick size of 64 3 voxels, plus four ghost voxels in each spatial dimension. Using smaller brick sizes incurs an impractical storage overhead for ghost voxels [11], while larger brick sizes lead to slower pre-processing, since Matching Pursuit has quadratic complexity. All bricks of level ℓ 0 are stored in the usual way, with one scalar per voxel.…”