Hybrid Ray Tracing of Massive Models Christian Lauterbach Dinesh Manocha UNC Chapel Hill 10/12/2009

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 Access pattern 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

Compact combined representation for hierarchy and ReduceM idea Triangle strips for ray tracing Two-level hierarchy: … High-level hierarchy (BVH, kd-tree, …) Compact combined representation 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 2 5 1 3

Representation Key idea: Can represent hierarchy via order of vertices 7 6 4 2 5 1 3

Representation Overall: Overhead for hierarchy 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

Construction overview Graph Adjacency Graph + Hierarchy Partitioning Sequences Ordering [1,3,2,4,6] [6,4,7,9,8] Triangle strips Strip output

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 Graph Graph + Hierarchy

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 Rendering performance 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 High quality 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 Problems: Hard-to-control errors Not robust 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: Example: Use ray tracing only to correct localized errors in GPU rendering algorithms Example: Shadow mapping Artifacts marked Final result

Ray generation and compaction Overview Hierarchy Geometry Frame buffer(s) unshaded FB with pixels marked Open ray buffer Traced ray results FB shaded with ray results Accuracy detection Ray generation and compaction Ray tracing Shading Main applications: Hard shadows Soft shadows Ambient occlusion

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 Result 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

Edge detection + conservative rendering 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 c) Actual geometry d) x

Ambient occlusion Error detection: Can partially ray trace 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 Ray organization 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?

Next up: 30 min. break Then: Sung-Eui Yoon: Data Management