Veach thesis - formula question

[ingenious]

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.

[spectral]

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 !?

bdpt_pt.png

bdpt_lt.png

[spectral]

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

[ingenious]

We've discussed this singularity 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.

[Igors]

Maybe this link can be helpful

http://www.sjbrown.co.uk/2011/05/09/vir ... pensation/

[spectral]

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 :

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

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.
The corners are darker (like using simple clampling method, it is the discussed bias !) and still got some noise fireflies on the cubes bottom !

singularities.png

[Zelcious]

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.

[apaffy]

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.

[ingenious]

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.

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.

[spectral]

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

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);
}

MIS

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;