Scattering Secondary RaysScattering Secondary Rays

Gordon Stoll, Intel

Scattering Secondary RaysScattering Secondary Rays

What’s with all the cheesy ray tracing?

Gordon Stoll, Intel

State of Graphics TodayState of Graphics Today

• More or less indistinguishable from reality

– huge caveat: performance

• This leads to a bifurcation of techniques

– for full speed, you use rasterization

– for full quality, you use ray tracing

• We really want full speed w/ full quality (duh)

• Claim: Rasterization won’t get us where we want to go (the algorithms, not the hardware).

That doesn’t look like RT…That doesn’t look like RT…

• Real-Time Ray Tracing saves the day?

• Right now, more like a trifurcation…

– for full speed: rasterization

– ????: cheesy ray tracing too much of today’s RTRT

– for full quality: “real” ray tracing

• Claim: Cheesy ray tracing won’t get us where we want to go either.

The Elephant in the RoomThe Elephant in the Room

• Very fast progress in the last few years

– Largely exploits coherence in ray behavior

• packets, frustums, memory layout, SIMD, caches, …

– Largely applied to rays that exhibit coherent behavior

– ...everybody see the problem?

• Are these techniques effective for more difficult cases? How do they behave? Are there better designs for these cases?

Scattering Secondary RaysScattering Secondary Rays

Scattering Secondary RaysScattering Secondary Rays

Scattering Secondary RaysScattering Secondary Rays

Scattering Secondary RaysScattering Secondary Rays

• In the past, we would say “RT is logarithmic!”

– dynamic scenes

• the right representation, plus laziness, might work

– frustum/packet/SIMD traversal and esp. intersection

– caches

• Fix the bad cases? Avoid them? Give up?

Plan of AttackPlan of Attack

Plan of AttackPlan of Attack

A) Give up

Plan of AttackPlan of Attack

A) Give up

– don’t depend on coherent ray behavior

B) Don’t give up

– maintain / create coherent ray behavior

Plan of AttackPlan of Attack

A) Give up

1) build systems that aren’t (as) dependent on coherence

• pure streaming approach (Purcell?)

2) change/improve individual components

• HW-efficient ray/triangle intersector that’s not N-ray-SIMD

B) Don’t give up

– maintain / create coherent ray behavior

Plan of AttackPlan of Attack

• B) Don’t give up

1) ray side techniques

• ray grouping (clever packets; local vs global?)

• ray regrouping (intra-traversal as per Pharr)

• algorithmic (Instant Global Illumination, etc.)

2) geometry side techniques

• multiresolution / LOD (Pixar paper, Razor)

Previous WorkPrevious Work

• Tim Purcell’s thesis

• Solomon Boulos’s distribution RT work

• Matt Pharr’s reordering paper

• Instant Global Illumination

• UNC R-LODs

• Pixar multires paper

• Razor

Multiresolution, LOD, “Razor”Multiresolution, LOD, “Razor”

*Character models © 2003-06 Digital Extremes. All rights reserved.

RazorRazor

• Research in Ray Tracer Architecture

– Goals

• all out on visual quality and features

• plan of attack “B” – maintain/create coherence

– Design elements

• new dynamic geometry handling schemes

• multiresolution / LOD

– adaptively tessellated surface patches

• new shading scheme

Multiresolution / LODMultiresolution / LOD

scattering secondary rays

Multiresolution / LODMultiresolution / LOD

scattering secondary rays

detailed scene database

Think SamplingThink Sampling

• Scene representation is set by primary rays

– relatively high frequencies are required

• Secondary rays want a much lower cutoff

– orders of magnitude

• Frequency mismatch

– classic sampling problem for us rendering folks

– two options

• pre-filtering (as for a MIP-mapped texture)

• irregular sampling and post-filtering

Don’t Just Think SamplingDon’t Just Think Sampling

• Not just a sampling problem!

• Big systems problem

– irregular access to a big database

– post-filtering solution doesn’t touch this problem

– pre-filtering solution does

• MIP-mapping is the iconic example

– makes texture filtering output-sensitive (principle of texture thrift)

Multiresolution / LODMultiresolution / LOD

specular diffuse

fraction of database being sampled

size of database being sampled

Pre-Filtering is HardPre-Filtering is Hard

• We’re not talking about a stored texture map

• May be hard to do, or hard to do “enough”

• For now limiting ourselves to a fairly easy case

– adaptive tessellation of surface patches

– still pretty hard to do well

– hard to tessellate accurately to a target LOD

– limited by original patches (can’t go coarser)

Next big question…Next big question…

• How?

– very little information out there on how to do this

– at least, implement ray/path differentials

• have to for texturing and programmable shading anyway

– implement some kind of multires representation

• we did adaptively tessellated surfaces

• could do progressive meshes, volumes, full LOD, etc.

• Lots of tricky bits, though.

Ray-Varying LODRay-Varying LOD

• Root of most problems is ray-varying LOD

• What LOD does the ray want?

– function of many different differentials

– depends on the parents in the ray tree

– different for every ray

– a complex function of “t” along the ray

• VERY different from traditional LOD

TunnelingTunneling

TunnelingTunneling

TunnelingTunneling

TunnelingTunneling

Fixing TunnelingFixing Tunneling

• Root of the problem

– using discrete LOD levels

– allowing ray-varying LOD

• Our solution

– stick with discrete LOD levels

– “Geomorphing”

– interpolate between those levels

• effectively intersect with a continuously varying surface

Big ChallengesBig Challenges

• Local ordering

– good techniques/heuristics for local packet ordering

– efficient implementations

– limits of local reordering

• Global ordering

– investigation of Pharr-like techniques for fast RT

• Global “a priori” ordering

– GI algorithm “X” evaluated/tweaked for coherence

Big ChallengesBig Challenges

• Appearance preserving multires/LOD

– classic open problem, not going away

– not just our problem (by a long shot)

• Full topological/volumetric LOD vs. just multires

– a single surface patch may be too fine-grained

– even a single object may be too fine-grained

Shading in RazorShading in Razor

Gordon Stoll, Intel

Fixing Shading in RTFixing Shading in RT

• Shade in coherent batches

– rays in a packet can hit anything

– processing and data access are too irregular

• Limit the total number of times we shade

– high oversampling can cause problems here

• Provide differential information

– texture and shader pre-filtering

MicropolygonsMicropolygons

• REYES-style shading

– shade on a grid of micropolygon vertices

– cache the results

• Advantages

– batches are highly coherent

– can shade at less than the oversampling rate

– differentials are relatively easy

– displacement mapping is possible

Micropolygon Ray TracingMicropolygon Ray Tracing

• Multiresolution RT makes this conceivable

– tessellate adaptively to <1 pixel triangles

– shade on grids of vertices

• Very aggressive design decision

– pushes the envelope for coherence-based techniques

• Can’t do all RT shading on the grid, though

– can’t cache incoming-ray dependent stuff

Two-Phase ShadingTwo-Phase Shading

• Common idea in physically-based rendering

– 1) compute material properties on the surface

– 2) bounce rays off of the result of shader #1

– (PBRT does this)

• Can think of this as compute BRDF, then evaluate (but we don’t).

Shading in RazorShading in Razor

• Most aggressive design element

– Split-Phase Shading, Phase #1 on uP grids

• Pluses and Minuses

– requires accurate adaptive pixel-level tessellation

– accurate curved surfaces, displacement mapping

• Could back off to coarser tessellation

– shade on an inset sub-grid, or just shade normally

Preliminary ResultsPreliminary Results

• Number of shading operations

– various causes of over/under tessellation

– all told, we shade 6-7 vertices per pixel

• Cost of shading operations

– coherent batches – haven’t evaluated yet (how?)

• Miscellaneous benefits

– all differentials available in phase #1

– displacement mapping possible