Title: Quick-VDR: Interactive View-Dependent Rendering of Massive Models
1Quick-VDR Interactive View-Dependent Rendering
of Massive Models
- Sung-Eui Yoon
- Brian Salomon
- Russell Gayle
- Dinesh Manocha
- University of North Carolina at Chapel Hill
- http//gamma.cs.unc.edu/QVDR
2Goal
- Interactive display of complex and massive models
at high image fidelity - Models from CAD, scientific simulation, and
scanning devices - High primitive counts
- Irregular distribution of geometry
3CAD Model Power Plant
12 million triangles Irregular
distribution Large occluders
4Isosurface from Turbulence Simulation (LLNL)
100 million triangles High depth complexity Sma
ll occluders Many holes
5Scanned Model St. Matthew
372 million triangles Highly tessellated
6Problems of current representation
- High cost of refining and rendering the geometry
- High memory footprint
- Complicate integration with other techniques
- occlusion culling and out-of-core management
7Main Contribution
- New view-dependent rendering algorithm
Clustered Hierarchy of Progressive Meshes (CHPM)
Out-of-core construction and rendering
Integrating occlusion culling and out-of-core
management
8Realtime Captured Video Power plant
Pentium IV GeForce FX 6800 Ultra 1 Pixel of Error
9Previous Work
- Geometric simplification
- View-dependent simplification
- Out-of-core simplification
- Occlusion culling
- Hybrid algorithms
10Geometric Simplification
- Static Cohen et al. 96 and Erikson et al. 01
- View-dependent Hoppe 97 Luebke et al. 97 Xia
and Varshney 97 - Surveyed in Level of Detail book Luebke el al.
02
11View-Dependent Simplification
- Progressive mesh Hop96
- Merge tree Xia and Varshney 97
- View-dependent refinement of progressive meshes
Hoppe 97 - Octree-based vertex clustering Luebke and
Erikson 97 - View-dependent tree El-Sana and Varshney 99
- Out-of-core approaches Decoro and Pajarola 02
Lindstrom 03
12Out-of-core Simplification
- Static Lindstrom and Silva 01 Shaffer and
Garland 01 Cignoni et al. 03 - Dynamic Hoppe 98 Prince 00 El-Sana and Chiang
00 Lindstrom 03
13Occlusion Culling
- A recent survey is in Cohen-Or et al. 03
- Image-based occlusion representation
- Greene et al 93, Zhang et al, 97, Klosowski and
Silva 01 - Additional graphics processors
- Wonka et al. 01, Govindaraju et al. 03
14Hybrid Approaches
- Combine model simplification and occlusion
culling techniques - UC Berkeley Walkthrough Funkhouser 96
- UNC MMR system Aliaga 99
- Integrate occlusion culling with view dependent
rendering - El-Sana et al. 01 Yoon et al. 03
15Outline
- CHPM representation
- Building a CHPM
- Interactive display
- Implementation and results
- Conclusion and future work
16Outline
- CHPM representation
- Building a CHPM
- Interactive display
- Implementation and results
- Conclusion and future work
17Clustered Hierarchy of Progressive Meshes (CHPM)
- Novel view-dependent representation
- Cluster hierarchy
- Progressive meshes
PM3
PM1
PM2
18Clustered Hierarchy of Progressive Meshes (CHPM)
- Cluster hierarchy
- Clusters are spatially localized mesh regions
- Used for visibility computations and out-of-core
rendering
19Clustered Hierarchy of Progressive Meshes (CHPM)
- Progressive mesh (PM) Hoppe 96
- Each cluster contains a PM as an LOD
representation
Vertex splits
PM
Base mesh
20Two-Levels of Refinement
- Coarse-grained view-dependent refinement
- Provided by selecting a front in the cluster
hierarchy
Front
21Two-Levels of Refinement
- Coarse-grained view-dependent refinement
- Provided by selecting a front in the cluster
hierarchy
Cluster-split
22Two-Levels of Refinement
- Coarse-grained view-dependent refinement
- Provided by selecting a front in the cluster
hierarchy
Cluster-split
Cluster-collapse
23Two-Levels of Refinement
- Fine-grained local refinement
- Supported by performing vertex splits in PMs
PM
24Simplification Error Bound
- Conservatively compute object space error bound
given screen space error bound - Perform two-levels of refinement based on the
error bound
25Main Properties of CHPM
- Low refinement cost
- 1 or 2 order of magnitude lower than a vertex
hierarchy - Alleviates visual popping artifacts
- Provides smooth transition between different LODs
26Video Comparison CHPM with Vertex Hierarchy
27Outline
- CHPM representation
- Building a CHPM
- Interactive display
- Implementation and results
- Conclusion and future work
28Overview of Building a CHPM
Input model
Cluster decomposition
Performed in out-of-core manner
Cluster hierarchy generation
Hierarchical simplification
CHPM
29Overview of Building a CHPM
Input model
Cluster decomposition
Cluster hierarchy generation
Hierarchical simplification
CHPM
30Cluster Decomposition
- Cluster
- Main unit for view-dependent refinement,
occlusion culling, out-of-core management - Spatially localized portion of the mesh
- Equally sized in terms of number of triangles
31Cluster Decomposition
- Similar to Ho et al. 01 Isenburg and Gumhold 03
Graph between cells
32An Example of Cluster Decomposition
Each cluster contains 4K triangles
33Overview of Building a CHPM
Input model
Cluster decomposition
Cluster hierarchy generation
Hierarchical simplification
CHPM
34Cluster Hierarchy Generation - Properties
- Nearly equal cluster size
- High spatial locality
- Minimum shared vertices
- Balanced cluster hierarchy
35Cluster Hierarchy Generation - Algorithm
- Node
- Corresponds to a cluster
- Weighted by the number of vertices
- Edge
- Made if clusters share vertices
- Weighted by the number of shared vertices
36Cluster Hierarchy Generation - Algorithm
2nd level clusters
Root cluster
3rd level clusters
Leaf clusters
37Overview of Building a CHPM
Input model
Cluster decomposition
Cluster hierarchy generation
Hierarchical simplification
CHPM
38Out-of-core Hierarchical Simplification
- Simplifies clusters in a bottom-up manner
39Out-of-core Hierarchical Simplification
- Simplifies clusters in a bottom-up manner
PM5
PM4
PM1
PM2
PM3
40Boundary Simplification
Boundary constraints
41Boundary Simplification
E
F
42Boundary Constraints
- Common problem in many hierarchical
simplification - Hoppe 98 Prince 00 Govindaraju et al. 03
- Degrades the quality of simplification
- Decrease rendering performance at runtime
- Aggravated as a depth of hierarchy increases
43Boundary Constraints
44Boundary Constraints
45Cluster Dependencies
- Replaces preprocessing constraints by runtime
dependencies
46Cluster Dependencies
dependency
E
F
C
B
A
D
Cluster hierarchy
47Cluster Dependencies
dependency
E
F
C
B
A
D
Cluster hierarchy
48Cluster Dependencies at Runtime
Force cluster-split
Cluster-split
dependency
E
F
C
B
A
D
Cluster hierarchy
49Cluster Dependencies
92 triangles reduced
227K triangles
19K triangles
After posing cluster dependencies
50Outline
- CHPM representation
- Building a CHPM
- Interactive display
- Implementation and results
- Conclusion and future work
51View-Dependent Refinement
Traverse and update previous active cluster list
Active Cluster List (ACL)
52View-Dependent Refinement
cluster-split
53View-Dependent Refinement
cluster-collapse
54View-Dependent Refinement
The PM contained within acluster is refined
prior torendering
55Occlusion Culling
- Exploit temporal coherence
- Use visible clusters from the previous frame as
potentially visible set (PVS) in the current
frame - Cluster bounding boxes tested using occlusion
queries
56Rendering Algorithm
Traverse the ACL and apply split and
collapseoperations
1. Refine Active ClusterList
PVS is rendered. The depth map is the occlusion
representation
2. Render PVS as anoccluder set
Test boxes of clusterson ACL using occlusion
queries
3. Compute new PVS and newly visible set
Rendering newly visible set completes the final
image
4. Render newly visible set
57Out-of-core Rendering
- Entire hierarchy stored in memory
- Takes 5MB in St. Matthew model
- PMs stored on disk
58Out-of-core Rendering
- Fetch PMs as necessary
- Buffer for LOD Changes
- Latency for visibility events
- PMs replaced using LRU policy
59LOD Prefetching
Not Visible
Visible
LOD Prefetched
Front
60Visibility Prefetching
- Occlusion events are difficult to predict
- We use a frame of latency to reduce stalling
- The rendering algorithm is reordered using a pair
of offscreen buffers
61Latency
Frame i1
Frame i
1. Refine ActiveCluster List
1. Refine ActiveCluster List
2. Render PVS as anoccluder set
2. Render PVS as anoccluder set
3. Compute new PVSand newly visible set
3. Compute new PVSand newly visible set
62Outline
- CHPM representation
- Building a CHPM
- Interactive display
- Implementation and results
- Conclusion and future work
63Implementation
- Use GL_ARB_vertex_buffer_object to manage PM data
in GPU memory - 5 of PMs change refinement level
- Implemented on Windows XP
- Uses virtual memory through memory mapped files
Lindstrom and Pascucci 02
64Live Demo Isosurface
- Alienware laptop
- 3.2GHz Pentium IV PC with 2GB main memory
- Quadro FX Go5700 with 128MB GPU memory
65Live Demo St. Matthew
- Alienware laptop
- 3.2GHz Pentium IV PC with 2GB main memory
- Quadro FX Go5700 with 128MB GPU memory
66Test Configuration
- Dell Precision Workstations
- Dual 3.2 GHz Pentium IV PC with 1 GB main memory
- GeForce FX 6800 Ultra with 128MB of video memory
67Processing Time and Storage Requirement
Processing 30M triangles per an hour
Model Triangles (M) Memory footprint used (MB) Processing Time (hour)
Power plant 12.8 32 0.5
Isosurface 100 256 2.8
St. Matthew 372 512 10.2
68Processing Time and Storage Requirement
- CHPM requires 88MB per million vertices
- Low compared to 224MB (Hoppes VDPM) and 108MB
(XFastMesh) - Compression on PMs can further improve the memory
overhead and storage overhead
69Runtime Performance
Model Pixels of error Frame rate Memory footprint Avg Tris
Power plant 1 28 400MB 542K
Isosurface 20 27 600MB 819K
St. Matthew 1 29 600MB 850K
Image resolution is 512 512
70Timing Breakdown
Model Rendering Occlusion Culling Refinement
Power plant 86 13 1
Isosurface 94 5 1
St. Matthew 94 4 2
71Refinement Comparison
1M Triangle Isosurface
Method Num Dependency Checks Total Refinement Time
Vertex Hierarchy 4.2M 1,065 msec
CHPM 223 28 msec
38X speedup
72Frame Rate - Isosurface
2X speedup
73Limitations
- Latency
- Reduces stalls but no guarantee
- Excludes latency-sensitive applications
- Requires high temporal coherence
74Advantages
- Refinement time
- Performance comparable to static LOD systems
- Combines out-of-core, VDR, and occlusion culling
- General
- CAD, scanned, isosurface models
75Conclusion
- Quick-VDR view-dependent rendering of massive
models - Generates crack-free and drastic high quality
simplification by cluster dependencies - Provides two levels of refinement using CHPM
- Applies to a wide variety of massive models
76Ongoing and Future Work
- Compression
- Consider dynamic effects
- Shadows
- Lighting
- Occlusion event prediction
77Application to Collision Detection
- Fast Collision Detection Between Massive Models
Using Dynamic Simplification - Presented in Symposium of Geometric Processing,
2004
78Acknowledgements
- Anonymous donor for power plant model
- LLNL ASCI VIEWS for isosurface model
- Digital Michelangelo Project at Stanford
University for the St. Matthew model
79Acknowledgements
- DARPA
- Army Research Office
- Intel Corporation
- Office of Naval Research
- National Science Foundation
80Acknowledgements
- Naga Govindaraju
- Martin Isenburg
- Stefan Gumhold
- Mark Duchaineau
- Peter Lindstrom
- Members of Walkthru group
81Questions?
Project URL http//gamma.cs.unc.edu/QVDR
82Quick-VDR Interactive View-Dependent Rendering
of Massive Models
- Sung-Eui Yoon
- Brian Salomon
- Russell Gayle
- Dinesh Manocha
- University of North Carolina at Chapel Hill
- http//gamma.cs.unc.edu/QVDR
83Realtime Captured Video ST. Matthew
Pentium IV GeForce FX 6800 Ultra 1 Pixel of Error
84Comparison with TetraPuzzles
TetraPuzzles Quick-VDR
Representation Hierarchies of tetrahedron, close to static LOD CHPM, close to VDR
Handling boundary constraints (implicit) dependencies Using cluster dependencies
Models scanned models Wide variety of models
Occlusion culling Hasnt been tested Yes
85Live Demo Power plant
- Alienware laptop
- 3.2GHz Pentium IV PC with 2GB main memory
- Quadro FX Go5700 with 128MB GPU memory