Ray Tracing Essentials, Part 1: Basics of Ray Tracing

I had a really fun time going through the ray tracer challenge recently! It really is an amazing introduction to ray tracing

I've since moved on to the pbr book[0] and finding myself getting much more lost in the math. I'm doing my best to brush up and/or learn all of it, but it's a bit daunting.

It's really telling how reassuring the tests are in the RTC. Right now I can re-implement something from the pbr-book, but I can't really say if I got it right other than by doing a render (and even then, it can be hard to tell).

My plan is to at least go through and write my own tests by doing the math by hand and trying to verify my implementations.

I really wish there were some intermediary book between the two.

[0] http://www.pbr-book.org/

+1 to Ray Tracer Challenge.

I really think the key thing for it clicking with me was to build up the math foundation via TDD. Sure I could have used C#'s Matrix4x4 and Vector classes and just browsed through the beginning of the book, but actually implementing my own tuples, vectors, points, and matrixes really helped me understand "here's what I'm trying to achieve" then "here's the math to implement it".

It is a great project for learning a new language. I used it to practice Rust.

You get to implement vectors, with basic operations on them, this gives you a chance to practice some abstractions. It's also good to create some unit tests to ensure your vector operations are correct. There's also good reason to parallelize your code and perform benchmarks. Abstractions, unit tests, parallelism, benchmarks, you have an excuse to try them all.

Less well known is "Rasterization in One Weekend"

https://tayfunkayhan.wordpress.com/2018/11/24/rasterization-...

I was reading through and noticed he does not normalize his vectors for (so far) things like ray direction or surface normals for lighting. He does give warnings but I'm curious what type of bugs or rendering issues will manifest from this decision?

While sub-pixel sampling provides little benefit for diffuse surfaces, sampling the same pixel multiple times does provide better smoothness across the surface of the object.

Since it's not much more computationally expensive to do sub-pixel sampling than to repeatedly sample the same point within the pixel you might as well just use sub-pixel sampling.

Additionally a pixel has no knowledge of its contents until you cast a ray. And even if the ray did hit a diffuse surface you would have to do more math to determine if the edge of that surface lies within the boundaries of that pixel. Might as well just use sub-pixel sampling.

When you shoot a ray from camera perspective, you've already chosen which pixel it's going to contribute to. "Platonic" pixels are infinitesimally small.

In reality, pixels on the screen and camera sensor have an area. If you choose a random position on that area, you get anti-aliasing "for free" because there's going to be variation in the direction of rays that contribute to the same pixel.

Consider a scenario where almost half of a pixel (but not the center of it) is covered by some diagonal black object that's in front of a white object.

If you ray trace and shoot one ray in the center of the pixel then it will hit the white object, and no matter how many rays you spawn from that intersection point the part of the black object that's covering part of the pixel won't actually contribute to the final image. So with this technique the final pixel will be white.

With path tracing you shoot many initial rays at random sub-pixel positions, most miss the black object and hit the white one, but some hit the black one instead. So with this technique the final pixel will be gray, a mixture of the two objects' colors and therefore anti-aliased.

There's a point in space that represents the lens of the observer's eye, and a rectangle in space that represents the viewport. This rectangle is divided into pixel-equivalent square areas. For each area, a sampling of one or more rays is drawn from the lens point through the bounds of the area, until it encounters a surface of the scene. At that point, the material rules of the surface might generate another ray for specular reflection, a cone for diffuse reflection, another ray for refraction, and also add the emissive light value from that material. If the specular or diffuse reflections encounter a light source or ambient light, they add some of that light to the pixel-equivalent.

The diffuse cones send out a sampling of rays and attenuate the light from the light source, based on how many of those rays hit it, instead of some other object.

Instead of drawing light onto the scene and calculating how much passes through the viewport to the lens, ray-tracing cheats by working backwards, because photons traveling backward in time follow exactly the same rules as those traveling forward in time. Every photon that can travel backwards in time from the eye to hit a light source must have emanated from a light source with exactly the right direction and polarization to enter the eye. So the only photons calculated are the ones that contribute to the scene as viewed by the eye.

Something like Ray Tracing Gems book they published last year? Or maybe CFP for Ray Tracing Gems II book they have right now?

Workin' on it. :-)

Note that the third edition came out roughly 5 years ago now, not 10.