Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik...

Afrigraph 2004 Tutorial A:Afrigraph 2004 Tutorial A:

Part II Part II Ray Tracing Ray Tracing BBased ased ApproachesApproaches

Ingo WaldIngo Wald

MPI InformatikMPI Informatik

Saarbrücken, GermanySaarbrücken, Germany

Nov 3, 2004 Afrigraph 2004 Tutorial A 2

OutlineOutline

• Motivation: Why Ray Tracing for Massive Models ?Motivation: Why Ray Tracing for Massive Models ?• Offline systemsOffline systems

– Pharr: Memory Coherent Ray TracingPharr: Memory Coherent Ray Tracing

– Kilauea: Data-parallelism with ray forwardingKilauea: Data-parallelism with ray forwarding

– Christensen: Multiresolution cachingChristensen: Multiresolution caching

• Interactive SystemsInteractive Systems– Utah: Realtime Ray Tracing on SupercomputersUtah: Realtime Ray Tracing on Supercomputers

• Massively complex visualization applicationsMassively complex visualization applications

– Saarland 2001: Distributed RTRT for Massive ModelsSaarland 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 RenderingSaarland 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 ProblemsSummary and Open Problems


OutlineOutline











Why Ray Tracing for Massive Why Ray Tracing for Massive Models ?Models ?

• Summary Part I:Summary Part I:– Rendering time is linear in #trianglesRendering time is linear in #triangles

Too many triangles take too long to render Too many triangles take too long to render Cannot render all triangles at interactive rates Cannot render all triangles at interactive rates Have to somehow reduce #triangles Have to somehow reduce #triangles (culling, simplification, approximation, ...) (culling, simplification, approximation, ...) … …

• Entire argumentation chain depends on initial axiomEntire argumentation chain depends on initial axiom“Rendering time is linear in #triangles”“Rendering time is linear in #triangles”– But: Only applies to brute force rasterization, …But: Only applies to brute force rasterization, …


Why Ray Tracing for Massive Why Ray Tracing for Massive Models ?Models ?

• Summary Part I:Summary Part I:– Rendering time is linear in #trianglesRendering time is linear in #triangles

Too many triangles take too long to render Too many triangles take too long to render Cannot render all triangles at interactive rates Cannot render all triangles at interactive rates Have to somehow reduce #triangles Have to somehow reduce #triangles (culling, simplification, approximation, ...) (culling, simplification, approximation, ...) … …

• Entire argumentation chain depends on initial axiomEntire argumentation chain depends on initial axiom“Rendering time is linear in #triangles”“Rendering time is linear in #triangles”– But: Only applies to brute force rasterization, …But: Only applies to brute force rasterization, …

– … … NOT for ray tracing !NOT for ray tracing !


Ray TracingRay Tracing

Simple AlgorithmSimple Algorithm

1.) Create ray from eye through pixel1.) Create ray from eye through pixel





2.) Trace ray into scene2.) Trace ray into scene





2.) Trace ray into scene2.) Trace ray into scene– Find objects nearby ray (traverse spatial data structures)Find objects nearby ray (traverse spatial data structures)

– Compute ray-object intersection testsCompute ray-object intersection tests

– Determine closest hitpointDetermine closest hitpoint

Grid (2D) Octree (2D)





3.) Compute color of ray (“shade” the ray)3.) Compute color of ray (“shade” the ray)– Maybe including secondary rays… (won’t discuss that here)Maybe including secondary rays… (won’t discuss that here)






3.) Compute color of ray (“shade” the ray)3.) Compute color of ray (“shade” the ray)

4.) Display final image4.) Display final image



• Simple algorithm, with many advantagesSimple algorithm, with many advantages– Support for advanced shading and global illuminationSupport for advanced shading and global illumination

• Not Not directlydirectly related to massive model rendering… related to massive model rendering…

– Supports instantiationSupports instantiation

– Visibility culling built inVisibility culling built in

– Occlusion culling built in, tooOcclusion culling built in, too• Per pixel visibilityPer pixel visibility

– Trivially parallelizableTrivially parallelizable

– Logarithmic scalability in scene sizeLogarithmic scalability in scene size• Due to Due to traversaltraversal of ( of (hierarchicalhierarchical) spatial acceleration structures) spatial acceleration structures

Ray Tracing: PropertiesRay Tracing: Properties


• Simple algorithm, with many advantagesSimple algorithm, with many advantages– Support for advanced shading and global illuminationSupport for advanced shading and global illumination

• Not Not directlydirectly related to massive model rendering… related to massive model rendering…

– Supports instantiationSupports instantiation

– Visibility culling built inVisibility culling built in

– Occlusion culling built in, tooOcclusion culling built in, too• Per pixel visibilityPer pixel visibility

– Trivially parallelizableTrivially parallelizable

– Logarithmic scalability in scene sizeLogarithmic 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 !For complex models, „log scalability“ is most important !

Ray Tracing: PropertiesRay Tracing: Properties


Ray Tracing: Log. ScalabilityRay Tracing: Log. Scalability

• Logarithmic scalability in practice:Logarithmic scalability in practice:– Example from Isosurface Ray Tracing (similar for polygons)Example from Isosurface Ray Tracing (similar for polygons)

– Marschner-Lobb dataset: Synthetically generatedMarschner-Lobb dataset: Synthetically generated• From 32x32x32 voxels (32kVox) to 1024x1024x1024 (1GVox)From 32x32x32 voxels (32kVox) to 1024x1024x1024 (1GVox)


Ray Tracing: Log. ScalabilityRay Tracing: Log. Scalability

• Logarithmic scalability in practice:Logarithmic scalability in practice:– Example from Isosurface Ray Tracing (similar for polygons)Example from Isosurface Ray Tracing (similar for polygons)

Rendering time *= 2, for scenesize *= 10^4.5 !Rendering time *= 2, for scenesize *= 10^4.5 !


Why use Ray Tracing for Why use Ray Tracing for Massive Model Rendering ?Massive Model Rendering ?

• Logarithmic scalability:Logarithmic scalability:– Essentially solves the complexity problemEssentially solves the complexity problem

• Number of triangles not the main problem any more…Number of triangles not the main problem any more…


Why use Ray Tracing for Why use Ray Tracing for Massive Model Rendering ?Massive Model Rendering ?

• #Triangles not the main problem any more#Triangles not the main problem any more– Proof by example: “Sunflowers” sceneProof 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


Ray Tracing for Ray Tracing for Massive Model RenderingMassive 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 ?


Ray Tracing for Ray Tracing for Massive Model RenderingMassive 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 !Main problem: Efficient scene storage and access !

The storage problemThe storage problem– ““logarithmic cost”: assumes all data is in memorylogarithmic cost”: assumes all data is in memory– ““Sunflowers” example ?Sunflowers” example ?

• Only possible through instantiation Only possible through instantiation special case ! special case !

– For general complex models: usually not the caseFor 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)Full model actually 270x24GB (270 time slices)

Storage is worst indiv. problem of ray tracing MCMsStorage is worst indiv. problem of ray tracing MCMs..


OutlineOutline











““Memory Coherent Ray Tracing”Memory Coherent Ray Tracing”[Pharr, Siggraph97][Pharr, Siggraph97]

• Basic observationBasic observation– Ray tracing ideally suited for complex modelsRay tracing ideally suited for complex models

– But: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) randomW/ global illumination: Scene access usually (almost) random

Excessive OS paging and thrashing, huge rendering times…Excessive OS paging and thrashing, huge rendering times…

• Basic ideaBasic idea– Do “manual” (explicit) caching/paging on suitable entitiesDo “manual” (explicit) caching/paging on suitable entities

– Reorder computations to achieve coherenceReorder computations to achieve coherence• Based on scheduler to minimize disk I/OBased on scheduler to minimize disk I/O

Avoid page thrashing, significantly improve performanceAvoid page thrashing, significantly improve performance


Memory Coherent Ray TracingMemory Coherent Ray Tracing - Reordering Computations - Reordering Computations

• Typical ray tracing approach: depth-firstTypical ray tracing approach: depth-first– Trace first ray until hit point is foundTrace first ray until hit point is found

– Trace all secondary rays of first ray in depth-first mannerTrace all secondary rays of first ray in depth-first manner

– Start new pixel only after all of the old one’s rays are finished…Start new pixel only after all of the old one’s rays are finished…

• Problem: Highly incoherent scene accessProblem: Highly incoherent scene access– Primary ray of 2Primary ray of 2ndnd pixel needs similar data as primary of 1 pixel needs similar data as primary of 1stst pixel pixel

– But: Secondary rays of 1But: Secondary rays of 1stst pixel have already swapped out data… pixel have already swapped out data…

• Solution: Improve scene access coherence by reorderingSolution: Improve scene access coherence by reordering– Explicit caching Explicit caching

• Know what’s in memory at what time !Know what’s in memory at what time !

– Reordering of raysReordering 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/OTrade uncontrolled OS paging for controlled disk I/O


MCRT – Geometry CacheMCRT – Geometry Cache

Caching frameworkCaching framework• Subdivide scene into grid of “voxels”Subdivide scene into grid of “voxels”

– Each voxel small enough to fit into memoryEach voxel small enough to fit into memory

– Voxel contains all necessary dataVoxel 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 itVoxel contains all data to trace a ray through itVoxel contains all data to trace a ray through it

– Build voxels in preprocessing step, store on diskBuild voxels in preprocessing step, store on disk

• Perform explicit caching on these voxelsPerform explicit caching on these voxels– Keep cache of currently loaded voxels (“geometry cache”)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.If new voxel needs to be loaded, discard old one.

– Plus: texture cache, displacement cache, … (no details here)Plus: texture cache, displacement cache, … (no details here)


MCRT – Ray SchedulingMCRT – Ray Scheduling

• Each ray consists ofEach ray consists of– Origin, direction, current hit information, …Origin, direction, current hit information, …

– Ref. to pixel it belongs toRef. to pixel it belongs to

– Weight factor that specifies how much ray may contribute to pixelWeight 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 pixelAdd its contribution (ray weight * surface emission) to pixel

Rays can be traced in any orderRays can be traced in any order

• Store queue of “active” rays per voxelStore queue of “active” rays per voxel– I.e., list of all rays that demand intersection with that voxelI.e., list of all rays that demand intersection with that voxel

– Perform scheduling based on voxel queuePerform scheduling based on voxel queue


MCRT – Ray SchedulingMCRT – Ray Scheduling

•Basic scheduling algorithmBasic scheduling algorithmGenerate eye rays and place them into respective queue(s)Generate eye rays and place them into respective queue(s)

While there are queued raysWhile there are queued rays

Choose a voxel to processChoose a voxel to process

For each ray in voxelFor each ray in voxel

Intersect ray with voxel’s geometryIntersect ray with voxel’s geometry

If there is an intersectionIf there is an intersection

Run shader and compute BRDFRun shader and compute BRDF

Insert spawned rays into voxel’s queue (w/ proper Insert spawned rays into voxel’s queue (w/ proper weights)weights)

If surface is emissive, store contribution to imageIf surface is emissive, store contribution to image

Terminate rayTerminate ray

elseelse

Advance ray to the next voxel queue along its wayAdvance ray to the next voxel queue along its way


Memory Coherent Ray TracingMemory Coherent Ray Tracing Scheduling Overview Scheduling Overview


MCRT – ResultsMCRT – Results

• Reordering significantly improves coherenceReordering significantly improves coherence– Always work on similar rays (same queue) at same timeAlways work on similar rays (same queue) at same time

• In particular: First iteration In particular: First iteration All primary rays in same queue ! All primary rays in same queue !

• Scheduling can significantly reduce disk I/OScheduling can significantly reduce disk I/O– Can prefer rays from voxels whose geometry is already loadedCan prefer rays from voxels whose geometry is already loaded

– When loading, can prefer voxels with many active raysWhen 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 pagingSignificantly less paging

Can efficiently ray trace scenes much larger than memoryCan efficiently ray trace scenes much larger than memory



Can efficiently ray trace scenes much larger than memoryCan efficiently ray trace scenes much larger than memory– Lake scene, rendered using path tracing and environment illum.Lake scene, rendered using path tracing and environment illum.

– MCRT: can be rendered at 10% cache sizeMCRT: can be rendered at 10% cache size

– Keep in mind: This was 1997 !!!Keep in mind: This was 1997 !!!



• Significantly less pagingSignificantly less paging Much faster renderingMuch faster rendering


OutlineOutline











Kilauea: Data-Parallel Ray Kilauea: Data-Parallel Ray TracingTracing

• So far: Ray tracing ideally suited for complex models…So far: Ray tracing ideally suited for complex models…• … … if one can store the modelif one can store the model

• Pharr: Reduce disk I/O if memory is too small for scenePharr: Reduce disk I/O if memory is too small for scene• Kilauea: Use combined memory of several PCsKilauea: Use combined memory of several PCs

– Combined memories of multiple PCs can hold entire sceneCombined memories of multiple PCs can hold entire scene• … … if it’s just enough PCsif it’s just enough PCs

– But: need data-parallel approachBut: need data-parallel approach


Data-Parallel Ray TracingData-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)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 clientsNeed communication between different clients

– Always send ray to client having the voxel it needs to traverseAlways send ray to client having the voxel it needs to traverse

– If ray leaves current RC’s voxel: forward to RC having next voxelIf ray leaves current RC’s voxel: forward to RC having next voxelSimilar to MCRT, except: Similar to MCRT, except:

• Forward to other RC instead of delay in queueForward to other RC instead of delay in queue

Can easily scale scene sizeCan easily scale scene size– As long as sum(all RC memories) > scene sizeAs long as sum(all RC memories) > scene size


Data-Parallel Ray TracingData-Parallel Ray Tracing

• Can easily scale scene sizeCan easily scale scene size– As long as sum(all RC memories) > scene size As long as sum(all RC memories) > scene size

• ProblemProblem– High communication demands High communication demands

bad communication/compute ratio (slow)bad communication/compute ratio (slow)

– Bottlenecks at “hot-spot” voxels (e.g. voxel w/ camera)Bottlenecks at “hot-spot” voxels (e.g. voxel w/ camera) very bad scalability in compute powervery bad scalability in compute power


Kilauea ApproachKilauea Approach

• ““as usual”: Distribute scene data over multiple RCsas usual”: Distribute scene data over multiple RCs• But: no ray “forwarding”But: no ray “forwarding”

– Instead: Broadcast ray to all clientsInstead: Broadcast ray to all clients

– Trace on all clients in parallelTrace 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 ResultsKilauea Results– Like typical data-par.RT: Can efficiently scale memoryLike typical data-par.RT: Can efficiently scale memory

– Plus: Fewer communication (no forwarding)Plus: Fewer communication (no forwarding)

– Plus: Reduced hot-spotting (all clients work on any ray)Plus: Reduced hot-spotting (all clients work on any ray)


Kilauea ResultsKilauea Results

• Additionally: Same approach also for other dataAdditionally: Same approach also for other data– Not only geometry, also for huge photon mapsNot only geometry, also for huge photon maps

Allows highly detailed photon maps even in complex scenesAllows highly detailed photon maps even in complex scenes


Kilauea ResultsKilauea Results

• Kilauea: Efficiently combine multiple PCs’ memoriesKilauea: 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 clientClient traces ray even if it ended much earlier on different client

– ““Early ray termination” and “occlusion culling” partially disabledEarly ray termination” and “occlusion culling” partially disabled

Rather bad scalability in compute powerRather bad scalability in compute power

• Partial fix: Hybrid data parallel / image-space parallelismPartial fix: Hybrid data parallel / image-space parallelism– E.g. for 10GB scene on 30 1GB-PCs: E.g. for 10GB scene on 30 1GB-PCs:

– Build 3 micro-clusters of 10 1GB-PCs eachBuild 3 micro-clusters of 10 1GB-PCs each

– Data-parallel on each of the 3 micro-clustersData-parallel on each of the 3 micro-clusters

– Image-space parallelism among micro-clustersImage-space parallelism among micro-clusters


OutlineOutline











Christensen 2003: Multiresolution Christensen 2003: Multiresolution Geometry Caching Geometry Caching

• Keep cache of loaded geometry voxelsKeep cache of loaded geometry voxels– Like MCRTLike MCRT

• Plus: Maintain multiresolution representation of scenePlus: Maintain multiresolution representation of scene– Defined by different tesselation levels of NURBS-modelled sceneDefined by different tesselation levels of NURBS-modelled scene

• Optimize cache use by selecting proper levelOptimize cache use by selecting proper level– Select proper level by tracking “ray differentials” [Igehy]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 raysEfficiently avoids thrashing the cache by incoherent rays


Christensen: Multiresolution Christensen: Multiresolution Geometry Caching Geometry Caching

• Efficient cache utlization: Efficient cache utlization: – Can render even highly complex modelsCan render even highly complex models


Christensen: Multiresolution Christensen: Multiresolution Geometry Caching Geometry Caching

• Efficient cache utlization: Efficient cache utlization: – Can render even highly complex modelsCan render even highly complex models

• But: Only applicable for special caseBut: Only applicable for special case– Needs multiresolution-suitable representation (tesselated NURBS)Needs multiresolution-suitable representation (tesselated NURBS)

– Not easily applicable to general (“triangle soup”) problemNot easily applicable to general (“triangle soup”) problem

– Not considered in any more detail here…Not considered in any more detail here…


OutlineOutline










Interactive Ray TracingInteractive Ray Tracing

• Parker/Muuss: Interactive Ray TracingParker/Muuss: Interactive Ray Tracing– Idea: Use ray tracing also for Idea: Use ray tracing also for interactive interactive applicationsapplications

• Already use for highly complex modelsAlready use for highly complex models– Muuss: Outdoor scenesMuuss: Outdoor scenes

– Parker: Complex Visualization datasetsParker: Complex Visualization datasets

• Muuss: Complex outdoor scenesMuuss: Complex outdoor scenes– Directly ray trace CSG models Directly ray trace CSG models

no tesselation requiredno tesselation required

– Plus: use instantiation to create outdoor complexityPlus: use instantiation to create outdoor complexity Complex scenes of multi-million triangle equivalentComplex scenes of multi-million triangle equivalent

(but moderate storage)(but moderate storage)

Achieve interactive performance through parallelizationAchieve interactive performance through parallelization


Parker et al.:Parker et al.:Interactive Ray TracingInteractive Ray Tracing

• Shared-memory supercomputer: cc-NUMA architecture Shared-memory supercomputer: cc-NUMA architecture – Also “distributed” memory, caching and demand-loading…Also “distributed” memory, caching and demand-loading…

– … … done entirely by HWdone entirely by HW

• Directly ray trace non-polygonal dataDirectly ray trace non-polygonal data– Direct ray tracing of isosurfacesDirect ray tracing of isosurfaces

Massively complex datasets (visible female) without tesselationMassively complex datasets (visible female) without tesselation


Parker et al.:Parker et al.:Interactive Ray TracingInteractive Ray Tracing

• Shared-memory supercomputer: cc-NUMA architecture Shared-memory supercomputer: cc-NUMA architecture – Also “distributed” memory, caching and demand-loading…Also “distributed” memory, caching and demand-loading…

– … … done entirely by HWdone entirely by HW

• Directly ray trace non-polygonal data Directly ray trace non-polygonal data – Direct ray tracing of isosurfacesDirect ray tracing of isosurfaces

Massively complex datasets (visible female) without tesselationMassively complex datasets (visible female) without tesselation

– But: no special techniques for handling complex modelsBut: no special techniques for handling complex models No more details in this “massive model” tutorial…No more details in this “massive model” tutorial…


OutlineOutline




– Christensen: Multiresolution ray tracingChristensen: Multiresolution ray tracing







Saarland 2001: Distributed IRT Saarland 2001: Distributed IRT for Massively Complex Modelsfor Massively Complex Models

• Basic IdeaBasic Idea– Interactive Ray Tracing now (2001) possibleInteractive 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 scalabilityData-parallel problematic in communication and scalability

– Memory Coherent Ray Tracing worked fine for complex modelsMemory Coherent Ray Tracing worked fine for complex models

– Can we do similar at interactive rates ?Can we do similar at interactive rates ?

• Main ProblemMain Problem– MCRT heavily depends on extensive reorderingMCRT heavily depends on extensive reordering

– Interactivity significantly limits reordering capabilitiesInteractivity significantly limits reordering capabilities

• ThereforeTherefore– Assume that at least working set fits into memoryAssume 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 latencyUse reordering only for hiding loading latency



• Cluster-based interactive ray tracing systemCluster-based interactive ray tracing system– One server, multiple clientsOne server, multiple clients

– Image-space load balancing (tile-based)Image-space load balancing (tile-based)

– For complex models: Can’t replicate scene on each clientFor complex models: Can’t replicate scene on each client

• Caching frameworkCaching framework– Similar to MCRT: Voxelize geometrySimilar 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 ownEach client caches scene data of its own

– Get voxels from (centralized) model serverGet voxels from (centralized) model server• Fetch over networkFetch over network



• ““Only” caching doesn’t sufficeOnly” caching doesn’t suffice– Loading latency too highLoading latency too high

– Entire client stalls for several milliseconds on cache missEntire client stalls for several milliseconds on cache miss Hide latency by reorderingHide latency by reordering

• Reordering: If any ray (would) stallReordering: If any ray (would) stall– Suspend stalling raySuspend stalling ray

– Start execution on new rayStart execution on new ray

– Fetch data asynchronouslyFetch data asynchronously

– Resume stalled ray once data is availableResume stalled ray once data is available

• Much simpler framework than MCRTMuch simpler framework than MCRT– No reordering except on cache missNo reordering except on cache miss

– Not for secondary rays, global illumination, …Not for secondary rays, global illumination, …



ResultsResults• Caching allows for rendering model larger than memoryCaching allows for rendering model larger than memory

– At least if footprint of frame is small enough At least if footprint of frame is small enough

– Powerplant: 12.5 MTri, several GB on disk (2001!)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 stallsReordering can hide “most” loading stalls– Must Must be able to load all missing data in same framebe able to load all missing data in same frame

– Only for ray casting plus simple shadows/reflectionsOnly 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 Depends on low loading bandwidth temporal coherency… temporal coherency…


OutlineOutline










Saarland 2004: OOC Ray Tracing Saarland 2004: OOC Ray Tracing with Proxy-Mechaisnmwith Proxy-Mechaisnm

• The PowerPlant – Since 2001:The PowerPlant – Since 2001:– Ray tracer much fasterRay tracer much faster

– … … and much more memory-efficientand much more memory-efficient• Can represent PowerPlant in < 1GBCan represent PowerPlant in < 1GB

– Much more memory on PCsMuch more memory on PCs

– Can easily render PowerPlant on single PC (laptop)Can easily render PowerPlant on single PC (laptop)

• Today’s challenge: The Boeing 777Today’s challenge: The Boeing 777– 350 million triangles350 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)12 GB raw triangle data (w/o kd-tree etc)

– Unstructured “soup” of trianglesUnstructured “soup” of triangles


Saarland 2004: OOC Ray Tracing Saarland 2004: OOC Ray Tracing with Proxy-Mechaisnmwith Proxy-Mechaisnm

• Today’s challenge: The “Boeing 777” (350 MTri)Today’s challenge: The “Boeing 777” (350 MTri)


Today‘s Challenge: Today‘s Challenge: The „Boeing 777“The „Boeing 777“



Same complexity all over the model…Same complexity all over the model…Same complexity all over the model…Same complexity all over the model…


Saarland 2004 – OOC Ray Saarland 2004 – OOC Ray Tracing with proxy mechanismTracing 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 problemOnce again: Storage is the main problem

– Proof-of-concept: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 mechanismNeed OOC mechanism

• Lessons learned from 2001-systemLessons learned from 2001-system– Asynchronous loading for latency hiding: Great!Asynchronous loading for latency hiding: Great!

– Avoiding OS page faults by manual caching: Great!Avoiding OS page faults by manual caching: Great!• But: costly, fragmentation, …But: costly, fragmentation, …

– Reordering to hide latency: Great, but…Reordering to hide latency: Great, but…• … … will never work for 777: Need far too much “new” data per framewill never work for 777: Need far too much “new” data per frame



• New system design:New system design:– Reuse concepts (caching, streaming preprocessing, async loading)Reuse concepts (caching, streaming preprocessing, async loading)

– But: Realized much more elegantly and efficientlyBut: 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”memory management unit”

– Keep track of what data is in memory at what timeKeep track of what data is in memory at what time

• Difference to 2001: Difference to 2001: – Work on OS pages, not on voxel filesWork 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 rayDon’t even try to load all data for stalling ray• Instead: Kill off ray…Instead: Kill off ray…

• … … and replace by proxy informationand replace by proxy information



• Killing off raysKilling off rays– In simplest form: Just mark with constant color (red…)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 timeProgressive loading: Red pixels disappear over time

– But: artifacts during loadingBut: artifacts during loading



• Proxies for missing raysProxies for missing rays– Don’t just mark faulted rays red…Don’t just mark faulted rays red…

– … … try to find approximate shading data (normal, material,…)try to find approximate shading data (normal, material,…)

– Smooth multiresolution representation would be bestSmooth multiresolution representation would be best• But it is complicated for complex “triangle soup” modelsBut it is complicated for complex “triangle soup” models

• RW2004 approachRW2004 approach– Build “proxies” for certain subtrees of model’s kd-treeBuild “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 !Analyze kd-tree in preprocessing step !

– ““Proxy”:lightfield-like representationProxy”: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”Attach proxies to “potentially faulting subtrees”• If memory access faults, just use proxyIf memory access faults, just use proxy


Proxy Quality – OverviewProxy Quality – OverviewOutside View (2GB footprint)Outside View (2GB footprint)

Immediately after startup Immediately after startup (tiny fraction of data loaded)(tiny fraction of data loaded)

Immediately after startup Immediately after startup (tiny fraction of data loaded)(tiny fraction of data loaded)

without proxieswithout proxieswithout proxieswithout proxies with proxieswith proxieswith proxieswith proxies


Proxy Quality – OverviewProxy Quality – OverviewOutside View (2GB footprint)Outside View (2GB footprint)

After loading for several secondsAfter loading for several seconds(roughly equal amount of geometry loaded)(roughly equal amount of geometry loaded)

After loading for several secondsAfter loading for several seconds(roughly equal amount of geometry loaded)(roughly equal amount of geometry loaded)

without proxieswithout proxieswithout proxieswithout proxies with proxieswith proxieswith proxieswith proxies



• Proxy resultsProxy results– Need only few memory (<1 GB for entire model)Need only few memory (<1 GB for entire model)

– Qualitatively better than red pixelsQualitatively 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 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”Psychology: rather prefer “really wrong” to “not convincingly real”

• ConclusionConclusion– OOC+MMU is goodOOC+MMU is good

– Proxies need to be improvedProxies need to be improved• Need better representation for voxelsNeed better representation for voxels





– Eye very sensitive to such artifacts 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”Psychology: rather prefer “really wrong” to “not convincingly real”

• ConclusionConclusion– OOC+MMU is goodOOC+MMU is good

– Proxies need to be improvedProxies need to be improved• Need better representation for voxelsNeed better representation for voxels

Question to the audience: Any ideas Question to the audience: Any ideas


OutlineOutline

• Todays challengeTodays challenge• Offline systemsOffline systems









Summary and Open IssuesSummary and Open Issues

• Summary: Summary: RT has several specific advantages for complex modelsRT has several specific advantages for complex models– Built-in occlusion cullingBuilt-in occlusion culling

– Logarithmic scalabilityLogarithmic scalability

– ……

• Several special solutions for complex modelsSeveral special solutions for complex models– Scene complexity using massive instantiationScene complexity using massive instantiation

• In particular for outdoor scenesIn particular for outdoor scenes

– Ability to avoid tesselation in the first place…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, …



• Summary: Have discussed several systemsSummary: Have discussed several systems– MCRT: Caching plus reordering for minimizing disk IOMCRT: Caching plus reordering for minimizing disk IO

– Kilauea: Data-parallel renderingKilauea: Data-parallel rendering


– Wald01: Caching plus (simple) reordering for latency hidingWald01: Caching plus (simple) reordering for latency hiding

– Wald04: OS-like caching with cancelling of faulting raysWald04: OS-like caching with cancelling of faulting rays

• Many similaritiesMany similarities– NO system tries to reduce complexity for cost reasonsNO 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 problemALL systems concentrate on scene storage problem



• Overall: Ray-tracing based MMR is very powerfulOverall: Ray-tracing based MMR is very powerful– Boeing: 350 MTris on single PCBoeing: 350 MTris on single PC

– Kilauea: High-quality global illuminationKilauea: High-quality global illumination• With highly complex photon mapsWith highly complex photon maps

– Utah: Massively complex volumetric datasetsUtah: 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 …Models get bigger and bigger …

• Much quicker than PCs get fasterMuch quicker than PCs get faster

– Still many unsolved problemsStill many unsolved problems



Biggest Problems left over:Biggest Problems left over:• AntialiasingAntialiasing

– More triangles More triangles more detail/pixel more detail/pixel aliasing… aliasing…

– Need more rays/pixel for more complex scenesNeed more rays/pixel for more complex scenes

• Efficient multiresolution approachEfficient multiresolution approach– What to do about missing dataWhat to do about missing data

– Can’t always wait for data – “Boeing-proxies” not sufficientCan’t always wait for data – “Boeing-proxies” not sufficient

• Efficient parallelizationEfficient parallelization– Currently either “data parallel” (scales in model size) …Currently either “data parallel” (scales in model size) …

– … … or image-space parallelism (scales in performance) …or image-space parallelism (scales in performance) …

– … … but not both.but not both.


Thanks for your attentionThanks for your attention

Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik...

Documents

Transcript of Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik...