Fall 2000 Research Work	Goal: Add interreflections and other global illumination effects to raytracing at an interactive rate.

Update Thursday, November 16: Well, I've actually got some images with caustics. I haven't timed the for framerates on rapture, but since the code to add (stationary) caustics just affected the preprocess stage and some of the not-so-time-consuming (according to SpeedShop) recursive function calls, the frame rate should be similar to the framerate without caustics.

Right now the caustics are only implemented for transparent objects, and they only cause caustics on certain types of surfaces (though it is easily extendable to other objects). I do have to check if special things need to be done if the caustics land on a non-lambertian surface, however.

Hopefully I can get some caustics on the mobile objects now...

Below are some images:

Most recent image. No bugs (that I can tell)	A bunch of spheres...
Earlier test of the caustics, a few bugs	Earlier test of the caustics, some bugs

Update Monday, November 12: So up until now, I had been atempting to get interreflections in entirely diffuse environments. Once I attained a decent working implementation, I spent time optimizing it to run quickly. As you can see from my previous updates, I sped up the results by a factor of more than 4, finally getting to a point where adding interreflections (at least in the simple scenes I was working on) only slowed the raytracer down by a factor of 1.6.

Now, the goal is to add similar effects for non diffuse environments while maintaining a reasonable frame rate. Additionally, I'd like to add other effects specific to non Lambertian environments, such as caustics.

While I haven't really attained any of these goals since I last posted results, I have added reflective object which still retain the interreflective properties of my diffuse implementation. I am currently working on a similar effect for refractive (transparent) objects. Once I get this framework in, I'll have the basis for some experimentation of effects such as caustics, which I have a few ideas about how to go about implementing.

Below are some of the images I've generated recently. I haven't decided yet if the interreflective effect you see here looks as realistic as it did on the Lambertian surfaces. Some changes may still need to be made here.

Framerates are either representative of the results on 32 processors or are representative of the results of running the raytracer remotely (where the network bandwidth limits framerates to slightly under 1 frame per second).

A reflective ceiling	The block in a different place
The block is also reflective	The block in a different place
Everything is reflective	The block in a different place
Both blocks are shaded using a metal material and the Irradiance Volume (above the small block used precomputed materials like the walls)	The block in a different place

Update Thursday, October 26: So you might ask exactly how fast is this system that I've put together. My last update described some of the optimizations I performed on my code, but this time I have some performance numbers to prove that indeed I sped things up. For comparison with the numbers below, my original implementation got 0.45 fps on 8 processors (which is roughly 0.9 fps on 16 processors).

The following graph shows the effect of increasing the number of rays per cell of the irradiance volume while keeping the number of cells constant (vertical axis is the number of frames per second):

Using a 6 x 6 x 6 irradiance volume, varying the number of rays at each grid cell
(from 2 * (7 x 7) to 2 * (15 x 15)), yellow: 32 processors, purple: 16 processors
The image at the top of the page is done with a 6³ grid, 2 * 7² rays

The next series of graphs show the result of increasing the number of grid cells while keeping the number of rays per cell constant. In all images, the yellow line is for 32 processors, the purple line is for 16 processors.

Using 98 rays per irradiance volume cell (7 x 7 per hemisphere)
Changing the number of cells along the X-axis, FPS along the Y-axis,
the number of cells goes from 6³ to 50³


Using 242 rays per irradiance volume cell (11 x 11 per hemisphere)
Changing the number of cells along the X-axis, FPS along the Y-axis,
the number of cells goes from 6³ to 50³


Using 450 rays per irradiance volume cell (15 x 15 per hemisphere)
Changing the number of cells along the X-axis, FPS along the Y-axis,
the number of cells goes from 6³ to 50³

Update Monday, October 23: So far this fall, I have been working on optimizing my code for interreflections that I worked on this summer.

I've tried numerous methods of optimizing the code, some worked, some didn't, and some failed miserably. Because the code I wrote is part of a larger base of code, the Realtime Raytracer, some of the common "optimizations" actually made the program slower, and some strange things which normally would have no effect produced a speedup.

Below is a list of some of the optimizations I looked at (the ones I can remember), and a qualitative description of what sort of speedup it gave. (Unfortunately, I didn't keep track of numbers during my experimentation, just determined if an "optimization" helped or hurt):

• Typical things like folding constants together, changing divides into multiplies, reordering operations to eliminate more expensive multiplies (like multiplying a color by a constant, which is actually 3 multiplies). Some of these had no effect (because the compiler already did them), some had particularly large effects when in inner loops.
• Reordering code to keep operations on the same operands close together to improve cache hits. The compiler does lots of this, but I tried to do it even when there were loops and conditionals in the way. This was only a minor speedup.
• I examined array structures and positioning in memory, but generally, the straightforward way of working with my arrays was to traverse them in order, so generally the cache performance was good before I looked at optimizing it.
• The Irradiance Volume was a big bottleneck during execution, and I focused lots of time on speeding up the lookup into the array. Earlier in the summer, I ran through my (porcupine) array of direction vectors twice per lookup into the Irradiace Volume (since the array only covered a hemisphere). I got roughly a 20% speedup by cutting this down to one traversal of the array (and looking in 2 directions per loop iteration). I further sped this up by summing one hemisphere during the preprocess, so an addition is only necessary if the dot product is negative rather than positive (which cuts roughly 50% of the additions). Since this is one of the very innermost loops of the program, this give a big speedup.
• For a while, I was calculating the dot product of a normal vector with each of my 49 direction vectors inside the Irradiance Volume lookup. I then called the lookup function 8 times per object intersection (for tri-linear interpolation). Repositioning the dot product calculation so that it was only done once gave a small speedup (smaller than expected, since the memory access time dominated the multiplication cost, and the memory access is still required).
• Another ploy which I tried with the dot product calculation is as follows: I'm calculating a dot product with 49 vectors, and all I care about is if the result is greater than or less than 0. If I can bound the change in dot product value from one vector to another, I may not have to calculate the value for every vector. This ploy works really well if I increase the number of vectors in my hemisphere (say to 225), but it actually slows down slightly when only using 49 vectors per hemisphere.
• Seemingly strange optimizations: I changed "result = result + color" to "result += color" and got an immediate 10% speedup (it was in an inner loop). After thinking about how classes work, this makes sense, but my gut instinct as a C (not C++) programmer was to be astounded.

Last Modified: Thursday, November 16, 2000

Chris Wyman (wyman@cs.utah.edu)