Let’s talk about the heart of any digital image: the pixel. And let’s talk about its finite nature. You see, in computer vision (and any digital display), each pixel is its own set of data (coordinates), and no information “fits” between them. You can make each pixel hold as much data as you like, but you can never make a “better” pixel.

Hear me out: all of computer vision is coordinate transforms with extra steps. The image format defines coordinate space, and the pixels are points located in this coordinate space. Here’s my case for why.

Ray tracing in game engines is the means by which graphics are rendered. At their core, a ray tracing algorithm is simply drawing a straight line between two objects in a scene, and then applying an interaction function. A ray tracing engine starts from some vantage point inside the scene, usually the player or a virtual camera, and sends a set of rays from this point into the scene. The rays intersect with an object inside the scene, and the ray is subsequently reflected back. In games, rays are almost always representing visible light and traced from the player into the scene and returned as an image. Hence, the name.

So, Part 1 introduced the most basic building blocks of a ray tracer, which were, more or less, a piece of code that draws a straight line between two objects and then does math on it until the object(s) more or less resemble a physical system. The question then is: how does the math know what math to math? Or, put differently, what are the properties of the object that determine how it appears in the final, rendered image?

Ok, Part 1 introduced the most basic building blocks of a ray tracer - drawing a line between two points and some clever math. Part 2 touched on that math - the properties of the object that determine how it appears. So for Part 3, we're going to look a little more about these properties. In Part 2, we looked at color; for Part 3, we're going to look at the rest of the basics.