What effects does path tracing capture that recursive ray tracing does not?

Question

So I have been wanting to make a rendering engine as a summer project. I'd like to shoot for photo-realism of static scenes rather than real time dynamic game like graphics. So in my research I came across two major techniques for going about this. One is to attempt to directly solve the rendering equation with specialized numeric methods like bidirectional path tracing. Another is the well known ray tracing technique. Ray tracing is a) much simpler and b) more efficient. Additionally it seems as though some kind of interpolation/de-noising is needed to make the images look properly smooth when path tracing techniques are used.

I understand recursive ray tracing to be an algorithm in which rays are shot out from the eye and collide with objects in the space. When they do more rays are shot from that point to calculate the lighting at that point.

I understand path tracing to be trying to find paths to the viewing plane from light sources. If enough of these paths are sampled without bias then you can use these paths to perform monte carlo integration over the space using the found paths as your sample points.

What effects are captured by path tracing that are not captured by ray tracing

Answer 1

Generally speaking, path tracing removes a number of assumptions that ray tracing makes. Ray tracing usually assumes that there is no indirect lighting (or that indirect lighting can be approximated by a constant function), because handling indirect lighting would require casting many additional rays whenever you shade an intersection point. Ray tracing usually assumes that there is no such thing as non-glossy reflection, because while it is fairly easy to handle glossy/mirror reflection (you reflect the ray and continue with the raycast), if you have non-glossy specular reflection you have a problem very much like indirect lighting: you need to trace a bunch more rays and then do lighting wherever those rays hit. Ray tracing also usually assumes that there are no area lights, because it is very cheap to cast a single ray towards a light to determine if an intersection point is in shadow, but if you have an area light you generally need to cast multiple rays towards different points on that light to determine the amount that the intersection point is shadowed.

And as soon as you need to break any of those assumptions with ray tracing, you now have a sampling problem: you need to decide how to distribute the many additional rays you need to trace in order to get an accurate result that doesn't have noticeable aliasing.