CS 6620.001 "Ray Tracing for Graphics" Fall 2014

Welcome to my ray tracing site for the course CS 6620.001, being taught at the University of Utah in Fall 2014 by Cem Yuksel.

Welcome fellow students! I have lots of experience tracing rays, and with graphics in general, and so I'll be pleased to help by giving constructive tips throughout (and I'll also try very hard to get the correct image, or say why particular images are correct as opposed to others). If you shoot me an email with a link to your project, I'm pretty good at guessing what the issues in raytracers are from looking at wrong images.

Hardware specifications, see bottom of page.

Timing information will look like "(#t #s ##:##:##)" and corresponds to the number of threads used, the number of samples (per pixel, per light, possibly explained in context), and the timing information rounded to the nearest second.

Project 2 - "Shading"

I got excited and added physically-based BSDFs to my raytracer, but I had a hard time working that in with this Blinn–Phong nonsense. So, I had to restructure a bunch of stuff to get it to work.

One interesting feature of my BSDF handling is that it handles multi-layer surfaces very naturally. Surfaces are supposed to be represented as at least one, and up to any number of, layers. For example, car paint might be modeled as a specular layer over a diffuse layer. The interaction of light with the layer (its BSDF) is baked into a 3D table and stored with the layer. The material itself is computed as the combination of these layers along all possible modes of light transport. I wasn't finished implementing all this when this assignment came up, though, and restructuring broke a lot of things.

Point of fact, the implementation below uses a single layer precomputed into the 3D table. The table is sampled using trilinear filtering. Other than that, it uses Blinn–Phong (of various varieties). When one says "Blinn–Phong", it's hard to know exactly what is meant. These non-physical BRDFs mainly come from hackish approximations. My renderer, which tries to be physically based, doesn't always react in the way these non-physical BRDFs expect.

In particular, there is the rendering equation (my explanation), which has a cosine term in it. This cosine term is actually the same cosine term you see in some formulations of the diffuse calculation. The diffuse BRDF is actually a constant; that cosine term is actually part of the rendering equation!

Anyway, the term is important for all BRDFs, but for these hackish sort of things, no one cares. Plus there's "ambient light", which is really hackish . . .

Here's what the Blinn–Phong model looks like with ambient light added directly to the pixel color and using the (correct cosine term) (16t 100s 00:03:01):

Rendering.

This is nice. Maybe you prefer the ambient term multiplied by the diffuse color before being added. In that case, you get (16t 100s 00:03:00):

Rendering.

This is good, but it seems that the shading model that's being looked for doesn't include that all-important cosine term. Well fine—the shading model isn't physically based anyway. Here's with ambient added directly (16t 100s 00:03:03):

Rendering.

. . . and with the ambient multiplied by the diffuse color (16t 100s 00:03:00) (yes, same timing as above):

Rendering.

This last one matches the reference image given.

Proceed to the Previous Project or Next Project.

Hardware

Except as mentioned, renders are done on my laptop, which has: