Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik Saarbrücken, Germany.

Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik Saarbrücken, Germany

Nov 3, 2004Afrigraph 2004 Tutorial A2 Outline Motivation: Why Ray Tracing for Massive Models ? Motivation: Why Ray Tracing for Massive Models ? Offline systems Offline systems –Pharr: Memory Coherent Ray Tracing –Kilauea: Data-parallelism with ray forwarding –Christensen: Multiresolution caching Interactive Systems Interactive Systems –Utah: Realtime Ray Tracing on Supercomputers Massively complex visualization applicationsMassively complex visualization applications –Saarland 2001: Distributed RTRT for Massive Models Cluster-based approach w/ demand loading, caching and reorderingCluster-based approach w/ demand loading, caching and reordering –Saarland 2004: Caching-based Massive Model Rendering Single-PC based w/ demand loading and proxies for missing dataSingle-PC based w/ demand loading and proxies for missing data Summary and Open Problems Summary and Open Problems

Nov 3, 2004Afrigraph 2004 Tutorial A4 Why Ray Tracing for Massive Models ? Summary Part I: Summary Part I: –Rendering time is linear in #triangles  Too many triangles take too long to render  Cannot render all triangles at interactive rates  Have to somehow reduce #triangles (culling, simplification, approximation,...)  … Entire argumentation chain depends on initial axiom “Rendering time is linear in #triangles” Entire argumentation chain depends on initial axiom “Rendering time is linear in #triangles” –But: Only applies to brute force rasterization, …

Nov 3, 2004Afrigraph 2004 Tutorial A5 Why Ray Tracing for Massive Models ? Summary Part I: Summary Part I: –Rendering time is linear in #triangles  Too many triangles take too long to render  Cannot render all triangles at interactive rates  Have to somehow reduce #triangles (culling, simplification, approximation,...)  … Entire argumentation chain depends on initial axiom “Rendering time is linear in #triangles” Entire argumentation chain depends on initial axiom “Rendering time is linear in #triangles” –But: Only applies to brute force rasterization, … –… NOT for ray tracing !

Nov 3, 2004Afrigraph 2004 Tutorial A6 Ray Tracing Simple Algorithm 1.) Create ray from eye through pixel

Nov 3, 2004Afrigraph 2004 Tutorial A7 Ray Tracing Simple Algorithm 1.) Create ray from eye through pixel 2.) Trace ray into scene

Nov 3, 2004Afrigraph 2004 Tutorial A8 Ray Tracing Simple Algorithm 1.) Create ray from eye through pixel 2.) Trace ray into scene –Find objects nearby ray (traverse spatial data structures) –Compute ray-object intersection tests –Determine closest hitpoint Grid (2D)Octree (2D)

Nov 3, 2004Afrigraph 2004 Tutorial A9 Simple Algorithm 1.) Create ray from eye through pixel 2.) Trace ray into scene 3.) Compute color of ray (“shade” the ray) –Maybe including secondary rays… (won’t discuss that here) Ray Tracing

Nov 3, 2004Afrigraph 2004 Tutorial A10 Simple Algorithm 1.) Create ray from eye through pixel 2.) Trace ray into scene 3.) Compute color of ray (“shade” the ray) 4.) Display final image Ray Tracing

Nov 3, 2004Afrigraph 2004 Tutorial A11 Simple algorithm, with many advantages Simple algorithm, with many advantages –Support for advanced shading and global illumination Not directly related to massive model rendering…Not directly related to massive model rendering… –Supports instantiation –Visibility culling built in –Occlusion culling built in, too Per pixel visibilityPer pixel visibility –Trivially parallelizable –Logarithmic scalability in scene size Due to traversal of (hierarchical) spatial acceleration structuresDue to traversal of (hierarchical) spatial acceleration structures Ray Tracing: Properties

Nov 3, 2004Afrigraph 2004 Tutorial A12 Simple algorithm, with many advantages Simple algorithm, with many advantages –Support for advanced shading and global illumination Not directly related to massive model rendering…Not directly related to massive model rendering… –Supports instantiation –Visibility culling built in –Occlusion culling built in, too Per pixel visibilityPer pixel visibility –Trivially parallelizable –Logarithmic scalability in scene size Due to traversal of (hierarchical) spatial acceleration structuresDue to traversal of (hierarchical) spatial acceleration structures  For complex models, „log scalability“ is most important ! Ray Tracing: Properties

Nov 3, 2004Afrigraph 2004 Tutorial A13 Ray Tracing: Log. Scalability Logarithmic scalability in practice: Logarithmic scalability in practice: –Example from Isosurface Ray Tracing (similar for polygons) –Marschner-Lobb dataset: Synthetically generated From 32x32x32 voxels (32kVox) to 1024x1024x1024 (1GVox)From 32x32x32 voxels (32kVox) to 1024x1024x1024 (1GVox)

Nov 3, 2004Afrigraph 2004 Tutorial A14 Ray Tracing: Log. Scalability Logarithmic scalability in practice: Logarithmic scalability in practice: –Example from Isosurface Ray Tracing (similar for polygons)  Rendering time *= 2, for scenesize *= 10^4.5 !

Nov 3, 2004Afrigraph 2004 Tutorial A15 Why use Ray Tracing for Massive Model Rendering ? Logarithmic scalability: Logarithmic scalability: –Essentially solves the complexity problem Number of triangles not the main problem any more…Number of triangles not the main problem any more…

Nov 3, 2004Afrigraph 2004 Tutorial A16 Why use Ray Tracing for Massive Model Rendering ? #Triangles not the main problem any more #Triangles not the main problem any more –Proof by example: “Sunflowers” scene ~one billion triangles~one billion triangles Plus shadows, textures, transparency, …Plus shadows, textures, transparency, … Rendered interactively on few PCsRendered interactively on few PCs

Nov 3, 2004Afrigraph 2004 Tutorial A17 Ray Tracing for Massive Model Rendering #Triangles not the main problem any more #Triangles not the main problem any more So, where’s the problem ? So, where’s the problem ?

Nov 3, 2004Afrigraph 2004 Tutorial A18 Ray Tracing for Massive Model Rendering #Triangles not the main problem any more #Triangles not the main problem any more So, where’s the problem ? So, where’s the problem ?  Main problem: Efficient scene storage and access !  The storage problem –“logarithmic cost”: assumes all data is in memory –“Sunflowers” example ? Only possible through instantiation  special case !Only possible through instantiation  special case ! –For general complex models: usually not the case Boeing 777: 40GB on diskBoeing 777: 40GB on disk Lawrence-Livermore dataset: 24 GB (already compressed)Lawrence-Livermore dataset: 24 GB (already compressed) – Full model actually 270x24GB (270 time slices)  Storage is worst indiv. problem of ray tracing MCMs.

Nov 3, 2004Afrigraph 2004 Tutorial A20 “Memory Coherent Ray Tracing” [Pharr, Siggraph97] Basic observation Basic observation –Ray tracing ideally suited for complex models –But: Complex scenes won’t fit into memoryComplex scenes won’t fit into memory Typical depth-first ray tracing destroys coherenceTypical depth-first ray tracing destroys coherence – W/ global illumination: Scene access usually (almost) random  Excessive OS paging and thrashing, huge rendering times… Basic idea Basic idea –Do “manual” (explicit) caching/paging on suitable entities –Reorder computations to achieve coherence Based on scheduler to minimize disk I/OBased on scheduler to minimize disk I/O  Avoid page thrashing, significantly improve performance

Nov 3, 2004Afrigraph 2004 Tutorial A21 Memory Coherent Ray Tracing - Reordering Computations Typical ray tracing approach: depth-first Typical ray tracing approach: depth-first –Trace first ray until hit point is found –Trace all secondary rays of first ray in depth-first manner –Start new pixel only after all of the old one’s rays are finished… Problem: Highly incoherent scene access Problem: Highly incoherent scene access –Primary ray of 2 nd pixel needs similar data as primary of 1 st pixel –But: Secondary rays of 1 st pixel have already swapped out data… Solution: Improve scene access coherence by reordering Solution: Improve scene access coherence by reordering –Explicit caching Know what’s in memory at what time !Know what’s in memory at what time ! –Reordering of rays Based on “ray scheduler” that tries to minimize I/OBased on “ray scheduler” that tries to minimize I/O  Trade uncontrolled OS paging for controlled disk I/O

Nov 3, 2004Afrigraph 2004 Tutorial A22 MCRT – Geometry Cache Caching framework Subdivide scene into grid of “voxels” Subdivide scene into grid of “voxels” –Each voxel small enough to fit into memory –Voxel contains all necessary data Triangles, vertices, local acceleration data structure,...Triangles, vertices, local acceleration data structure,... If triangle overlaps two voxels, replicate itIf triangle overlaps two voxels, replicate it  Voxel contains all data to trace a ray through it –Build voxels in preprocessing step, store on disk Perform explicit caching on these voxels Perform explicit caching on these voxels –Keep cache of currently loaded voxels (“geometry cache”) Use fixed-size cacheUse fixed-size cache –If new voxel needs to be loaded, discard old one. –Plus: texture cache, displacement cache, … (no details here)

Nov 3, 2004Afrigraph 2004 Tutorial A23 MCRT – Ray Scheduling Each ray consists of Each ray consists of –Origin, direction, current hit information, … –Ref. to pixel it belongs to –Weight factor that specifies how much ray may contribute to pixel Once ray hits emissive objectOnce ray hits emissive object – Add its contribution (ray weight * surface emission) to pixel  Rays can be traced in any order Store queue of “active” rays per voxel Store queue of “active” rays per voxel –I.e., list of all rays that demand intersection with that voxel –Perform scheduling based on voxel queue

Nov 3, 2004Afrigraph 2004 Tutorial A24 MCRT – Ray Scheduling Basic scheduling algorithm Basic scheduling algorithm Generate eye rays and place them into respective queue(s) While there are queued rays Choose a voxel to process Choose a voxel to process For each ray in voxel Intersect ray with voxel’s geometry If there is an intersection Run shader and compute BRDF Insert spawned rays into voxel’s queue (w/ proper weights) If surface is emissive, store contribution to image Terminate ray else Advance ray to the next voxel queue along its way

Nov 3, 2004Afrigraph 2004 Tutorial A25 Memory Coherent Ray Tracing Scheduling Overview

Nov 3, 2004Afrigraph 2004 Tutorial A26 MCRT – Results Reordering significantly improves coherence Reordering significantly improves coherence –Always work on similar rays (same queue) at same time In particular: First iteration  All primary rays in same queue !In particular: First iteration  All primary rays in same queue ! Scheduling can significantly reduce disk I/O Scheduling can significantly reduce disk I/O –Can prefer rays from voxels whose geometry is already loaded –When loading, can prefer voxels with many active rays Amortize loading cost over as many rays as possibleAmortize loading cost over as many rays as possible –Significantly less paging  Can efficiently ray trace scenes much larger than memory

Nov 3, 2004Afrigraph 2004 Tutorial A27 MCRT – Results  Can efficiently ray trace scenes much larger than memory –Lake scene, rendered using path tracing and environment illum. –MCRT: can be rendered at 10% cache size –Keep in mind: This was 1997 !!!

Nov 3, 2004Afrigraph 2004 Tutorial A28 MCRT – Results Significantly less paging Significantly less paging  Much faster rendering

Nov 3, 2004Afrigraph 2004 Tutorial A30 Kilauea: Data-Parallel Ray Tracing So far: Ray tracing ideally suited for complex models… So far: Ray tracing ideally suited for complex models… … if one can store the model … if one can store the model Pharr: Reduce disk I/O if memory is too small for scene Pharr: Reduce disk I/O if memory is too small for scene Kilauea: Use combined memory of several PCs Kilauea: Use combined memory of several PCs –Combined memories of multiple PCs can hold entire scene … if it’s just enough PCs… if it’s just enough PCs –But: need data-parallel approach

Nov 3, 2004Afrigraph 2004 Tutorial A31 Data-Parallel Ray Tracing Typical data-parallel ray tracing [Reinhard et al.] Typical data-parallel ray tracing [Reinhard et al.] –Distribute scene data over multiple rendering clients (RCs) Subdivide scene into grid of voxels, distribute voxels over RCsSubdivide scene into grid of voxels, distribute voxels over RCs NO client has entire sceneNO client has entire scene  Need communication between different clients –Always send ray to client having the voxel it needs to traverse –If ray leaves current RC’s voxel: forward to RC having next voxel  Similar to MCRT, except: Forward to other RC instead of delay in queue Forward to other RC instead of delay in queue  Can easily scale scene size –As long as sum(all RC memories) > scene size

Nov 3, 2004Afrigraph 2004 Tutorial A32 Data-Parallel Ray Tracing Can easily scale scene size Can easily scale scene size –As long as sum(all RC memories) > scene size Problem Problem –High communication demands  bad communication/compute ratio (slow) –Bottlenecks at “hot-spot” voxels (e.g. voxel w/ camera)  very bad scalability in compute power

Nov 3, 2004Afrigraph 2004 Tutorial A33 Kilauea Approach “as usual”: Distribute scene data over multiple RCs “as usual”: Distribute scene data over multiple RCs But: no ray “forwarding” But: no ray “forwarding” –Instead: Broadcast ray to all clients –Trace on all clients in parallel Each with what scene data it has (no paging)Each with what scene data it has (no paging) Result is minimum of all hits found at any clientResult is minimum of all hits found at any client Kilauea Results Kilauea Results –Like typical data-par.RT: Can efficiently scale memory –Plus: Fewer communication (no forwarding) –Plus: Reduced hot-spotting (all clients work on any ray)

Nov 3, 2004Afrigraph 2004 Tutorial A34 Kilauea Results Additionally: Same approach also for other data Additionally: Same approach also for other data –Not only geometry, also for huge photon maps  Allows highly detailed photon maps even in complex scenes

Nov 3, 2004Afrigraph 2004 Tutorial A35 Kilauea Results Kilauea: Efficiently combine multiple PCs’ memories Kilauea: Efficiently combine multiple PCs’ memories But: Many clients do too much But: Many clients do too much –Client traces ray even if it ended much earlier on different client –“Early ray termination” and “occlusion culling” partially disabled  Rather bad scalability in compute power Partial fix: Hybrid data parallel / image-space parallelism Partial fix: Hybrid data parallel / image-space parallelism –E.g. for 10GB scene on 30 1GB-PCs: –Build 3 micro-clusters of 10 1GB-PCs each –Data-parallel on each of the 3 micro-clusters –Image-space parallelism among micro-clusters

Nov 3, 2004Afrigraph 2004 Tutorial A37 Christensen 2003: Multiresolution Geometry Caching Keep cache of loaded geometry voxels Keep cache of loaded geometry voxels –Like MCRT Plus: Maintain multiresolution representation of scene Plus: Maintain multiresolution representation of scene –Defined by different tesselation levels of NURBS-modelled scene Optimize cache use by selecting proper level Optimize cache use by selecting proper level –Select proper level by tracking “ray differentials” [Igehy] “Coherent rays: detailed geometry”…“Coherent rays: detailed geometry”… “Incoherent rays: coarse geometry”…“Incoherent rays: coarse geometry”…  Efficiently avoids thrashing the cache by incoherent rays

Nov 3, 2004Afrigraph 2004 Tutorial A38 Christensen: Multiresolution Geometry Caching Efficient cache utlization: Efficient cache utlization: –Can render even highly complex models

Nov 3, 2004Afrigraph 2004 Tutorial A39 Christensen: Multiresolution Geometry Caching Efficient cache utlization: Efficient cache utlization: –Can render even highly complex models But: Only applicable for special case But: Only applicable for special case –Needs multiresolution-suitable representation (tesselated NURBS) –Not easily applicable to general (“triangle soup”) problem –Not considered in any more detail here…

Nov 3, 2004Afrigraph 2004 Tutorial A40 Outline Motivation: Why Ray Tracing for Massive Models ? Motivation: Why Ray Tracing for Massive Models ? Offline systems Offline systems –Pharr: Memory Coherent Ray Tracing –Kilauea: Data-parallelism with ray forwarding Interactive Systems Interactive Systems –Utah: Realtime Ray Tracing on Supercomputers Massively complex visualization applicationsMassively complex visualization applications –Saarland 2002: Distributed RTRT for Massive Models Cluster-based approach w/ demand loading, caching and reorderingCluster-based approach w/ demand loading, caching and reordering –Saarland 2004: Caching-based Massive Model Rendering Single-PC based w/ demand loading and proxies for missing dataSingle-PC based w/ demand loading and proxies for missing data Summary and Open Problems Summary and Open Problems

Nov 3, 2004Afrigraph 2004 Tutorial A41 Interactive Ray Tracing Parker/Muuss: Interactive Ray Tracing Parker/Muuss: Interactive Ray Tracing –Idea: Use ray tracing also for interactive applications Already use for highly complex models Already use for highly complex models –Muuss: Outdoor scenes –Parker: Complex Visualization datasets Muuss: Complex outdoor scenes Muuss: Complex outdoor scenes –Directly ray trace CSG models  no tesselation required –Plus: use instantiation to create outdoor complexity  Complex scenes of multi-million triangle equivalent (but moderate storage)  Achieve interactive performance through parallelization

Nov 3, 2004Afrigraph 2004 Tutorial A42 Parker et al.: Interactive Ray Tracing Shared-memory supercomputer: cc-NUMA architecture Shared-memory supercomputer: cc-NUMA architecture –Also “distributed” memory, caching and demand-loading… –… done entirely by HW Directly ray trace non-polygonal data Directly ray trace non-polygonal data –Direct ray tracing of isosurfaces  Massively complex datasets (visible female) without tesselation

Nov 3, 2004Afrigraph 2004 Tutorial A43 Parker et al.: Interactive Ray Tracing Shared-memory supercomputer: cc-NUMA architecture Shared-memory supercomputer: cc-NUMA architecture –Also “distributed” memory, caching and demand-loading… –… done entirely by HW Directly ray trace non-polygonal data Directly ray trace non-polygonal data –Direct ray tracing of isosurfaces  Massively complex datasets (visible female) without tesselation –But: no special techniques for handling complex models  No more details in this “massive model” tutorial…

Nov 3, 2004Afrigraph 2004 Tutorial A44 Outline Motivation: Why Ray Tracing for Massive Models ? Motivation: Why Ray Tracing for Massive Models ? Offline systems Offline systems –Pharr: Memory Coherent Ray Tracing –Kilauea: Data-parallelism with ray forwarding –Christensen: Multiresolution ray tracing Interactive Systems Interactive Systems –Utah: Realtime Ray Tracing on Supercomputers Massively complex visualization applicationsMassively complex visualization applications –Saarland 2001: Distributed RTRT for Massive Models Cluster-based approach w/ demand loading, caching and reorderingCluster-based approach w/ demand loading, caching and reordering –Saarland 2004: Caching-based Massive Model Rendering Single-PC based w/ demand loading and proxies for missing dataSingle-PC based w/ demand loading and proxies for missing data Summary and Open Problems Summary and Open Problems

Nov 3, 2004Afrigraph 2004 Tutorial A45 Saarland 2001: Distributed IRT for Massively Complex Models Basic Idea Basic Idea –Interactive Ray Tracing now (2001) possible Can we also handle massively complex models ?Can we also handle massively complex models ? –Data-parallel problematic in communication and scalability –Memory Coherent Ray Tracing worked fine for complex models –Can we do similar at interactive rates ? Main Problem Main Problem –MCRT heavily depends on extensive reordering –Interactivity significantly limits reordering capabilities Therefore Therefore –Assume that at least working set fits into memory Often need only small part of scene for each frame (occlusion,...)Often need only small part of scene for each frame (occlusion,...) –Use reordering only for hiding loading latency

Nov 3, 2004Afrigraph 2004 Tutorial A46 Saarland 2001: Distributed IRT for Massively Complex Models Cluster-based interactive ray tracing system Cluster-based interactive ray tracing system –One server, multiple clients –Image-space load balancing (tile-based) –For complex models: Can’t replicate scene on each client Caching framework Caching framework –Similar to MCRT: Voxelize geometry Caching based on self-contained voxelsCaching based on self-contained voxels Use kd-tree instead of grid, otherwise exactly the sameUse kd-tree instead of grid, otherwise exactly the same –Each client caches scene data of its own –Get voxels from (centralized) model server Fetch over networkFetch over network

Nov 3, 2004Afrigraph 2004 Tutorial A47 Saarland 2001: Distributed IRT for Massively Complex Models “Only” caching doesn’t suffice “Only” caching doesn’t suffice –Loading latency too high –Entire client stalls for several milliseconds on cache miss  Hide latency by reordering Reordering: If any ray (would) stall Reordering: If any ray (would) stall –Suspend stalling ray –Start execution on new ray –Fetch data asynchronously –Resume stalled ray once data is available Much simpler framework than MCRT Much simpler framework than MCRT –No reordering except on cache miss –Not for secondary rays, global illumination, …

Nov 3, 2004Afrigraph 2004 Tutorial A48 Saarland 2001: Distributed IRT for Massively Complex Models Results Caching allows for rendering model larger than memory Caching allows for rendering model larger than memory –At least if footprint of frame is small enough –Powerplant: 12.5 MTri, several GB on disk (2001!) Rendered on 5-7 PCs w/ 200-400MB geometry cacheRendered on 5-7 PCs w/ 200-400MB geometry cache Reordering can hide “most” loading stalls Reordering can hide “most” loading stalls –Must be able to load all missing data in same frame –Only for ray casting plus simple shadows/reflections Full global illumination touches too much geometryFull global illumination touches too much geometry –Depends on low loading bandwidth  temporal coherency…

Nov 3, 2004Afrigraph 2004 Tutorial A49 Saarland 2001: Distributed IRT for Massively Complex Models

Nov 3, 2004Afrigraph 2004 Tutorial A50 Outline Motivation: Why Ray Tracing for Massive Models ? Motivation: Why Ray Tracing for Massive Models ? Offline systems Offline systems –Pharr: Memory Coherent Ray Tracing –Kilauea: Data-parallelism with ray forwarding Interactive Systems Interactive Systems –Utah: Realtime Ray Tracing on Supercomputers Massively complex visualization applicationsMassively complex visualization applications –Saarland 2001: Distributed RTRT for Massive Models Cluster-based approach w/ demand loading, caching and reorderingCluster-based approach w/ demand loading, caching and reordering –Saarland 2004: Caching-based Massive Model Rendering Single-PC based w/ demand loading and proxies for missing dataSingle-PC based w/ demand loading and proxies for missing data Summary and Open Problems Summary and Open Problems

Nov 3, 2004Afrigraph 2004 Tutorial A51 Saarland 2004: OOC Ray Tracing with Proxy-Mechaisnm The PowerPlant – Since 2001: The PowerPlant – Since 2001: –Ray tracer much faster –… and much more memory-efficient Can represent PowerPlant in < 1GBCan represent PowerPlant in < 1GB –Much more memory on PCs –Can easily render PowerPlant on single PC (laptop) Today’s challenge: The Boeing 777 Today’s challenge: The Boeing 777 –350 million triangles Next generation (7E7) already being designed w/ ~1,000 million…Next generation (7E7) already being designed w/ ~1,000 million… –12 GB raw triangle data (w/o kd-tree etc) –Unstructured “soup” of triangles

Nov 3, 2004Afrigraph 2004 Tutorial A52 Saarland 2004: OOC Ray Tracing with Proxy-Mechaisnm Today’s challenge: The “Boeing 777” (350 MTri) Today’s challenge: The “Boeing 777” (350 MTri)

Nov 3, 2004Afrigraph 2004 Tutorial A53 Today‘s Challenge: The „Boeing 777“

Nov 3, 2004Afrigraph 2004 Tutorial A56 Today‘s Challenge: The „Boeing 777“ Same complexity all over the model…

Nov 3, 2004Afrigraph 2004 Tutorial A57 Saarland 2004 – OOC Ray Tracing with proxy mechanism Compute time itself not the big issue (logarithmic cost…) Compute time itself not the big issue (logarithmic cost…) –Once again: Storage is the main problem –Proof-of-concept: 777on SUN SunFire 12k w/ 96GB RAM: not a problem…777on SUN SunFire 12k w/ 96GB RAM: not a problem… But: Target single-PC setup (<= 8GB RAM) But: Target single-PC setup (<= 8GB RAM)  Need OOC mechanism Lessons learned from 2001-system Lessons learned from 2001-system –Asynchronous loading for latency hiding: Great! –Avoiding OS page faults by manual caching: Great! But: costly, fragmentation, …But: costly, fragmentation, … –Reordering to hide latency: Great, but… … will never work for 777: Need far too much “new” data per frame… will never work for 777: Need far too much “new” data per frame

Nov 3, 2004Afrigraph 2004 Tutorial A58 Saarland 2004 – OOC Ray Tracing with proxy mechanism New system design: New system design: –Reuse concepts (caching, streaming preprocessing, async loading) –But: Realized much more elegantly and efficiently Detect (and avoid) potential page faults by “MMU” Detect (and avoid) potential page faults by “MMU” –“memory management unit” –Keep track of what data is in memory at what time Difference to 2001: Difference to 2001: –Work on OS pages, not on voxel files Uniform caching domain (all data is handled in same way)Uniform caching domain (all data is handled in same way) Less fragmentation, easier to useLess fragmentation, easier to use –Don’t even try to load all data for stalling ray Instead: Kill off ray…Instead: Kill off ray… … and replace by proxy information… and replace by proxy information

Nov 3, 2004Afrigraph 2004 Tutorial A59 Saarland 2004 – OOC Ray Tracing with proxy mechanism Killing off rays Killing off rays –In simplest form: Just mark with constant color (red…) Anything is better than OS paging…Anything is better than OS paging… –Progressive loading: Red pixels disappear over time –But: artifacts during loading

Nov 3, 2004Afrigraph 2004 Tutorial A60 Saarland 2004 – OOC Ray Tracing with proxy mechanism Killing off rays Killing off rays –In simplest form: Just mark with constant color (red…) Anything is better than OS paging…Anything is better than OS paging… –Progressive loading: Red pixels disappear over time –But: artifacts during loading

Nov 3, 2004Afrigraph 2004 Tutorial A61 Saarland 2004 – OOC Ray Tracing with proxy mechanism Proxies for missing rays Proxies for missing rays –Don’t just mark faulted rays red… –… try to find approximate shading data (normal, material,…) –Smooth multiresolution representation would be best But it is complicated for complex “triangle soup” modelsBut it is complicated for complex “triangle soup” models RW2004 approach RW2004 approach –Build “proxies” for certain subtrees of model’s kd-tree Essentially for every subtree that may cause a cache faultEssentially for every subtree that may cause a cache fault – Analyze kd-tree in preprocessing step ! –“Proxy”:lightfield-like representation Averaged normal and material for N discretized viewing directionsAveraged normal and material for N discretized viewing directions –Attach proxies to “potentially faulting subtrees” If memory access faults, just use proxyIf memory access faults, just use proxy

Nov 3, 2004Afrigraph 2004 Tutorial A62 Proxy Quality – Overview Outside View (2GB footprint) Immediately after startup (tiny fraction of data loaded) Immediately after startup (tiny fraction of data loaded) without proxies with proxies

Nov 3, 2004Afrigraph 2004 Tutorial A63 Proxy Quality – Overview Outside View (2GB footprint) After loading for several seconds (roughly equal amount of geometry loaded) After loading for several seconds (roughly equal amount of geometry loaded) without proxies with proxies

Nov 3, 2004Afrigraph 2004 Tutorial A64 Saarland 2004 – OOC Ray Tracing with proxy mechanism Proxy results Proxy results –Need only few memory (<1 GB for entire model) –Qualitatively better than red pixels But: Still artifacts due to incorrect (averaged) normal & materialBut: Still artifacts due to incorrect (averaged) normal & material

Nov 3, 2004Afrigraph 2004 Tutorial A65 Saarland 2004 – OOC Ray Tracing with proxy mechanism Proxy results Proxy results –Need only few memory (<1 GB for entire model) –Qualitatively better than red pixels But: Still artifacts due to incorrect (averaged) normal & materialBut: Still artifacts due to incorrect (averaged) normal & material –Eye very sensitive to such artifacts  In practice: Often prefer red pixels …In practice: Often prefer red pixels … – Psychology: rather prefer “really wrong” to “not convincingly real” Conclusion Conclusion –OOC+MMU is good –Proxies need to be improved Need better representation for voxelsNeed better representation for voxels

Nov 3, 2004Afrigraph 2004 Tutorial A66 Saarland 2004 – OOC Ray Tracing with proxy mechanism Proxy results Proxy results –Need only few memory (<1 GB for entire model) –Qualitatively better than red pixels But: Still artifacts due to incorrect (averaged) normal & materialBut: Still artifacts due to incorrect (averaged) normal & material –Eye very sensitive to such artifacts  In practice: Often prefer red pixels …In practice: Often prefer red pixels … – Psychology: rather prefer “really wrong” to “not convincingly real” Conclusion Conclusion –OOC+MMU is good –Proxies need to be improved Need better representation for voxelsNeed better representation for voxels  Question to the audience: Any ideas

Nov 3, 2004Afrigraph 2004 Tutorial A67 Outline Todays challenge Todays challenge Offline systems Offline systems –Pharr: Memory Coherent Ray Tracing –Kilauea: Data-parallelism with ray forwarding Interactive Systems Interactive Systems –Utah: Realtime Ray Tracing on Supercomputers Massively complex visualization applicationsMassively complex visualization applications –Saarland 2002: Distributed RTRT for Massive Models Cluster-based approach w/ demand loading, caching and reorderingCluster-based approach w/ demand loading, caching and reordering –Saarland 2004: Caching-based Massive Model Rendering Single-PC based w/ demand loading and proxies for missing dataSingle-PC based w/ demand loading and proxies for missing data Summary and Open Problems Summary and Open Problems

Nov 3, 2004Afrigraph 2004 Tutorial A68 Summary and Open Issues Summary: RT has several specific advantages for complex models Summary: RT has several specific advantages for complex models –Built-in occlusion culling –Logarithmic scalability –… Several special solutions for complex models Several special solutions for complex models –Scene complexity using massive instantiation In particular for outdoor scenesIn particular for outdoor scenes –Ability to avoid tesselation in the first place… Direct ray tracing of isosurfacesDirect ray tracing of isosurfaces Similar for complex point-based models, NURBS scenes, …Similar for complex point-based models, NURBS scenes, …

Nov 3, 2004Afrigraph 2004 Tutorial A69 Summary and Open Issues Summary: Have discussed several systems Summary: Have discussed several systems –MCRT: Caching plus reordering for minimizing disk IO –Kilauea: Data-parallel rendering –Christensen: Multiresolution caching –Wald01: Caching plus (simple) reordering for latency hiding –Wald04: OS-like caching with cancelling of faulting rays Many similarities Many similarities –NO system tries to reduce complexity for cost reasons Only for reducing loading time and storage…Only for reducing loading time and storage… –ALL systems concentrate on scene storage problem

Nov 3, 2004Afrigraph 2004 Tutorial A70 Summary and Open Issues Overall: Ray-tracing based MMR is very powerful Overall: Ray-tracing based MMR is very powerful –Boeing: 350 MTris on single PC –Kilauea: High-quality global illumination With highly complex photon mapsWith highly complex photon maps –Utah: Massively complex volumetric datasets Including high-quality shadingIncluding high-quality shading But: Still a lot to do… But: Still a lot to do… –Models get bigger and bigger … Much quicker than PCs get fasterMuch quicker than PCs get faster –Still many unsolved problems

Nov 3, 2004Afrigraph 2004 Tutorial A71 Summary and Open Issues Biggest Problems left over: Antialiasing Antialiasing –More triangles  more detail/pixel  aliasing… –Need more rays/pixel for more complex scenes Efficient multiresolution approach Efficient multiresolution approach –What to do about missing data –Can’t always wait for data – “Boeing-proxies” not sufficient Efficient parallelization Efficient parallelization –Currently either “data parallel” (scales in model size) … –… or image-space parallelism (scales in performance) … –… but not both.

Nov 3, 2004Afrigraph 2004 Tutorial A72 Thanks for your attention

Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik Saarbrücken, Germany.

Similar presentations

Presentation on theme: "Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik Saarbrücken, Germany."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik Saarbrücken, Germany.

Similar presentations

Presentation on theme: "Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik Saarbrücken, Germany."— Presentation transcript:

Similar presentations

About project

Feedback