Ray Tracing in One Weekend, but Actually in One Year

Here is my finished ray tracer, based on Peter Shirley’s Ray Tracing in One Weekend. Despite the title, this one took me a little longer than a weekend.

I started it over a year ago and chipped away at it in bursts, with a few long breaks in between. One of those breaks ended up being useful. It gave me a reason to revisit some of the math concepts involved. None of the math in this project is especially intimidating, but I wanted more than a surface-level sense of why things worked.

It was not always the most fun project I have worked on, but it was definitely one of the most satisfying to finally finish. You can see the code on GitHub.

What Is Ray Tracing?

Ray tracing is a rendering technique that creates an image by simulating rays of light.

For each pixel, a ray is sent from a virtual camera into a scene. The renderer checks whether that ray hits anything, where it hits, and how the material at that point changes the ray. Depending on the surface, the ray might bounce, scatter, reflect, or get absorbed.

Repeat that process across every pixel, and after enough samples, an image starts to emerge. At first it looks rough and noisy, but once the pieces come together, you get shadows, reflections, depth, and lighting that feel much more natural than a simple flat render.

My version started out about as simple as possible:

Just a sphere, a background, and the basic logic needed to prove that rays were hitting something at all.

Then it became a little more interesting:

At that point, it was starting to behave more like an actual renderer.

After about 30 minutes of rendering, this was the final result:

It took much longer than a weekend, but I am glad I came back to it and finished it. I also came away with a better understanding of what the renderer was actually doing, which made the extra time feel worthwhile.