1. RACBVHs: Random-Accessible Compressed Bounding Volume Hierarchies Tae-Joon Kim Bochang Moon Duksu Kim Sung-Eui Yoon KAIST (Korea Advanced Institute of Science and Technology) To appear at IEEE TVCG 09

2. Goal   Design a compact representation for interactive geometric and graphics applications of massive models   Support random access   Support various applications   Improve performance of applications

3. Motivation – Massive Models   Take high disk/memory spaces   Long data access time and low I/O performance St. Matthew model (372M triangles) Power plant with Hugo model (82M triangles)

4. Low Growth Rate of Data Access Speed Accumulated growth rate during 1999~2009 (log scale) Reducing data access time is critical! access speed disk access speed

5. Large Scale Applications   Ray tracing   Collision detection   Visibility queries   Dynamic simulation   Motion planning

6. Large Scale Applications   Common geometric data structures   Meshes   Acceleration hierarchies   k-d trees   Bounding volume hierarchies (BVHs)   Usually require random access on meshes and hierarchies Supporting random access is important!

7. Our Approach   Compress bounding volume hierarchies (BVHs) to reduce expensive data access time   Support random access   Support fast runtime decompression for performance improvements   Provide general API for various applications Random-Accessible Compressed BVHs

8. Ray Tracing of St. Matthew Model   128M triangles (4GB)   256M BVH (8GB)   9.6:1 compression ratios for the BVH over original uncompressed BVH   4.4:1 runtime performance improvement

9. Related Work   Mesh compression   Compression and random access   Tree and BVH compression

10. Mesh Compression   Designed to achieve a maximum compression ratio or efficient transmission   [Touma and Gotsman 98, Devillers and Gandoin 00]   Encode vertices   [Alliez and Desbrun 01, Kälberer et al. 05]   Encode edges   [Isenburg and Snoeyink 00]   Encode faces   [Gumhold and Strasser 98, Rossignac 99, Lee et al. 02] Do not directly support random access

11. Compression and Random Access   Quite common in video & audio encoding   E.g., MPEG video   Single or multi-resolution mesh compression   [Choe et al. 04, Yoon and Lindstrom 07, Choe et al. 09]   [Gobbetti et al. 06, Kim et al. 06]   Regular volumetric grids and images   [Ihm and Park 99, Rodler 99, Lefebvre and Hoppe 06]

12. Tree and BVH Compression   Tree compression   [Zaks 80, Zerling 85, Katajainen and Makinen 90]   Do not support random access   Encode bounding volumes   Quantization: [Cline et al. 06, Mahovsky 05, Terdiman 03]   Hierarchical encoding: [Rusinkiewicz and Levoy 00, Hubo et al. 06]   Encode tree structures   Assume a particular tree structure: [Lauterbach et al. 07 and 08]   Assume a particular layout for the tree: [Lefebvre and Hoppe 07]

13. Outline   Overview   Compression at preprocessing   Runtime data access framework   Results

14. Outline   Overview   Compression at preprocessing   Runtime data access framework   Results

15. Overview - Compression at Preprocessing   Decompose the BVHs into set of clusters   Compress each cluster separately   Each cluster serves as an access point C1C1 C2C2 C3C3 BVH

16. Overview - Runtime BVH Access Framework Main memory Applications External drive Compressed data pool Cached data Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n … 0 1 2 3 4 5 … n Offset table Request data Requested data Decompress using CPU power

17. Overview - Runtime BVH Access Framework Main memory Applications Compressed data pool Cached data Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n … 0 1 2 3 4 5 … n Offset table Request data Requested data Preloaded data

18. Outline   Overview   Compression at preprocessing   Runtime data access framework   Results

19. Bounding Volume Hierarchies (BVHs)   A node of BVHs has:   Indices of children nodes   A bounding volume (BV)   We use the axis-aligned bounding box (AABB) and a binary BVH   Due to its simplicity and the wide use   Can be easily extended to other types of BVs and k-ary BVHs BV Index of child node

20. Layouts of BVHs   Order of stored BV nodes in memory   Affect the performance of applications   Our method preserves the original layouts   Support any layouts   Use cache-efficient layouts for the best performance [Yoon and Manocha 06] Layout of a BVH

21. Cluster-based Compression   Cluster has:   Fixed number (e.g. 4K) of consecutive nodes in the layouts   Compute clusters with cache-coherent nodes   Implicitly performed by using cache-coherent layouts of BVHs C1C1 C2C2 C3C3

22. Encoding Bounding Volumes   Quantize min and max extents of BVs   Predict child BVs using their parent BV   Use the simple median prediction   Encode prediction errors   Use a dictionary-based encoder for fast decompression Parent BV Left BV Right BV Prediction error

23. Front-based Tree Structure Encoding   Maintain a front of nodes, one of whose child nodes is uncompressed yet   Average size of front: 13   4K nodes with cache-efficient layouts   Encode tree structures using only a few bits by connecting uncompressed nodes to a node in the front : Not yet compressed nodes : Compressed nodes n6n6 n6n6 n7n7 n7n7 n8n8 n8n8 n9n9 n9n9 n 10 n 11 n 13 n 14 n 12 n1n1 n1n1 n3n3 n3n3 n5n5 n5n5 n4n4 n4n4 n2n2 n2n2 n0n0 n0n0 n2n2 n2n2 n3n3 n3n3 n4n4 n4n4 n5n5 n5n5 Front 0 0 1 1 2 2 3 3 n1n1 n1n1 n3n3 n3n3 n5n5 n5n5 n4n4 n4n4 n2n2 n2n2 n0n0 n0n0

24. Outline   Overview   Compression at preprocessing   Runtime data access framework   Results

25.   Various applications can transparently access our representation using the following API: Applications BVH Access API Main memory External drive Compressed data pool Cached data Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n … 0 1 2 3 4 5 … n Offset table Decompression  GetRootIndex (.)  GetBV (.)  IsLeaf (.)  GetLeftChildIndex (.)  GetRightChildIndex (.)  GetTriangleIndex (.)

26. Outline   Overview   Compression at preprocessing   Runtime data access framework   Results

27. Compression Results Model Tri. (M) St. Matthew128 Iso surface102 Lucy28 Power plant13 CAD turbine1.8 Comp. ratio over uncomp. BVH 9.6:1 8.8:1 8.7:1 12:1 8.3:1 Compression bits per node TreeBV 8.6618.0 8.7520.3 8.7020.7 9.2212.3 9.1921.6  16 bits quantization for BVs  4K nodes per cluster Size (MB) of uncomp. BVH 7,811 6,254 1,684 778 108

28. Benchmark Applications   Ray tracing   Typically traverses large portions of BVHs   Collision detection   Accesses smaller and more localized portions of BVHs than ray tracing

29. Video for Benchmark Applications

30. Performance Improvement   Mainly due to higher I/O performance   Reduce the data size by using compression → Reduce or remove the expensive disk I/O time   Use CPU power to efficiently decompress the data

31. Parallel Random Access   Ray tracing of St. Matthew model (128M tri.) using only primary rays Speedup

32. Limitation   Lower (by up to 3%) the performance with small models which can fit in main memory   Overhead of identifying clusters   Less tight BVs due to a conservative quantization

33. Summary & Conclusion   Low storage requirement   Achieve up to a 12:1 compression ratio   Improved performance with random accessibility   Achieve a 4:1 runtime performance improvement   Wide applicability   Allows various applications to access the compressed BVHs   High scalability   Achieve a 3.6:1 performance improvement when using 4 threads over single thread

34. Future Work   Compact in-core representations   Apply to highly parallel architectures   GPU   Larrabee   Apply to levels-of-detail (LOD) hierarchies

35. Acknowledgments   Members of SGLab. in KAIST   Model contributors   Funding agencies   KAIST seed grant   Ministry of Knowledge Economy   Samsung   Microsoft Research Asia   Korea Research Foundation

36. Any Questions? Q & A Thank you!