Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Tedious bugs in my bidirectional path tracer.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
7 replies to this topic

#1 shiqiu1105   Members   -  Reputation: 111

Like
0Likes
Like

Posted 05 July 2012 - 02:31 AM

Hi guys,

I have been trying to create my bidirectional path tracer for a long while.
But there were always bugs which I was having a hard time debugging!

The result image is down below.
My bidir path tracer generates noiser images than my path tracer when the same amount of samples are used :(

Bidir:
Posted Image
Normal path tracer:
Posted Image

Notice that not only is the bidir version noiser, they seem to converge to different colors too. Any idea how to debug?

Bidir path tracer is particularly noisy in the edges, as you can see.
Or can I put up the source code so that you guys can help?

Sponsor:

#2 jameszhao00   Members   -  Reputation: 271

Like
0Likes
Like

Posted 05 July 2012 - 07:52 AM

Uniformly sampled bidirectional tracer is noisier in mostly directly light situations.

On debugging: You're on the right track with the reference image comparison. Get ready for a boatload of pain though.

I really suggest you download the Intel compiler trial. It saves a lot of debugging time (as the generated code pretty much beats VC++ by 10-20% usually)

For BDPT, the weights for path configurations of a given path length must sum to 1. So, we can have any weights we want, as long as it sums to 1. Some things I would try

- render with path length = 3 only, compare uniform bdpt with reference
- render with path length = 3 only, render with 4 eye verts, 0 light verts weighted to 1,
- render with path length = 3 only, render with 3 eye verts, 1 light verts weighted to 1,

Also, I've found it extremely helpful to posterize the images in a photo editor (I use Paint.Net) and compare. It lets me see the lighting gradients very well.

Also, having a crapload of asserts is extremely helpful (check your understanding, detect undesirable nan/infs)

Also, I have some stuff in my blog when I implemented BDPT. (I have not yet written about MIS BDPT)

Here's my reference uniform BDPT code by the way
https://github.com/j...ghtway/bdpt.cpp

MIS BDPT (Does not handle specular / escaped ray)
https://github.com/j...way/bdptMIS.cpp

My implementation requires at least 2 eye vertices (so weights change slightly)

Edited by jameszhao00, 05 July 2012 - 08:00 AM.


#3 ProfL   Members   -  Reputation: 575

Like
1Likes
Like

Posted 05 July 2012 - 05:03 PM

I have to disagree, bi-directional path tracer should have a faster convergence, if you have smaller lightsources. They are kind of bad for light domes (IBL).
I mean, the noise is mostly visible in the in-directional areas, it shouldn't be like that. You might end up with some fire flies if you add specular surfaces, tho.

I'm not sure what your error is, but if both images converge to different result, it's clearly wrong. My wild guess would be that something is wrong with your probability calculations. check out:
http://graphics.stanford.edu/courses/cs348b-03/papers/veach-chapter10.pdf
and additionally
http://www.sjbrown.co.uk/2011/01/03/two-way-path-tracing/

#4 jameszhao00   Members   -  Reputation: 271

Like
0Likes
Like

Posted 05 July 2012 - 06:24 PM

His implementation looks like uniform weighting (might be wrong). With standard path tracing, you have eye*-shadow-light connections, whereas in uniform BDPT you have a portion of paths requiring random hits vs the light (and higher variance). Thus, for mostly direct lighting (where eye*-shadow-light should be weighted more) uniform BDPT's increase variance should be very visible in a comparison with regular path tracing.

if you have smaller lightsources



Are you by any chance referring to MIS path tracing? where we combine brdf sampling (good for specularish surfaces) and explicit light sampling (good for small lights)?



#5 shiqiu1105   Members   -  Reputation: 111

Like
1Likes
Like

Posted 05 July 2012 - 07:51 PM

I have tried both the uniform and MIS approach. But I am not sure I calculated the path weights correctly, so I will take a look at your implementation, thanks a lot!!

I think they should converge to the same result, even with the uniform approach(it just takes a lot more samples). So color differences and noise clearly indicate there are errors.

This bug have been there for nearly 8 months, OMG..

#6 jameszhao00   Members   -  Reputation: 271

Like
0Likes
Like

Posted 05 July 2012 - 10:56 PM

MIS BDPT weights isn't easy to get right. Understanding the bdpt implementation section in the Veach thesis and fully grasp the P(i+1)/P(i) notation (i.e. what is i? What is a path with 0 light vertex? etc) is very important.

Also, you can try summing weights of a path length and see if it gives you 1 for fully expressable paths (e.g. eye/light paths are not too short for open cornell boxes)

Also, for MIS BDPT if you're using an open cornell box it will look different unless you somehow correctly account for escaped rays.

Edited by jameszhao00, 06 July 2012 - 12:22 AM.


#7 xieofxie   Members   -  Reputation: 110

Like
0Likes
Like

Posted 06 July 2012 - 07:15 AM

i am a beginner in making a bidirectional path tracer and i encounter with the same problem.
i think it is the result of geometry coupling term G or a bad weight function.
but i don't know how to solve it.
can anyone help?

Edited by xieofxie, 06 July 2012 - 07:17 AM.


#8 shiqiu1105   Members   -  Reputation: 111

Like
0Likes
Like

Posted 10 July 2012 - 07:29 AM

Uniformly sampled bidirectional tracer is noisier in mostly directly light situations.

On debugging: You're on the right track with the reference image comparison. Get ready for a boatload of pain though.

I really suggest you download the Intel compiler trial. It saves a lot of debugging time (as the generated code pretty much beats VC++ by 10-20% usually)

For BDPT, the weights for path configurations of a given path length must sum to 1. So, we can have any weights we want, as long as it sums to 1. Some things I would try

- render with path length = 3 only, compare uniform bdpt with reference
- render with path length = 3 only, render with 4 eye verts, 0 light verts weighted to 1,
- render with path length = 3 only, render with 3 eye verts, 1 light verts weighted to 1,

Also, I've found it extremely helpful to posterize the images in a photo editor (I use Paint.Net) and compare. It lets me see the lighting gradients very well.

Also, having a crapload of asserts is extremely helpful (check your understanding, detect undesirable nan/infs)

Also, I have some stuff in my blog when I implemented BDPT. (I have not yet written about MIS BDPT)

Here's my reference uniform BDPT code by the way
https://github.com/j...ghtway/bdpt.cpp

MIS BDPT (Does not handle specular / escaped ray)
https://github.com/j...way/bdptMIS.cpp

My implementation requires at least 2 eye vertices (so weights change slightly)


Hi I want to ask you something.

How do I weight the first eye vertex if I am using the pinhole camera (no intersectable area in the lens)?

Veach's thesis suggests we should set it to 1 / area, but in this case, we don't have area.
Should I just set the probability of the first node to 1.0?




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS