<p><strong>Q1</strong>: how to represent path tracing as the first one...</p>
<p>Your materials have brought enough information, the first formula, quoted from your material, presents as</p>
<blockquote>
<p>The path integral formulation of light transport formalizes the idea
by writing the camera response as an integral over all light transport
paths of all lengths in the scene, which given path encompasses</p>
<ol>
<li>the “amount” of light emitted along the path,</li>
<li>the light carrying capacity of the path, and</li>
<li>the sensitivity of the sensor to light brought along the path.</li>
</ol>
</blockquote>
<p>Can't interpret the formula better</p>
<p><strong>Q2</strong>: Should I generate paths for different lengths and do this procedure over and over...</p>
<p><strong>Q3</strong>: ...randomly generate paths with different lengths and sum their estimate up since each length...</p>
<p>Quoted from your material,</p>
<blockquote>
<p>The Monte Carlo integration procedure consists in generating a
‘sample’, that is, a random x-value from the integration domain, ...</p>
</blockquote>
<p>I can't say the second one is a formula, it is just the Monte Carlo estimator of the path integral formulation of light transport or it is just a method for programming the formulation; or course you could have other methods.</p>

CC BY-SA 4.0
2020-09-14T01:24:16.343Z
Thanks for your answer! I think Q1 is clear to me. But for Q2 and Q3, what I mean is: if we can estimate the path integral by generating a single path, why mainstream renderers(mitsuba and pbrt) uses the increasing path construction scheme and accumulate the contribution of different paths?
TH3CHARLie
CC BY-SA 4.0
2020-09-14T03:13:54.537Z
If you use Russian roulette while constructing a path, that's a probability distribution over path lengths; you could as well choose the length randomly in advance, and construct the path to that length. Accumulating direct lighting samples along a path as it's constructed is a convenient/cheap kind of reuse, which I suppose results in correlated samples in path space (not totally independent of each other) but it's still unbiased and correct as long as you get the pdfs right.
Nathan Reed
CC BY-SA 4.0
2020-09-15T02:22:18.253Z
@NathanReed Thanks for the comment. I did some further research, reading and implementation. From the BDPT's paper and PBRT's BDPT implementation, I think I now understand that it is mathematically correct to use the path integral form to estimate the final integral. However, if I understand correctly, randomly generating the path to a specific length can only account for a specific set of scene parameters and for parameters that cannot the paths will have low contribution. That's probably why we construct incremental length so we can account for more scenarios.
TH3CHARLie
CC BY-SA 4.0
2020-09-21T13:42:42.840Z
@NathanReed I have a followup question regarding this topic.  Are each connection strategy in BDPT without the MIS weighing, for example: (t=1, s=2) and (t=2, s=1) and etc, an unbiased estimate of the final integral?
TH3CHARLie
CC BY-SA 4.0
2020-09-14T01:13:04.747Z
2020-09-14T01:13:04.747Z
xer-rex
<p>The description is going to be long and detailed, thanks in advance for your patience!</p>
<p>I am learning the path integral form of light transport equation(LTE) to be able to follow recent rendering papers. The materials I am using are PBRT(chapter 14.4-14.5: <a href="http://www.pbr-book.org/3ed-2018/Light_Transport_I_Surface_Reflection/The_Light_Transport_Equation.html" rel="nofollow noreferrer">link</a>) and SIGGRAPH 2013 course: <a href="https://cgg.mff.cuni.cz/%7Ejaroslav/papers/2013-ltscourse/02%20-%20ltscourse%20-%20path%20integral%20-%20krivanek%20-%20notes.pdf" rel="nofollow noreferrer">link</a>.</p>
<p>The path integral form of LTE is:</p>
<p><span class="math-container">$$ I(x) = \int_{\Omega}f(\overline{x})d\mu(\overline{x})$$</span></p>
<p>From the SIGGRAPH course's slide, we know that we can estimate <span class="math-container">$I$</span> by randomly sampling a path, computing its contribution <span class="math-container">$f$</span>, and dividing by its probability <span class="math-container">$p$</span>:</p>
<p><span class="math-container">$$ \overline{I}(x) = \frac{f(\overline{x})}{p(\overline{x})} $$</span></p>
<p>From the PBRT's notes and its implementation, it expands the path integral into an infinite sum of integrals on specific lengths of paths. This notation is well shown in the path tracing implementation since the i-th bounce computes the i-th integral and simply summing them up will the final estimate of <span class="math-container">$I$</span>.</p>
<p><span class="math-container">$$ \overline{I}(x) = \sum_{i=0}^{\infty}\overline{I_{i}}(x) $$</span></p>
<p>With these two notations based on the path form integral of LTE, my question is how to represent path tracing as the first one(the SIGGRAPH course notation) since most PT implementations I've seen so far is based either on the PBRT's notation(the sum notation) or other notations of LTE.</p>
<p>I have one possible idea that is to follow the formula by generating a path and computing its pdf, but I am not sure about its practical implementation. Should I generate paths for different lengths and do this procedure over and over(since this looks more like the PBRT's notation), or a single path with the correct pdf will suffice?</p>
<p>Or, from another perspective, I think that to apply the SIGGRAPH course's notation in practice, one has to randomly generate paths with different lengths and sum their estimate up since each length corresponds to one term in the expanded notation. Is this correct?</p>

<pathtracing><sampling>
Path Integral Form with Path Tracing
TH3CHARLie
# Path Integral Form with Path Tracing

(Asked by: username_0 on 2020-09-13)

The description is going to be long and detailed, thanks in advance for your patience!

I am learning the path integral form of light transport equation(LTE) to be able to follow recent rendering papers. The materials I am using are PBRT(chapter 14.4-14.5: [link](http://www.pbr-book.org/3ed-2018/Light_Transport_I_Surface_Reflection/The_Light_Transport_Equation.html)) and SIGGRAPH 2013 course: [link](https://cgg.mff.cuni.cz/%7Ejaroslav/papers/2013-ltscourse/02%20-%20ltscourse%20-%20path%20integral%20-%20krivanek%20-%20notes.pdf).

The path integral form of LTE is:

$$ I(x) = \int\_{\Omega}f(\overline{x})d\mu(\overline{x})$$

From the SIGGRAPH course's slide, we know that we can estimate $I$ by randomly sampling a path, computing its contribution $f$, and dividing by its probability $p$:

$$ \overline{I}(x) = \frac{f(\overline{x})}{p(\overline{x})} $$

From the PBRT's notes and its implementation, it expands the path integral into an infinite sum of integrals on specific lengths of paths. This notation is well shown in the path tracing implementation since the i-th bounce computes the i-th integral and simply summing them up will the final estimate of $I$.

$$ \overline{I}(x) = \sum\_{i=0}^{\infty}\overline{I\_{i}}(x) $$

With these two notations based on the path form integral of LTE, my question is how to represent path tracing as the first one(the SIGGRAPH course notation) since most PT implementations I've seen so far is based either on the PBRT's notation(the sum notation) or other notations of LTE.

I have one possible idea that is to follow the formula by generating a path and computing its pdf, but I am not sure about its practical implementation. Should I generate paths for different lengths and do this procedure over and over(since this looks more like the PBRT's notation), or a single path with the correct pdf will suffice?

Or, from another perspective, I think that to apply the SIGGRAPH course's notation in practice, one has to randomly generate paths with different lengths and sum their estimate up since each length corresponds to one term in the expanded notation. Is this correct?

**Tags:** pathtracing, sampling


---

## 1 answers

### Answer by username_1 on 2020-09-14. Score: 1 | Accepted answer

**Q1**: how to represent path tracing as the first one...

Your materials have brought enough information, the first formula, quoted from your material, presents as

> The path integral formulation of light transport formalizes the idea
> by writing the camera response as an integral over all light transport
> paths of all lengths in the scene, which given path encompasses
>
> 1. the “amount” of light emitted along the path,
> 2. the light carrying capacity of the path, and
> 3. the sensitivity of the sensor to light brought along the path.

Can't interpret the formula better

**Q2**: Should I generate paths for different lengths and do this procedure over and over...

**Q3**: ...randomly generate paths with different lengths and sum their estimate up since each length...

Quoted from your material,

> The Monte Carlo integration procedure consists in generating a
> ‘sample’, that is, a random x-value from the integration domain, ...

I can't say the second one is a formula, it is just the Monte Carlo estimator of the path integral formulation of light transport or it is just a method for programming the formulation; or course you could have other methods.

> **Comments:**
> **username_0**: Thanks for your answer! I think Q1 is clear to me. But for Q2 and Q3, what I mean is: if we can estimate the path integral by generating a single path, why mainstream renderers(mitsuba and pbrt) uses the increasing path construction scheme and accumulate the contribution of different paths?  
> **username_2**: If you use Russian roulette while constructing a path, that's a probability distribution over path lengths; you could as well choose the length randomly in advance, and construct the path to that length. Accumulating direct lighting samples along a path as it's constructed is a convenient/cheap kind of reuse, which I suppose results in correlated samples in path space (not totally independent of each other) but it's still unbiased and correct as long as you get the pdfs right.  
> **username_0**: @username_2 Thanks for the comment. I did some further research, reading and implementation. From the BDPT's paper and PBRT's BDPT implementation, I think I now understand that it is mathematically correct to use the path integral form to estimate the final integral. However, if I understand correctly, randomly generating the path to a specific length can only account for a specific set of scene parameters and for parameters that cannot the paths will have low contribution. That's probably why we construct incremental length so we can account for more scenarios.  
> **username_0**: @username_2 I have a followup question regarding this topic.  Are each connection strategy in BDPT without the MIS weighing, for example: (t=1, s=2) and (t=2, s=1) and etc, an unbiased estimate of the final integral?  

---

