## Veach thesis - formula question

### Re: Veach thesis - formula question

The thing with the camera is the following. In BDPT you need to compute the area pdf of the first point hit from the camera, let's call this point 'x'. How do you normally compute the area pdf of a point? Convert the solid angle ray pdf to area measure, as desperately discussed above So, you need the solid angle pdf of the camera ray, which you then convert to area measure once you trace it and hit 'x'.

Now how you do compute the solid angle pdf of the camera ray? You might think it's something uniform, but it's not. The reason is that a camera ray is usually generated by uniformly sampling the pixel area on the image plane. A uniform image plane area density results in a non-uniform solid angle density for the ray direction. The solid angle pdf can be computed by multiplying the uniform image plane area pdf (which is simply 1/image_size) by the inverse of the factor you use for the conversion above, i.e. 'dist^2 / cos(theta)', where 'dist' is the distance from the pinhole to the image plane point, and 'theta' is the angle between the ray direction and the camera viewing direction. This is all very simple to derive geometrically on a piece of paper, and I'm puzzled by the obscure explanations of the camera model in BDPT in all related documents I've seen. It's just converting measures area -> solid angle -> area. So in summary, the camera cosine appears in the pdf of the first point seen from the camera.

Now how you do compute the solid angle pdf of the camera ray? You might think it's something uniform, but it's not. The reason is that a camera ray is usually generated by uniformly sampling the pixel area on the image plane. A uniform image plane area density results in a non-uniform solid angle density for the ray direction. The solid angle pdf can be computed by multiplying the uniform image plane area pdf (which is simply 1/image_size) by the inverse of the factor you use for the conversion above, i.e. 'dist^2 / cos(theta)', where 'dist' is the distance from the pinhole to the image plane point, and 'theta' is the angle between the ray direction and the camera viewing direction. This is all very simple to derive geometrically on a piece of paper, and I'm puzzled by the obscure explanations of the camera model in BDPT in all related documents I've seen. It's just converting measures area -> solid angle -> area. So in summary, the camera cosine appears in the pdf of the first point seen from the camera.

**Click here.**You'll thank me later.

### Re: Veach thesis - formula question

Interesting... I will give a try too ! Thanks for clarrifications...

Finally I'm back to my code and I got better results... but, with light tracing I got some strange fireflies...

it is a problem I have already see (see "Light Rays Only"):

http://wwwx.cs.unc.edu/~sjguy/ImgSynth/ass3/main.html

http://graphics.ucsd.edu/~iman/BDPT/

I was expecting to have the exact same image for both PT and LT, my pdf are 1/Pi so there is no division by 0 !

If you have an idea ? maybe it is common or not !?

Finally I'm back to my code and I got better results... but, with light tracing I got some strange fireflies...

it is a problem I have already see (see "Light Rays Only"):

http://wwwx.cs.unc.edu/~sjguy/ImgSynth/ass3/main.html

http://graphics.ucsd.edu/~iman/BDPT/

I was expecting to have the exact same image for both PT and LT, my pdf are 1/Pi so there is no division by 0 !

If you have an idea ? maybe it is common or not !?

**Spectral**

**OMPF 2 global moderator**

### Re: Veach thesis - formula question

It seems to be a problem with the geometric term, when ||x-x'||² is small ?!

To remove my fireflies, I cancel any sample when this value < 10 ! It is not really a good way to fix it.

Do you have another suggestion ?

Thanks

To remove my fireflies, I cancel any sample when this value < 10 ! It is not really a good way to fix it.

Do you have another suggestion ?

Thanks

**Spectral**

**OMPF 2 global moderator**

### Re: Veach thesis - formula question

We've discussed this singularity

The two pages you've linked to both seem to have buggy BDPT implementations.

*many*times already. This is normal. Full bidirectional path tracing with multiple importance sampling avoids the issue.The two pages you've linked to both seem to have buggy BDPT implementations.

**Click here.**You'll thank me later.

### Re: Veach thesis - formula question

Thanks for the link,

I have to try MIS now, but because I'm on the GPU I have to take an approach, up now I have read the Dietger (recursive MIS...) paper and will give a try.

But before it is still interesting to try the method proposed on the Simon blog. What I understand is the following :

The corners are darker (like using simple clampling method, it is the discussed bias !) and still got some noise fireflies on the cubes bottom !

I have to try MIS now, but because I'm on the GPU I have to take an approach, up now I have read the Dietger (recursive MIS...) paper and will give a try.

But before it is still interesting to try the method proposed on the Simon blog. What I understand is the following :

For now I play with a fixed 'b=0.1' and 'b=(1/|A|)/f )' , I have less fireflies but still get some differences compared to the path traced image.1) I compute K = max( (G-b)/G , 0)

2) if K != 0 I bypass the connection (don't account the current vertices) and (a) continue the eye path and (b) multiply the eye-throughput by k

The corners are darker (like using simple clampling method, it is the discussed bias !) and still got some noise fireflies on the cubes bottom !

**Spectral**

**OMPF 2 global moderator**

### Re: Veach thesis - formula question

You are missing a point. Don't bypass connection when k!= 0, clamp it (with the same b of course). That is reason for your incorrect result.

### Re: Veach thesis - formula question

If you read the Kollig and Keller paper, you'll see how this recursive bias compensation technique can be reformulated as a weighting scheme for multiple importance sampling in a bidirectional path tracer.

Maybe not directly helpful for you, but I found this to be really insightful.

Maybe not directly helpful for you, but I found this to be really insightful.

### Re: Veach thesis - formula question

Indeed, and people seem to often overlook this part of the paper, which is the most insightful one, as it puts everything to place Though the only advantage I see to it is the easier implementation than Veach's heuristics. It can be a good reason to justify implementation, but in general it's suboptimal to the power heuristic.apaffy wrote:If you read the Kollig and Keller paper, you'll see how this recursive bias compensation technique can be reformulated as a weighting scheme for multiple importance sampling in a bidirectional path tracer.

Maybe not directly helpful for you, but I found this to be really insightful.

**Click here.**You'll thank me later.

### Re: Veach thesis - formula question

Thanks a lot,

I have try to add both (MIS + bias compensation) but still got a strange noise on the box !

The pseudo-code looks like this ( easier to write than equation in the forum for now )

Bias compensation
MIS

I use several parallel bdpt paths, so for now I just try to MIS between threads (if they have the same path length):

I have try to add both (MIS + bias compensation) but still got a strange noise on the box !

The pseudo-code looks like this ( easier to write than equation in the forum for now )

Bias compensation

Code: Select all

```
float b = lightArea/ bsdf(x);
float k = max(G-b)/G, 0);
if (k != 0)
{
lightPath_throughput *= k;
return min(b, G);
}
```

I use several parallel bdpt paths, so for now I just try to MIS between threads (if they have the same path length):

Code: Select all

```
foat sumPdf = 0;
color r = 0;
for(int i = 0; i < THREADS; i++)
{
pdf = lightPath[i].path_pdf * cameraPath.path_pdf;
sumPdf += pdf;
r += r * pdf;
}
r /= sumPdf;
```

**Spectral**

**OMPF 2 global moderator**