Interactive Ray Tracing #2

Peter Djeu

April 22, 2003

Interactive Ray Tracing

S. Parker, W. Martin, P. Sloan, P. Shirley, B. Smits, C. Hansen

The University of Utah

Goals• Implement a brute force interactive ray

tracer in software for the SGI Origin 2000– hardware renderers are inflexible, whereas

software renderers can be extended and re-tested with new algorithms

• Study and try to compensate for the problems that come with interactive ray tracing (e.g. lighting, shadows, splines)

Why is Ray Tracing Appealing?1. It scales well (keep throwing processors at

the problem until the renderer is interactive)

2. Rendering time is sub-linear in the number of primitives in the scene (unlike rasterization, which is linear)

3. Ray tracing is more flexible and the image quality is better (ex: more primitives are allowed, ray tracing generates shadows, highlights, transparency)

Overview of the System (page 1)

Overview of the System (page 2)

Rendering Mode 1:Conventional Mode

• Create a static set of ray bundles (called jobs) where the job size spans a range of sizes. Use first-come first-served, assign larger jobs first, and towards the end the smaller job size will cause load-balancing.

• When all bundles have been processed, display the current frame.

Conventional Mode: Diagram

The Nitty Gritty of Conventional Mode

• Use job sizes that are multiples of 128 bytes. This is because the machine has 128 byte cache lines (no false sharing).

• Use the Origin’s fetch and op instruction for as a fast synchronization tool– 61 sec on Origin vs. 6 msec on Irix, a big

difference

Thoughts on Conventional Mode

• Good: The algorithm is very simple, but still achieves load balancing.

• Bad: How many bundles should be created? How large should the largest bundles be? Other limits to a static algorithm…

• Bad: How are rays grouped into bundles? Do the bundles respect locality (like in Pharr’s paper)?

Rendering Mode 2: Frameless

• Assign a set of pixels to each processor.• Each processor will compute its set of

pixels as fast as it can, but the screen will be updated at an independent rate.

• We get guaranteed framerate at the cost of inconsistent image quality.

Frameless Rendering: Diagram

Thoughts on Frameless Mode

• The two competing goals for locality are interesting: when assigning pixels, strong locality means better cache utilization, but strong locality also means that an entire portion of the screen may have a noticeable artifact if that particular processor is overburdened.– How do find a balance?

– Or does such a tradeoff completely kill frameless rendering?

• Where are the pictures of frameless mode?

The Transition to Interactive

• A static ray tracer can use a variety of hacks which do not apply to interactive ray tracers (ex: lighting and object’s material hacked based on viewpoint)

• The authors propose some new ray tracing techniques to improve: lighting, material models, shadows, intersection computations.

Whitted Lighting and a Material Model with Categories

• A robust lighting model with coefficients that determine the category and visual appearance of materials. For efficiency, coefficients that are not needed are set to 0:– Diffuse: no highlights nor specular, just diffuse

– Metal: no diffuse, just specular and highlights

– Dielectric: (ex: glass, water), formula used for specular coefficients

– Polished: complex formula used for overall color

Ambient Lighting

• Problem: Ambient light is usually hacked in to a ray tracer so that points not directly in light are lit up. However, if they face away from the light, these regions appear flat (no real ray tracing occurs).

• Solution: assign a color to “fully facing the light” and a color to “fully facing away from the light.” For all surfaces, find an interpolated color. No need for additional light rays.

Directionally VaryingAmbient Lighting

• Problem: Ambient light is usually hacked in to a ray tracer so that points not directly in light are lit up. However, if they face away from the light, these regions appear flat (no real ray tracing occurs).

• Solution: assign a color to “fully facing the light” and a color to “fully facing away from the light.” For all surfaces, find an interpolated color. No need for additional light rays.

Directionally VaryingAmbient Lighting in Action

Inner / Outer Object Shadowsto Approximate Area Lights

• Problem: Realistic shadows have an umbra and a penumbra created by area lights, not hard shadows

• Solution: treat an area light as a point. Based on the size / shape of the light, construct an inner and outer object for the shadow caster. Create two shadow regions, and interpolate the transparency between them to simulate the soft shadow.

Diagram of Inner / Outer Objects

Picture of Soft Shadows in Practice

Subdividing Spline Surfaces

• Problem: Usually, splines are tessellated in ray tracers, which means there can be an explosion in memory usage and / or pipeline saturation

• Solution: use a bottom up technique of creating bounding volumes, then compute intersections using Broyden’s method. This is fast (~ 3 iterations / query) and is memory efficient.

Results: page 1

Results: page 2

Results: page 3

• Rendering Room scene (small scene): 9.4 Mb/s• Rendering the Female Dataset (large scene): 2.1

Mb/s to 8.4 Mb/s, note this is less than before• Most scenes fit within 4Mb of secondary cache

• Dynamic (aka moving) objects: no acceleration, they are processed using the standard algorithm

• Depth complexity has little effect on rendering speed.

Critique of Results (page 1)

• Why does one chart go up to 64 proc.’s, while the other have a max of 128 proc.’s?

• How was the ideal performance calculated? Note that the ideal line is NOT the same on both charts: (64, 7x) vs. (64, 10x)

• Why is there a drop-off in both charts?– Any ideas?

Critique of Results (page 2)• No attempt was made to explain why a larger

scene “ironically” uses less memory bandwidth than a smaller scene.– Coherence? Occlusion? Something else?

• Will most scenes in the future fit within the secondary cache (4 Mb in this case)?

• The authors mainly address the making of an interactive ray tracer for static scenes. The results presented seem more like an afterthought.

Conclusions

• There is still much work to be done in the world of ray tracing, including:– anti-aliasing, dynamic scenes, performance

guarantees, API creation, hardware

• Creating (and using) better ray tracers means that we will be better able to focus our efforts for future work– usefulness of soft shadows, BRDF’s, reflect’s

State of the Art inInteractive Ray Tracing

I. Wald and P. Slusallek

Saarland University, Germany

Goals

• Create a survey of contemporary raytracing. Topics include:– the weaknesses of rasterization– different ways to ray trace– ray tracing on different platforms

(supercomputers, PC’s, PC clusters)– recent research

• Talk about their research

Problems with Rasterization

• With respect to the number of polygons in the scene, the complexity if O(n) rather than O(log n)

• Hard to scale to parallel architectures because of high communication needs

• Hard to incorporate a shader into the pipeline

Another look at Rasterization

• O(n) rather than O(log n)– since when has O(n) been a problem in terms of

scalability? Of course, O(log n) is better, but…

• Hard to scale to parallel architectures

• Hard to incorporate a shader– is this still true when we have shader languages

such as Cg and MS Cg?

Benefits of Ray Tracing

• Flexible– different types of rays, different primitives

• O(log n)• Shading only done on visible components• Shaders easier to add (no pipeline) (?)• Correct reflections, refractions• Parallel and Scalable• Coherent when using a Pharr-like algorithm

Raytracing is faster, but….

• Almost all tests currently use just primary rays.

• Shadows and reflections will drop frame rate by a constant factor.

• Acceleration structures like BSP trees are the source for the speed, but they are heavily dependent on static scenes. They do not (currently) support dynamic objects.

Different Forms of Ray Tracing

1. Rasterization-Based – do a quick rasterization pass, and then add ray traced effects (artifacts)

2. Image-Based – kind of like frameless rendering from Parker’s paper (artifacts)

3. Approximation-Based – sample certain regions and interpolate (artifacts)

4. Acceleration-Based – construct fast-culling data structures, exploit coherence, respect the memory hierarchy (no artifacts?)

Approximate Ray Tracing

• Main idea: the visual feedback from interactivity (i.e. frame rate) can often be more important than visual correctness– ex: Sonic 2 and Blast Processing

• Examples:– Rasterize, then use corrective textures for highlights

– the RenderCache reuses rays within error bound (however, this is great for off-line global illumination)

– the Holodeck keeps all generated rays on disk, reuses

Perceptually Guided Corrective Texturing

Ray Tracing Platform 1: Supercomputers

• Using a 96-proc. SGI PowerChallenge, Muuss was able to ray trace a scene that could not be rasterized (1995)

• Parker et al. used an SGI Origin 2000 to create a ray tracer that could support triangle and non-triangle scenes (1999)

Ray Tracing Platform 2:Desktop PC’s

• Why?– Supercomputers are rare, while PC’s are

everywhere– Work for stand-alone PC’s could lead to

efficient ray tracers on cluster PC’s

• Challenges of using a CPU– reduce branches and complexity, respect the

memory hierarchy, reduce memory bandwidth

Points to Note on the Desktop PC Implementation

• Shading takes up far less than 10% of the total rendering time

• SIMD CPU instructions (aka vector ops) produce only a 2x speedup– Do 4 rays on one tri., not 4 tri.’s on 1 ray

• Wald’s implementation was compared to freely available POV-Ray and Rayshade– 11x – 15x speedup

Table 2 (less is more)

Ray Tracing vs. Rasterization (on Desktop PC’s)

• We can already achieve the crossover point (see bottom row of the next slide)

• SGI Performer (a rasterizer) running on powerful desktops is comparable to ray tracing on a more modest desktop

Table 3 (bigger is better)

Conclusions from Desktop PC Results

• Raytracing has a high startup cost per ray, but…

• It scales well as scenes get more complex, a crossover point exists regardless of screen resolution

• You can do correct reflections, etc.

Figure 8

Ray Tracing Platform 3:Clusters of PC’s

• Because ray tracing is embarrassingly parallel, let’s try to build a cheap PC cluster-based ray tracer

• Challenges:– no shared memory on PC clusters

• Setup: a scheduling machine, a display machine, and lots of processing machines

Data Management in the Cluster World

• An NFS based data fetch system blocks on a data miss, and this is too costly

• Instead, the scene cache is managed in software via an asynchronous loader thread, a ray is suspended until its data arrives

• Compression-Decompression is used for voxels transferred over the network

Other Issues in the Cluster World

• Preprocess - Create an adaptive BSP tree with small voxels in detailed regions and large voxels in sparse regions, O(n log n)

• Load balancing – assign voxels to machines that have already done them, only good for small scenes

• Interconnect – Gigabit ethernet and switch– is this fair?

Results for the Cluster Ray Tracer

• On a 12.5 million tri. power plant model, 3-5 fps almost constantly (8-10 fps with SIMD instructions), comparable to rasterizer

• Adding reflective rays: the performance hit is proportional to # of traced rays, reduced coherence -> little effect on performance (!)

• Stress test of a 4x Power Plant (50 million tri’s) found that indoor scenes were not affected (2 extra BSP tree levels), while outside scenes with motion suffered from large voxel transfer over network

Network Saturation vs. Scalability

Hardware Support in the Future

• RAYA – simulations say build a ray tracer on a single chip

• Smart Memories – a programmable and configurable architecture, should be able to get 50 fps at 512 x 512 (!)

• Saarland’s own architecture – a ray tracing pipeline, coherence is enforced by having rays traversal and intersection on a clock

Smart Memories

Saarland’s Pipeline

Ongoing Ray Tracing Research

• Dynamic scenes– some work done, Reinhard proposes making

large objects live in coarser levels of the hierarchy to maintain constant update cost

• Ray tracing API– try to make it like OpenGL, like C and Java

• Interactive Global Illumination– more like an application of ray tracing

Reinhard on dynamic hierarchies

Parting Thoughts

• Ray tracing and rasterization are, in a way, converging– Occlusion culling, hierarchical z-buffer, advanced

shading

• Still different in that ray tracing selects only the geometry needed, while rasterization needs to conservatively send all tri’s that might be visible

• “We strongly believe that what we see today is only the beginning of an exciting new field of computer graphics.”