<p>Generally speaking, <strong>path tracing</strong> removes a number of assumptions that ray tracing makes. Ray tracing usually assumes that there is no <strong>indirect lighting</strong> (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 <strong>non-glossy reflection</strong>, 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 <strong>area lights</strong>, 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 <em>amount</em> that the intersection point is shadowed.</p>

<p>And as soon as you need to break any of those assumptions with ray tracing, you now have a <strong>sampling problem</strong>: 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.</p>

CC BY-SA 3.0
2016-05-18T14:32:42.377Z
How do area lights create sampling bias?
Jake
CC BY-SA 3.0
2016-05-18T19:34:14.567Z
@Jake: In the same way as the rest: you have to cast more than one ray, so you need to decide what distribution to use.
John Calsbeek
CC BY-SA 3.0
2016-05-18T22:27:16.833Z
I suppose I thought area lights where directional so that light was only emitted along the normal of the light surface. Is that not how area lights work?
Jake
CC BY-SA 3.0
2016-05-18T23:24:53.520Z
@Jake No, area lights generally emit light into the entire hemisphere of directions at each point on their surface. You can see this if you imagine what a real-world area light looks like (such as a computer display showing solid white). You can see the emitted light from any direction.
Nathan Reed
CC BY-SA 3.0
2016-05-18T23:42:16.707Z
I'd add that [distribution ray tracing](https://en.wikipedia.org/wiki/Distributed_ray_tracing) is sort of a middle ground between recursive ray tracing and path tracing. It allows one to _somewhat_ have things like glossy reflection or depth of field in the recursive framework. The limitation is it's easy to run into problems with the branching factor: imagine if every ray that hits a surface spawns 10-100 secondary rays; the ray count would grow exponentially with each bounce! So path tracing is much more efficient if you want to do more than a very limited amount of stochastic phenomena.
Nathan Reed
CC BY-SA 3.0
2016-05-19T00:07:55.837Z
Yea the laptop example really clears things up. Of course it's hemispherical from each point now that you put it that way. Thanks so much!
Jake
CC BY-SA 3.0
2016-05-18T13:39:55.867Z
2016-05-18T13:39:55.867Z
John Calsbeek
<p>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.</p>

<p>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.</p>

<p>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.</p>

<p>What effects are captured by path tracing that are not captured by ray tracing</p>

<raytracing><pathtracing><monte-carlo>
What effects does path tracing capture that recursive ray tracing does not?
Jake
# What effects does path tracing capture that recursive ray tracing does not?

(Asked by: username_0 on 2016-05-17)

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

**Tags:** raytracing, pathtracing, monte-carlo


---

## 1 answers

### Answer by username_1 on 2016-05-18. Score: 11 | Accepted answer

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.

> **Comments:**
> **username_0**: How do area lights create sampling bias?  
> **username_1**: @username_0: In the same way as the rest: you have to cast more than one ray, so you need to decide what distribution to use.  
> **username_0**: I suppose I thought area lights where directional so that light was only emitted along the normal of the light surface. Is that not how area lights work?  
> **username_2**: @username_0 No, area lights generally emit light into the entire hemisphere of directions at each point on their surface. You can see this if you imagine what a real-world area light looks like (such as a computer display showing solid white). You can see the emitted light from any direction.  
> **username_2**: I'd add that [distribution ray tracing](https://en.wikipedia.org/wiki/Distributed_ray_tracing) is sort of a middle ground between recursive ray tracing and path tracing. It allows one to _somewhat_ have things like glossy reflection or depth of field in the recursive framework. The limitation is it's easy to run into problems with the branching factor: imagine if every ray that hits a surface spawns 10-100 secondary rays; the ray count would grow exponentially with each bounce! So path tracing is much more efficient if you want to do more than a very limited amount of stochastic phenomena.  
> **username_0**: Yea the laptop example really clears things up. Of course it's hemispherical from each point now that you put it that way. Thanks so much!  

---

