Ray Tracing: Efficiency and Extensions, Study notes of Computer Graphics

Classical ray tracing, focusing on efficiency and extending its capabilities. Topics include ray tracing algorithms, spatial data structures, and distributed ray tracing for phenomena like glossy reflections and soft shadows. The document also discusses the importance of efficient code and implementation details.

Typology: Study notes

Pre 2010

Uploaded on 03/16/2009

koofers-user-r86
koofers-user-r86 🇺🇸

10 documents

1 / 5

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
Where We Left Off: Classical Ray Tracing
What we’ve seen so far is usually called classical ray tracing
it was the method used by most early ray tracers
To refresh our memories, it most important features are
trace eye rays through each pixel
at intersection with nearest surface
trace rays towards lights to check for shadow
recursively trace reflected and transmitted rays
supersample with multiple rays per pixel for antialiasing
Starting with this, we want to look more closely at two issues
how to make sure we’re ray tracing efficiently?
how to extend this to encompass more visual phenomena?
Ray Tracing Efficiently
The primary path to efficiency
avoid tracing rays whenever possible
and above all, avoid ray–surface intersection tests
A ray tracing system can be easily overcome with rays
minimum 1 eye ray per pixel, many more with supersampling
recursion depth kyields 2
k+1
−1rays traced per eye ray
counting reflection & transmission rays but not shadow rays
Consider this example
image resolution of 1024x768 = 786,432 pixels
3x3 supersampling = 7 million eye rays
recursion depth 5 = 63*7 = 441 million
each tested against 10,000 polygons
4.4 trillion intersection tests (ignoring shadow rays)
Spatial Data Structures
Probably the single most important efficiency improvement
divide space into cells
record what geometry lies in each cell
first test rays against cell
only check geometry within cell if the ray actually hits the cell
Several data structures in common practice
hierarchical bounding volumes
BSP trees
octrees
regular 3-D grids
Hierarchical Bounding Volumes
Begin by intersecting ray with the root volume
if no intersection, ignore all child volumes
otherwise, recursively test child volumes
We’ll only test objects whose bounding volume is actually hit by ray
hopefully ignoring most of the scene
but this depends a lot on the structure of the hierarchy
pf3
pf4
pf5

Partial preview of the text

Download Ray Tracing: Efficiency and Extensions and more Study notes Computer Graphics in PDF only on Docsity!

Where We Left Off: Classical Ray Tracing What we’ve seen so far is usually called classical ray tracing

  • it was the method used by most early ray tracers

To refresh our memories, it most important features are

  • trace eye rays through each pixel• at intersection with nearest surface
    • trace rays towards lights to check for shadow– recursively trace reflected and transmitted rays
      • supersample with multiple rays per pixel for antialiasing

Starting with this, we want to look more closely at two issues

  • how to make sure we’re ray tracing efficiently?• how to extend this to encompass more visual phenomena?

Ray Tracing Efficiently The primary path to efficiency

  • avoid tracing rays whenever possible• and above all, avoid ray–surface intersection tests

A ray tracing system can be easily overcome with rays

  • minimum 1 eye ray per pixel, many more with supersampling• recursion depth

k

yields

k

rays traced per eye ray

  • counting reflection & transmission rays but

not

shadow rays

Consider this example

  • image resolution of 1024x768 = 786,432 pixels• 3x3 supersampling = 7 million eye rays• recursion depth 5 = 63*7 = 441 million• each tested against 10,000 polygons• 4.4 trillion intersection tests (ignoring shadow rays)

Spatial Data Structures Probably the single most important efficiency improvement

  • divide space into cells• record what geometry lies in each cell• first test rays against cell• only check geometry within cell if the ray actually hits the cell

Several data structures in common practice

  • hierarchical bounding volumes• BSP trees• octrees• regular 3-D grids

Hierarchical Bounding Volumes Begin by intersecting ray with the root volume

  • if no intersection, ignore all child volumes• otherwise, recursively test child volumes

We’ll only test objects whose bounding volume is actually hit by ray

  • hopefully ignoring most of the scene• but this depends a lot on the structure of the hierarchy

BSP Trees, Octrees, and Grids Use BSP tree to traverse scene from front to back

  • start at root plane• figure out which side the viewpoint is on• descend on that side first; do this recursively

Helps us avoid unnecessary work

  • can tell when closest intersection found• because we’re going front to back

Can use grids & octrees similarly

  • traverse grid with 3-D DDA algorithm• octree a little trickier

A

B

C

Efficiency Through Good Code Ray–surface intersection code is executed

many

times

  • 4.4 trillion in the previous example• it is absolutely critical that this code be efficient

Some general tips for efficient code

  • use the best available algorithm for intersection test• keep track of number of operations (# adds, multiplies, …)• don’t compute values unless necessary
    • particularly important for expensive things like

sqrt()

  • and once computed, don’t recompute them
    • always use the cheapest method to calculate something
      • e.g., always

x*x

and never

pow(x, 2)

  • avoid excessive conditional branches (i.e.,

if

for

while

Details to Watch in Implementation Make sure ray directions are always unit vectorsMake sure vectors are pointing in right direction

  • surface normals• incoming & outgoing directions (look at diagrams closely)

Make sure you get the right intersection

  • ignore negative intersections behind the ray origin• watch out for self-intersection of recursive rays
    • caused by floating point imprecision

L

n

v r

n

θ

I

θ

r

Recall the Structure of Shading Procedure rgbColor shade(surface s, ray r, double t)

point x = r(t)rgbColor color = blackfor each light source L

if( closest_hit(shadow_ray(x, L)) >= distance(L) )

color += shade_phong(s, x)

color += k_specular * trace(reflected_ray(s,r,x))color += k_transmit * trace(transmitted_ray(s,r,x))return color

What does this simulate?

  • Phong illumination+shadows (direct lighting of plastic)• perfect specular reflection (mirrors, chrome)• perfect specular transmission (glass, crystal)

Distributed Ray Tracing: Glossy Reflections Our current method simulates perfect specular reflection

  • is only really true for perfect mirrors• simulates metals like chrome fairly well

Most surfaces are imperfect specular reflectors

  • reflect rays in cone around perfect reflection direction• glossy reflections rather than mirror images• Phong model tries to fake this kind of thing

We can directly simulate real glossy reflection

  • for an incoming ray direction
    • instead of always shooting ray in perfect reflected direction– stochastically sample rays within cone of reflected directions
      • strength of reflection drops off rapidly from mirror direction• probability of sampling that direction should fall off similarly

The Structure of Soft Shadows

Area Light Source

Occluder

or

Blocker

Umbra

(complete shadow)

Penumbra

(partial shadow)

Penumbra

(partial shadow)

Distributed Ray Tracing: Soft Shadows

Our previous shadow method

  • for the point we’re shading• cast a ray towards point light• hit surface before light = shadow• otherwise no shadow

Extends directly to area lights

  • sample multiple spots on light• look at fraction hitting surfaces• indicates level of shadow
    • none hit = full illumination– all hit = full shadow– some hit = partial shadow

Efficiently Distributing Rays Simple way to implement distributed tracing is dreadfully slow

  • every time we’re shading a surface point
    • shoot several rays at the light source– shoot several rays in reflected direction cone– shoot several rays for other phenomena we’re sampling

Fortunately, we can do much better than this

  • we’re already shooting say 16 rays per pixel• for each one, pre-determine how it will be distributed
    • specific location on light, angle from mirror direction, etc.
      • spawn usual recursive rays: 1 shadow, reflected, transmitted
        • they inherit the predetermined distribution values from eye ray
          • we’ll shoot exactly the same number of rays as basic tracing

One Practical Implementation Strategy Must predetermine all the quantities we want to distribute over

  • generate a table with one entry for every shot per pixel• fill in values in the table according to appropriate distribution of values• for each sub-pixel eye ray, randomly assign an index• every time this ray or its descendents strike an object
    • generate necessary recursive rays (shadow, reflection, transmission)– they inherit the index and are distributed according to table entry

Index

Time offset

Subarea oflight source

Reflected

angle offset

1

+0.01sec

Section 4/

1.5%

2

-0.03sec

Section 1/

0%

9

+0.2sec

Section 8/

0.2%