1. Click to edit Master title style HCCMeshes: Hierarchical-Culling oriented Compact Meshes Tae-Joon Kim 1, Yongyoung Byun 1, Yongjin Kim 2, Bochang Moon 1, Seungyong Lee 2, and Sung-Eui Yoon 1 1 KAIST 2 POSTECH

2. Motivation – Massive Models   Take high disk/memory spaces   Long data access time and low I/O performance Lucy model (28 M triangles) St. Matthew model (372 M triangles) 2/35

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

4. Large Scale Applications   Ray tracing   Collision detection   Non-photorealistic rendering   Dynamic simulation   Motion planning 4/35

5. Large Scale Applications   Common geometric data structures   Meshes   Acceleration hierarchies (e.g., k-d trees, bounding volume hierarchies (BVHs))   Random hierarchical traversal is necessary 5/35

6. Goal   Design a compact mesh representation for interactive geometric and graphics applications of massive models   Support hierarchical random access and culling   Support various applications   Improve performance of applications 6/35

7. Handling Massive Models   Sufficient memory Main memory Applications Data pool Requested data Request data Original data 7/35

8. Handling Massive Models   Insufficient memory   Out-of-core technique: [Silva et al. 02, Cignoni et al. 03] Main memory Applications External drive Original data Cached data Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n Requested data Request data Original data 8/35

9.   Compress data for reducing expensive I/O thrashing Handling Massive Models Main memory Applications External drive Cached data Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n Decompress using CPU Data pool Compressed data Requested data Request data Original data Compressed data 9/35

10. Requested data Request data Handling Massive Models Main memory Applications External drive Cached data Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n Decompress using CPU power Data pool Compressed data pool   Compress data for reducing expensive I/O thrashing   Random-accessible compression   For meshes: [Yoon et al. 07, Choe et al. 09, Kim et al. 06]   For hierarchies: [Melero et al. 08, Kim et al. 10]   [Yoon et al. 07] & [Kim et al. 10] improve ray tracing performance by a factor of 4 compared to uncompressed data   20 : 1 compression ratio 10/35

11. Applications Requested data Request data External drive Data pool Compressed data pool Limited Performance Improvements Main memory Cached data Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n   Decompression speed is slow   Memory caches uncompressed data: cache misses Decompress using CPU 11/35

12. Our Approach Main memory Applications External drive Cached data Data pool Compressed data pool Requested data Request data High performance decompression Original data Compressed data Intermediate compressed data i-HCCMeshes o-HCCMeshes Low performance decompression 12/35 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 Cluster c n … Cluster c 0 Cluster c m Cluster c 8 Cluster c 9 Cluster c 10 Cluster c 11 Cluster c 12 Cluster c 13 … Cluster c m Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 Cluster c 6 Cluster c 7 Cluster c 8 Cluster c 9 Cluster c 10 Cluster c 11 Cluster c 12 Cluster c 13 … Cluster c 0 Cluster c 1 Cluster c 2 Cluster c 3 Cluster c 4 Cluster c 5 … Cluster c n

13.   128 M triangles (5.6 GB)   256 M BVH (8 GB)   i-HCCMeshes (1.9 GB)   o-HCCMeshes (678 MB)   More than 100X speedup over uncompressed data by avoiding the disk I/O thrashing Ray Tracing of St. Matthew Model 13/35

14.   128 M triangles (5.6 GB)   256 M BVH (8 GB)   i-HCCMeshes (1.9 GB)   o-HCCMeshes (678 MB)   Captured in real time Ray Tracing of St. Matthew Model 14/35

15. Outline   Overview   i-HCCMesh representation   o-HCCMesh representation   Results 15/35

16. Outline   Overview   i-HCCMesh representation   o-HCCMesh representation   Results 16/35

17. … …   High-level BVH   Takes small memory   Used frequently   Low-level BVHs and sub- meshes   Take large memory   Less frequently used   Compress clusters only Overall Structure High-level BVH Low-level BVHs Clusters … … … BVH 17/35 Mesh Sub-meshes

18. High-level BVH Low-level BVH Overview - Runtime Access Framework … External drive Main memory o-HCCMeshes i-HCCMeshes (cached) … … … 18/35

19. Outline   Overview   i-HCCMesh representation   o-HCCMesh representation   Results 19/35

20. 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   We assume each leaf node contains a single triangle BV Index of child node 20/35

21. Encoding Bounding Volumes 10000111 v8v8 v5v5 10 Left BV = ~ Parent BV: Child BVs: Reuse mask: Additional vertices: Final child BVs: Parent BV Left BV Right BV min x min y max x max y v1v1 v2v2 v3v3 v4v4 v1v1 v5v5 v6v6 v7v7 v8v8 v2v2 v3v3 v4v4 00 Right BV v6v6 v7v7 v1v1 v2v2 v4v4 v3v3 v8v8 x y v6v6 v7v7 v5v5 v8v8 v6v6 v7v7 v5v5 v1v1 v2v2 v3v3 v4v4 v5v5 v6v6 v7v7 v8v8 v1v1 v6v6 v7v7 v5v5 v1v1 v6v6 v7v7 v5v5 v2v2 v4v4 v3v3 v8v8 v2v2 v4v4 v3v3 v8v8 21/35

22.   Horizontally partition into height of k   All sub-trees have same height k   Types of sub-trees’ structures are limited Encoding Tree Structure k … … … 22/35

23. Partitioning line 34 0 1 2 Encoding Tree Structure 2 0 1 Tree template ID Tree template (k = 2)   Encode only template IDs and inter connections 23/35

24. Outline   Overview   i-HCCMesh representation   o-HCCMesh representation   Results 24/35

25. Out-of-core Compression   It is not easy to further compress i-HCCMesh representation using general methods (e.g., gzip)   Each cluster is compressed independently for random access   Tree structures are encoded using our dictionary-based compression   We do not encode BVs   Reconstruct using tree structures and mesh information 25/35

26.   Mesh information is compressed following to the encoding layout   Triangle indices need not to be encoded   Order preserving mesh compression method is necessary   Streaming mesh [Isenburg et al. 05]   We modify steaming mesh to use our dictionary-based compression for fast decompression Out-of-core Compression Layout of a BVH Triangles 26/35

27. Outline   Overview   i-HCCMesh representation   o-HCCMesh representation   Results 27/35

28. Compression Results Model Tri. (M) St. Matthew372 Lucy28 David8 Iso-surface102 CAD turbine2 Size (MB) of uncomp. data 40,459 3,008 897 11,148 192 i-HCCMesh Size(MB)Ratio 5,4747.4 : 1 4137.3 : 1 1227.4 : 1 1,5547.2 : 1 26.47.3 : 1 o-HCCMesh Size(MB)Ratio 1,73823.3 : 1 15319.7 : 1 4519.9 : 1 65717.0 : 1 1117.4 : 1  i-HCCMesh and o-HCCMesh achieve 7.3 : 1 and 19.5 : 1 compression ratio on average 28/35

29. Benchmark Applications   Whitted-style ray tracing   Non-photorealistic rendering   LOD-based ray tracing   Collision detection   Photon mapping 29/35

30. Video for Benchmark Applications 30/35

31.   Mainly due to higher I/O performance   Reduce the data size by using compression → Reduce or remove the expensive disk I/O time Performance Improvement 31/35

32. Limitations   Compression ratios of k-ary trees may be lower than binary trees   Many more templates   Runtime performance overhead for small models   33% for the Whitted-style ray tracing over uncompressed data 32/35

33. Summary & Conclusion   A novel, compact mesh representations   Compressed by tightly coupling meshes and BVHs   Supports hierarchical random access and culling   Can be used with many applications   Low storage requirement   Achieve 7.2 : 1 (i-HCCMesh) and 20.9 : 1 (o-HCCMesh) compression ratio over uncompressed data   High performance   Handle 7 times bigger model without I/O than uncompressed data   60 times faster than uncompressed data even much bigger models that causes disk I/O acccess 33/35

34. Acknowledgments   Members of SGLab. in KAIST   Model contributors   Funding agencies   MKE, MCST, KEIT, IITA, KOCCA   Microsoft Research Asia   Korea Research Foundation 34/35

35. Any Questions? Q & A Thank you! 35/35