Don't feel bad if it doesn't make sense, the article gets quite a bit wrong. At each intersection, a ray tracer might spawn a refraction ray, a reflection ray,

Don't feel bad if it doesn't make sense, the article gets quite a bit wrong. At each intersection, a ray tracer might spawn a refraction ray, a reflection ray, and a shadow ray towards each of the lights. The reflection and refraction rays might spawn rays of their own, recursively. There are pathological cases where this gets out of hand, so most ray tracer have a maximum recursion depth or some threshold that if the ray doesn't contribute more than some threshold to the color of the pixel it just defaults to black (or whatever) and isn't computed. Most scenes aren't made entirely of shiny glass spheres, so this usually isn't a major problem. Path tracing is a little different, instead of evaluating a recursive tree of rays, you just do a lot of random sampling. Instead of evaluating both the reflection and refration ray, you flip a coin and evaluate one or the other. Or if the surface isn't perfectly smooth and glossy, you pick a random direction. Generally, path tracers have to trace a lot of rays per pixel to get anything other than a very noisy image. That can take a long time, so historically path tracing has been a lot slower than classical Whitted-style recursive ray tracing. In either case, path tracing or ray tracing, the traversal doesn't (usually) terminate in the ray colliding with a light source. Instead, at some hit location you do a direct illumination test which usually amounts to casting a shadow ray at all the light sources to see if that spot is directly illuminated, and then evaluating the texture and lighting at that point to produce a color, which propagates back up to the final result. > I don't understand this either. This just sounds like raytracing without reflections. Yep, that's raytracing without reflections, refractions, or shadows. Or basically anything that distinguishes it from plain polygon rasterization. Which is why ray tracers and path tracers do actually compute those secondary rays, they just have different strategies about which ones they evaluate. Plain Whitted ray tracing handles some additional optical effects that polygon rasterizers aren't good at (reflection, refraction, shadows), but it's not a complete solution. (Or we would say that it's not a full solution to the "rendering equation", because it omits some important terms.) Path tracing on the other hand is a complete, unbiased solution to the rendering equation. (Which is to say it renders a "correct image" according to a fairly realistic model of how light behaves, given infinite compute power, and if one's resources aren't infinite, at least it will give a statistically representative if perhaps noisy result.) The main thing path tracing handles that ray tracing doesn't is global illumination: basically, light that bounces off more than one surface between the light source and the camera. It can even correctly model semi-glossy surfaces. Global illumination can often make the difference between "this looks CG" and "this look like a photograph" (assuming there aren't any other major tells). https://en.wikipedia.org/wiki/Rendering_equation https://en.wikipedia.org/wiki/Rendering_equation