Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches - PowerPoint PPT Presentation

1 / 72
About This Presentation
Title:

Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches

Description:

Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches Ingo Wald MPI Informatik Saarbr cken, Germany Outline Motivation: Why Ray Tracing for Massive Models ? – PowerPoint PPT presentation

Number of Views:113
Avg rating:3.0/5.0
Slides: 73
Provided by: IngoWald
Category:

less

Transcript and Presenter's Notes

Title: Afrigraph 2004 Tutorial A: Part II Ray Tracing Based Approaches


1
Afrigraph 2004 Tutorial APart II Ray Tracing
Based Approaches
  • Ingo Wald
  • MPI Informatik
  • Saarbrücken, Germany

2
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Christensen Multiresolution caching
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2001 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

3
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Christensen Multiresolution caching
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2001 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

4
Why Ray Tracing for Massive Models ?
  • 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
    axiomRendering time is linear in triangles
  • But Only applies to brute force rasterization,

5
Why Ray Tracing for Massive Models ?
  • 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
    axiomRendering time is linear in triangles
  • But Only applies to brute force rasterization,
  • NOT for ray tracing !

6
Ray Tracing
  • Simple Algorithm
  • 1.) Create ray from eye through pixel

7
Ray Tracing
  • Simple Algorithm
  • 1.) Create ray from eye through pixel
  • 2.) Trace ray into scene

8
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)
9
Ray Tracing
  • 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 (wont discuss
    that here)

10
Ray Tracing
  • 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

11
Ray Tracing Properties
  • Simple algorithm, with many advantages
  • Support for advanced shading and global
    illumination
  • Not directly related to massive model rendering
  • Supports instantiation
  • Visibility culling built in
  • Occlusion culling built in, too
  • Per pixel visibility
  • Trivially parallelizable
  • Logarithmic scalability in scene size
  • Due to traversal of (hierarchical) spatial
    acceleration structures

12
Ray Tracing Properties
  • Simple algorithm, with many advantages
  • Support for advanced shading and global
    illumination
  • Not directly related to massive model rendering
  • Supports instantiation
  • Visibility culling built in
  • Occlusion culling built in, too
  • Per pixel visibility
  • Trivially parallelizable
  • Logarithmic scalability in scene size
  • Due to traversal of (hierarchical) spatial
    acceleration structures
  • For complex models, log scalability is most
    important !

13
Ray Tracing Log. Scalability
  • Logarithmic scalability in practice
  • Example from Isosurface Ray Tracing (similar for
    polygons)
  • Marschner-Lobb dataset Synthetically generated
  • From 32x32x32 voxels (32kVox) to 1024x1024x1024
    (1GVox)

14
Ray Tracing Log. Scalability
  • Logarithmic scalability in practice
  • Example from Isosurface Ray Tracing (similar for
    polygons)
  • Rendering time 2, for scenesize 104.5 !

15
Why use Ray Tracing for Massive Model Rendering ?
  • Logarithmic scalability
  • Essentially solves the complexity problem
  • Number of triangles not the main problem any more

16
Why use Ray Tracing for Massive Model Rendering ?
  • Triangles not the main problem any more
  • Proof by example Sunflowers scene
  • one billion triangles
  • Plus shadows, textures, transparency,
  • Rendered interactively on few PCs

17
Ray Tracing for Massive Model Rendering
  • Triangles not the main problem any more
  • So, wheres the problem ?

18
Ray Tracing for Massive Model Rendering
  • Triangles not the main problem any more
  • So, wheres 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 !
  • For general complex models usually not the case
  • Boeing 777 40GB on disk
  • Lawrence-Livermore dataset 24 GB (already
    compressed)
  • Full model actually 270x24GB (270 time slices)
  • ? Storage is worst indiv. problem of ray tracing
    MCMs.

19
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Christensen Multiresolution caching
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2002 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

20
Memory Coherent Ray TracingPharr, Siggraph97
  • Basic observation
  • Ray tracing ideally suited for complex models
  • But
  • Complex scenes wont fit into memory
  • Typical depth-first ray tracing destroys
    coherence
  • W/ global illumination Scene access usually
    (almost) random
  • Excessive OS paging and thrashing, huge rendering
    times
  • Basic idea
  • Do manual (explicit) caching/paging on suitable
    entities
  • Reorder computations to achieve coherence
  • Based on scheduler to minimize disk I/O
  • ? Avoid page thrashing, significantly improve
    performance

21
Memory Coherent Ray Tracing - Reordering
Computations
  • 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 ones
    rays are finished
  • Problem Highly incoherent scene access
  • Primary ray of 2nd pixel needs similar data as
    primary of 1st pixel
  • But Secondary rays of 1st pixel have already
    swapped out data
  • Solution Improve scene access coherence by
    reordering
  • Explicit caching
  • Know whats in memory at what time !
  • Reordering of rays
  • Based on ray scheduler that tries to minimize
    I/O
  • ? Trade uncontrolled OS paging for controlled
    disk I/O

22
MCRT Geometry Cache
  • Caching framework
  • 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, ...
  • If 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
  • Keep cache of currently loaded voxels (geometry
    cache)
  • Use fixed-size cache
  • If new voxel needs to be loaded, discard old one.
  • Plus texture cache, displacement cache, (no
    details here)

23
MCRT Ray Scheduling
  • 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 object
  • Add its contribution (ray weight surface
    emission) to pixel
  • Rays can be traced in any order
  • 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

24
MCRT Ray Scheduling
  • Basic scheduling algorithm
  • Generate eye rays and place them into respective
    queue(s)
  • While there are queued rays
  • Choose a voxel to process
  • For each ray in voxel
  • Intersect ray with voxels geometry
  • If there is an intersection
  • Run shader and compute BRDF
  • Insert spawned rays into voxels 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

25
Memory Coherent Ray Tracing Scheduling Overview
26
MCRT Results
  • Reordering significantly improves coherence
  • Always work on similar rays (same queue) at same
    time
  • In particular First iteration ? All primary rays
    in same queue !
  • 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
    possible
  • Significantly less paging
  • Can efficiently ray trace scenes much larger than
    memory

27
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 !!!

28
MCRT Results
  • Significantly less paging
  • ? Much faster rendering

29
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Christensen Multiresolution caching
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2002 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

30
Kilauea Data-Parallel Ray Tracing
  • So far Ray tracing ideally suited for complex
    models
  • if one can store the model
  • Pharr Reduce disk I/O if memory is too small for
    scene
  • Kilauea Use combined memory of several PCs
  • Combined memories of multiple PCs can hold entire
    scene
  • if its just enough PCs
  • But need data-parallel approach

31
Data-Parallel Ray Tracing
  • 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 RCs
  • NO 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 RCs voxel forward to RC
    having next voxel
  • Similar to MCRT, except
  • Forward to other RC instead of delay in queue
  • Can easily scale scene size
  • As long as sum(all RC memories) gt scene size

32
Data-Parallel Ray Tracing
  • Can easily scale scene size
  • As long as sum(all RC memories) gt scene size
  • 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

33
Kilauea Approach
  • as usual Distribute scene data over multiple
    RCs
  • 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)
  • Result is minimum of all hits found at any client
  • 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)

34
Kilauea Results
  • Additionally Same approach also for other data
  • Not only geometry, also for huge photon maps
  • ? Allows highly detailed photon maps even in
    complex scenes

35
Kilauea Results
  • Kilauea Efficiently combine multiple PCs
    memories
  • 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
  • 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

36
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Christensen Multiresolution caching
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2002 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

37
Christensen 2003 Multiresolution Geometry
Caching
  • Keep cache of loaded geometry voxels
  • Like MCRT
  • Plus Maintain multiresolution representation of
    scene
  • Defined by different tesselation levels of
    NURBS-modelled scene
  • Optimize cache use by selecting proper level
  • Select proper level by tracking ray
    differentials Igehy
  • Coherent rays detailed geometry
  • Incoherent rays coarse geometry
  • ? Efficiently avoids thrashing the cache by
    incoherent rays

38
Christensen Multiresolution Geometry Caching
  • Efficient cache utlization
  • Can render even highly complex models

39
Christensen Multiresolution Geometry Caching
  • Efficient cache utlization
  • Can render even highly complex models
  • 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

40
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2002 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

41
Interactive Ray Tracing
  • Parker/Muuss Interactive Ray Tracing
  • Idea Use ray tracing also for interactive
    applications
  • Already use for highly complex models
  • Muuss Outdoor scenes
  • Parker Complex Visualization datasets
  • 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

42
Parker et al.Interactive Ray Tracing
  • Shared-memory supercomputer cc-NUMA architecture
  • Also distributed memory, caching and
    demand-loading
  • done entirely by HW
  • Directly ray trace non-polygonal data
  • Direct ray tracing of isosurfaces
  • ? Massively complex datasets (visible female)
    without tesselation

43
Parker et al.Interactive Ray Tracing
  • Shared-memory supercomputer cc-NUMA architecture
  • Also distributed memory, caching and
    demand-loading
  • done entirely by HW
  • 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

44
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Christensen Multiresolution ray tracing
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2001 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

45
Saarland 2001 Distributed IRT for Massively
Complex Models
  • Basic Idea
  • Interactive Ray Tracing now (2001) possible
  • 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
  • MCRT heavily depends on extensive reordering
  • Interactivity significantly limits reordering
    capabilities
  • Therefore
  • Assume that at least working set fits into memory
  • Often need only small part of scene for each
    frame (occlusion,...)
  • Use reordering only for hiding loading latency

46
Saarland 2001 Distributed IRT for Massively
Complex Models
  • Cluster-based interactive ray tracing system
  • One server, multiple clients
  • Image-space load balancing (tile-based)
  • For complex models Cant replicate scene on each
    client
  • Caching framework
  • Similar to MCRT Voxelize geometry
  • Caching based on self-contained voxels
  • Use 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 network

47
Saarland 2001 Distributed IRT for Massively
Complex Models
  • Only caching doesnt suffice
  • Loading latency too high
  • Entire client stalls for several milliseconds on
    cache miss
  • Hide latency by reordering
  • 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
  • No reordering except on cache miss
  • Not for secondary rays, global illumination,

48
Saarland 2001 Distributed IRT for Massively
Complex Models
  • Results
  • 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 cache
  • 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
    geometry
  • Depends on low loading bandwidth ? temporal
    coherency

49
Saarland 2001 Distributed IRT for Massively
Complex Models
50
Outline
  • Motivation Why Ray Tracing for Massive Models ?
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2001 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

51
Saarland 2004 OOC Ray Tracing with
Proxy-Mechaisnm
  • The PowerPlant Since 2001
  • Ray tracer much faster
  • and much more memory-efficient
  • Can represent PowerPlant in lt 1GB
  • Much more memory on PCs
  • Can easily render PowerPlant on single PC
    (laptop)
  • Todays challenge The Boeing 777
  • 350 million triangles
  • Next generation (7E7) already being designed w/
    1,000 million
  • 12 GB raw triangle data (w/o kd-tree etc)
  • Unstructured soup of triangles

52
Saarland 2004 OOC Ray Tracing with
Proxy-Mechaisnm
  • Todays challenge The Boeing 777 (350 MTri)

53
Todays Challenge The Boeing 777
54
Todays Challenge The Boeing 777
55
Todays Challenge The Boeing 777
56
Todays Challenge The Boeing 777
Same complexity all over the model
57
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • 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
  • But Target single-PC setup (lt 8GB RAM)
  • ? Need OOC mechanism
  • Lessons learned from 2001-system
  • Asynchronous loading for latency hiding Great!
  • Avoiding OS page faults by manual caching Great!
  • But costly, fragmentation,
  • Reordering to hide latency Great, but
  • will never work for 777 Need far too much
    new data per frame

58
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • 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
  • memory management unit
  • Keep track of what data is in memory at what time
  • Difference to 2001
  • Work on OS pages, not on voxel files
  • Uniform caching domain (all data is handled in
    same way)
  • Less fragmentation, easier to use
  • Dont even try to load all data for stalling ray
  • Instead Kill off ray
  • and replace by proxy information

59
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • Killing off rays
  • In simplest form Just mark with constant color
    (red)
  • Anything is better than OS paging
  • Progressive loading Red pixels disappear over
    time
  • But artifacts during loading

60
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • Killing off rays
  • In simplest form Just mark with constant color
    (red)
  • Anything is better than OS paging
  • Progressive loading Red pixels disappear over
    time
  • But artifacts during loading

61
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • Proxies for missing rays
  • Dont 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
    models
  • RW2004 approach
  • Build proxies for certain subtrees of models
    kd-tree
  • Essentially for every subtree that may cause a
    cache fault
  • Analyze kd-tree in preprocessing step !
  • Proxylightfield-like representation
  • Averaged normal and material for N discretized
    viewing directions
  • Attach proxies to potentially faulting subtrees
  • If memory access faults, just use proxy

62
Proxy Quality OverviewOutside View (2GB
footprint)
  • Immediately after startup
  • (tiny fraction of data loaded)
  • without proxies
  • with proxies

63
Proxy Quality OverviewOutside View (2GB
footprint)
  • After loading for several seconds
  • (roughly equal amount of geometry loaded)
  • without proxies
  • with proxies

64
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • Proxy results
  • Need only few memory (lt1 GB for entire model)
  • Qualitatively better than red pixels
  • But Still artifacts due to incorrect (averaged)
    normal material

65
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • Proxy results
  • Need only few memory (lt1 GB for entire model)
  • Qualitatively better than red pixels
  • But Still artifacts due to incorrect (averaged)
    normal material
  • Eye very sensitive to such artifacts ?
  • In practice Often prefer red pixels
  • Psychology rather prefer really wrong to not
    convincingly real
  • Conclusion
  • OOCMMU is good
  • Proxies need to be improved
  • Need better representation for voxels

66
Saarland 2004 OOC Ray Tracing with proxy
mechanism
  • Proxy results
  • Need only few memory (lt1 GB for entire model)
  • Qualitatively better than red pixels
  • But Still artifacts due to incorrect (averaged)
    normal material
  • Eye very sensitive to such artifacts ?
  • In practice Often prefer red pixels
  • Psychology rather prefer really wrong to not
    convincingly real
  • Conclusion
  • OOCMMU is good
  • Proxies need to be improved
  • Need better representation for voxels
  • ? Question to the audience Any ideas

67
Outline
  • Todays challenge
  • Offline systems
  • Pharr Memory Coherent Ray Tracing
  • Kilauea Data-parallelism with ray forwarding
  • Interactive Systems
  • Utah Realtime Ray Tracing on Supercomputers
  • Massively complex visualization applications
  • Saarland 2002 Distributed RTRT for Massive
    Models
  • Cluster-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 data
  • Summary and Open Problems

68
Summary and Open Issues
  • Summary RT has several specific advantages for
    complex models
  • Built-in occlusion culling
  • Logarithmic scalability
  • Several special solutions for complex models
  • Scene complexity using massive instantiation
  • In particular for outdoor scenes
  • Ability to avoid tesselation in the first place
  • Direct ray tracing of isosurfaces
  • Similar for complex point-based models, NURBS
    scenes,

69
Summary and Open Issues
  • 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
  • NO system tries to reduce complexity for cost
    reasons
  • Only for reducing loading time and storage
  • ALL systems concentrate on scene storage problem

70
Summary and Open Issues
  • Overall Ray-tracing based MMR is very powerful
  • Boeing 350 MTris on single PC
  • Kilauea High-quality global illumination
  • With highly complex photon maps
  • Utah Massively complex volumetric datasets
  • Including high-quality shading
  • But Still a lot to do
  • Models get bigger and bigger
  • Much quicker than PCs get faster
  • Still many unsolved problems

71
Summary and Open Issues
  • Biggest Problems left over
  • Antialiasing
  • More triangles ? more detail/pixel ? aliasing
  • Need more rays/pixel for more complex scenes
  • Efficient multiresolution approach
  • What to do about missing data
  • Cant always wait for data Boeing-proxies not
    sufficient
  • Efficient parallelization
  • Currently either data parallel (scales in model
    size)
  • or image-space parallelism (scales in
    performance)
  • but not both.

72
Thanks for your attention
Write a Comment
User Comments (0)
About PowerShow.com