Real-time visualization of large detailed volumes on GPU

1. Interactive GigaVoxels Real-timevisualization of large detailed volumes on GPU Cyril Crassin,Fabrice Neyret, Sylvain Lefebvre INRIA Rhône-Alpes / Grenoble Universities

2. Volumetric representations for special effects • Volumetric special effects [KH05, KAP02] • Impressive natural scenes • Accurate director vision modeling • Realistic and controllable model • Voxel engines • Realistic global illumination models • Effects compositing • Particles, fluids, etc. • Unified rendering • Costly rendering solutions • Computations time • Memory occupation Source: [Digital Domain]

3. What we do • Voxels ray-casting for real-time scenes in Video Games • Full scenes representation • Multi-Scale: Large and detailed • Hyper-texture usage • Details enhancement on surface-based scenes • Procedural amplification • Advantages • Compact representation for very small details • Memory and rendering efficiency • Easy filtering and LOD • 3D Mip-Mapping • A lot of tricky effects becomes easy • Depth Of Field, volumetric light effects

4. Pictures and videos

5. Data structure • Hybrid data structure • N3-tree : Generalized Octree • Allow multi-scale subdivision depending on data densities • Limit tree depth for rendering performances • Acceleration structure • Empty space skipping • Dense, empty and detailed zones encoding • Small voxel grids in leafs • Rendering performances • Allow hardware filtering (Tri/Quadri-linear) • Mip-Mapping • Memory efficiency • Improve storage cost/structure cost efficiency • Local density hypothesis in complex zones • Data generation and transfer efficiency • Regular blocs generation/loading • Bloc transfers to the GPU

6. Rendering • Screen space volume ray-casting • Direct N3-tree traversal on GPU • Close to GPU Kd-tree traversal for triangle ray-tracing [EVG04,FS05,HSHH07] • Kd-Restart is the most efficient on current architectures (G80/G92/GT200) • Regular bricks rendering in leafs • Volumetric ray-casting [KW03, Sch05] • Hardware filtering • Mip-Mapping • Adaptive sampling • Distance dependant • Advantages • Good scaling on huge volumes • Low dependency on data volume, low overdraw, few geometrical manipulation • Early rays termination • Lighting • Classical Blinn-Phong per ray sample • On the fly computed or stored gradient data • Shadow maps

7. Out-of-core data streaming (1) • Produce / Store on GPU only data needed for the current point of view • Tree update and bricks loading in real time during exploration • GPU Cache mechanism • Pools of chunks • Implemented in texture memory • Sub-Texture update operations • Manually managed LRU mechanism • Time stamps updated during rendering • Via visibility mechanism • Tree storage: Nodes-Pool • Classical pointer-based structure • Small size 3D texture • Bricks storage: Bricks-Pool • Very large 3D texture • Usually the whole remaining GPU memory

8. Out-of-core data streaming (2) • Visibility based loading and LOD • Loaded tree branches subdivision/merging • Depending on brick distance to the view • A voxel project to one pixel constraint • Nodes visibility detection • Per ray needed nodes information provided by rendering • Screen space Nodes ID buffers • Fast stream compaction operation • Reduced Nodes ID buffer read back to CPU • Progressive loading • Upper nodes used while waiting for new data • Bricks kept in parents nodes • Min of 3 levels kept for mip-mapping implementation

9. Results • Scenes • Lizard • 2048^3 SP FLOAT, 32GB • Visible Man • 2048^3 RGBA8, 32GB • Bones field • 8192^3 ALPHA8, 512GB (1GB on disk) • Sierpinski sponge • 8.4M^3 ALPHA8 • Clouds • 512^3 SP FLOAT • Hyper-texture usage

10. Visible Man • 2048^3 RGBA8, 32GB, 20FPS@512^2

11. Lizard • 2048^3 SP FLOAT, 32GB, 15FPS@512^2

12. Sierpinski sponge • 8.4M^3 ALPHA8 procedural, 80FPS@512^3

13. Bones Field • 8192^3 ALPHA8, 512GB (1GB on disk)

14. Clouds • 512^3 SP FLOAT

15. G80 Reverse Engineering • Results • Dzdz • See online: • http://www.icare3d.org/GPU/CN08