390 likes | 423 Views
This talk discusses the motivation behind ray tracing, memory issues, and hybrid rendering approaches for ray tracing of massive models. It explores the ReduceM idea which utilizes triangle strips for ray tracing and compact representation for hierarchy and geometry. The talk also covers representation, traversal and intersection techniques, construction algorithms, and key results and comparisons.
E N D
Christian LauterbachDineshManochaUNC Chapel Hill 10/12/2009 Hybrid Ray Tracing of Massive Models
Motivation: Ray Tracing • As a visualization method • General and robust solution for light transport • Transparency, refraction, reflection • Lighting: shadows, indirect lighting, … • Performance logarithmic with model complexity
This talk • Memory issues for ray tracing of massive models • Hybrid rendering approaches
Problem: Memory • Memory overhead • Any object can be accessed by ray at any time • Need to store acceleration structure • Access pattern • Low locality • High number of cache misses • 3 orders of magnitude ~ disk vs. memory speed
Massive models: ReduceM • Goals: • Compact representation for hierarchy and geometry • Low rendering performance overhead
… … … ReduceM idea • Triangle strips for ray tracing • Two-level hierarchy: High-level hierarchy(BVH, kd-tree, …) Compact combinedrepresentation for hierarchy and geometry
ReduceM • Main features: • Compact ReduceM representation • Fast traversal and intersection of strips • Construction of triangle strips optimized for ray tracing
Representation • Based on triangle strips • Encode hierarchy on top as efficiently as possible 7 6 4 5 2 1 3
Representation • Key idea: • Can represent hierarchy via order of vertices 7 6 4 5 2 1 3
Representation • Overall: • Store vertices in order that defines hierarchy • Store local indices to define strip Sufficient both for triangle intersection and hierarchy traversal • Overhead for hierarchy • Local vertex indices • Some vertices stored twice (about 1.5-3%)
Traversal and intersection • Ported ray packet techniques to ReduceM • New possibilities: • Larger packet size for high-level hierarchy • Share edge results for triangle intersection • Intersection of single ray with multiple edges • Up to 90% higher ray tracing performance [Lauterbach et al. 07]
Construction • Many algorithms for triangle strip generation for GPU rasterization • Different criteria for ray tracing • Length compression ratio • Spatial coherence ray tracing performance
Graph Graph + Hierarchy Sequences Triangle strips [1,3,2,4,6][6,4,7,9,8] Construction overview Adjacency Partitioning Ordering Strip output
Graph Graph + Hierarchy Construction algorithm • Our approach: • Strip generation using surface area heuristic information • Partitioning: • generate ideal hierarchy • Ordering: • Use hierarchy as reference to evaluate possible triangle sequences • Iteratively try to combine sequences Partitioning Ordering
Results • Tested on set of massive models • All benchmarks are fully in-core[Lauterbach et al. 07, Lauterbach et al. 08] St. Matthew (372M) Powerplant (12.7M) Double Eagle (82M) Boeing 777 (360M) Build time: 1h 36m Build time: 5m Build time: 33m Build time: 1h 50m
Key results • Memory footprint • Reduced by up to 80% compared to standard kd-tree or BVH • Rendering performance • Optimized strips: up to 58% higher compared to rasterization strips • Overall performance comparable to kd-tree • Higher for some large models • Single ray performance up to 90% higher
Results • Logarithmic performance maintained
Comparison • Most similar to compressed BVH approaches [Mahovsky 05, Cline et al. 06] • Higher compression of hierarchy • But: • Does not change geometry footprint • Rendering times 40-60% with best compression • Worst for single rays
State-of-the-art • Basic visualization: fast enough • E.g. visibility, shading, hard shadows • One or several rays / pixel • Decent lighting: barely interactive (~1-5 fps) • E.g. soft shadows, simple ambient occlusion • <= 16 rays / pixel • High-quality: non-interactive (<< 1fps) • E.g. indirect lighting, “good” lighting, anti-aliasing • Tens to hundreds of rays / pixel
GPU Rendering • Fast visibility • Levels-of-detail, mesh layouts, compression, out-of-core rendering, … • High quality • Cheap antialiasing, shading, …
Hybrid rendering • One solution until hardware nirvana • Use GPU rendering where it makes sense • Use ray tracing otherwise • Try to reduce ray workload
Future architectures • Graphics pipelines are getting more flexible • GPUs • DirectX 11 compute shaders • More configurable stages • Intel Larrabee • Software pipeline
Hybrid ray tracing • Already widely used in GPU ray tracing • Rasterize visibility, add reflection, refraction and shadows with ray tracing [Reiter-Horn et al. 07] • Counter-argument • When ray tracing 100+ rays/pixel, why care about one more for visibility?
Selective ray tracing • Motivation: • GPU ray tracing feasible, but still orders of magnitude slower than rasterization • Want to use ray tracing for ‘interesting’ effects • Accurate hard/soft shadows • Ambient occlusion • Indirect lighting, … • But: Hardware not yet fast enough to trace enough rays
GPU algorithms Hard shadows Soft shadows Ambient occlusion (from [Lloyd 08]) (from [Laine et al. 05]) (from [Bavoil et al. 08]) • Problems: • Hard-to-control errors • Not robust • Not scalable
Selective ray tracing • Idea: • Use ray tracing only to correct localized errors in GPU rendering algorithms • Example: Shadow mapping Artifacts marked Final result
Overview • Main applications: • Hard shadows • Soft shadows • Ambient occlusion HierarchyGeometry Open ray buffer Traced ray results FB shaded with ray results Frame buffer(s) unshaded FB with pixels marked Accuracy detection Ray generationand compaction Ray tracing Shading
Massive model rendering • To use ray tracing, need to store geometry and hierarchy on GPU • Problem: even less memory than CPUs • ReduceM for GPU ray tracing • With minor modifications can also use directly use strip representation in GPU rendering
Shadow mapping • Shadow mapping algorithm • Renders scene from light into depth map • During rendering, reproject each pixel to light’s view and test whether occluded using map • Main source of error is mismatched sampling rate of shadow map • Result • Jagged shadow boundaries • Missed shadows
Shadow mapping Normal shadow mapping Edge detection Edge detection + conservative rendering
Soft shadows • Also identify and ray trace penumbra regions • Our solution: • Project area light onto each shadow map pixel • Mark all pixels in that projected region
Ambient occlusion • Ambient occlusion • Screen-space ambient occlusion • Reconstruct local geometry from depth buffer neighborhood: R x R
Ambient occlusion • Problems: • Information in depth buffer insufficient • Result: missing shadows or view-dependent changes in occlusion a) b) x x Actual geometry c) d) x
Ambient occlusion • Error detection: • Find discontinuities in neighborhood • If found, revert to ray tracing • Can partially ray trace • E.g. discontinuity in one quadrant? Still use screen-space solution for others
Shadow results • Rendering of complex models with accurate shadows on current GPU • E.g. Powerplant • Performance: • ~3-5 times faster than full ray tracing • ~2-3 times slower than original algorithm • Accuracy • Virtually identical to ray traced solution
Shadow results Hard shadows, real-time capture Soft shadows, ~2 fps
Challenges • Integrate with GPU rendering • Levels-of-detail • Shared representations for rendering • Ray organization
Future work • GPU rendering as dense visibility sampling • Can use for more general purposes? • Hybrid rendering representations • How to modify future rendering pipelines?