Weighted Path tracing idea. Would it help?

Hi all, especially you, DingTo :wink:
i am working on a photorealistic animation project and I’m using back and forth path tracing (from now on: PT) and branched path tracing (BPT). I have node-filled materials everywhere, PBR-ish hard surfaces, complex water shader etc…, illumination is done by a sun and a hdr sky.
Using BPT is really slow. Often PT gives me better noise/time results despite what everyone says about BPT, despite solid angle manual, and despite logic! So i came with this idea: taking the benefits of both modes, and have an hybrid approach. I’ll go to explain.

Reading here and there this is what I understood: BPT, for each AA sample, splits the calculation in the 7 shading components (diffuse glossy transmission AO meshlights sss and volume) and evaluates from there according to each component multiplier. Useful to decide how much love to give each one.
Downside, AA samples can take veeery long time to be done.
On the other hand PT is very fast since it doesn’t split rays but instead, randomly chooses which shading component will be evaluated every time.
Downside, you can’t assign more samples to any shading component because, statistically, they all get the same attention.

So here is the idea: bring components in PT and give them a “weight”, which will determine the probability that each have to be randomly choosen in the place of the others.

example: 700 PT samples

now=> each component has a weight of 1 (same probability).
result=> approx 100 samples each

hybrid=> d4 g3 t2 A0* m1 s1 v1 (* yes 0, why not?)
result=> approx d233 g175 t116 A0 m58 s58 v58

4+3+2+0+1+1+1 = 12
So, the random pick, intead of being done between 1-7 will be done between 1-12

700/12 = 58.333
58d = 233 samples
58
g = 175 samples
and so on…

in case you have no SSS or volume or AO (as i do) you can set all these to 0 gaining samples for the others

at the end of the job you obtain the speed of PT plus the ability to “probabilistically-drive” more samples on the components that need them more, as in BPT. I’d call this Weighted Path Tracing (WPT).

what you guys think?

I’ve sadly made the exact same experience!

Generally this should indeed work and might be worth a try.
However, you have one misconception in your calculation: PT samples only components that are present in your shader. So, if you use no SSS, for example, you don’t waste 100 samples for nothing - If you only mix Diffuse and Glossy, both will get 350 samples (to be precise, they are weighted based on their relative brightness, so this is only true when they are both white and mixed half-half).

The situations that Branched path tracing really performs well in are scenes with lots of lamps and not so much meshlights or environment lighting.

try an interior scene with lots of lights and switch back and forth between BPT and PT, you should see a noticable improvement in the time it takes to clear up the lighting (at least the first bounce, multibounce lighting seems to resolve about as quickly with either integrator)

The opposite is true with hdr light probe lighting, in my experience. it takes longer to resolve the first bounce of light with BPT.

But I haven’t quite figured out all of the intricacies, so experiment on your own to find what works best for your scene.

that’s the point!
In my mind a weighted PT approach would solve this tryout issue, giving the best of the two worlds

A sort-of related weighting thing. Currently BPT samples both BSDFs on mix shaders, while PT blindly picks a random one. Why not do a random pick that is weighted by the mix factor? I believe that’s what this shader is describing here? http://therenderblog.com/russian-roulette-sampling/

Btw, for BPT and HDRI lights, don’t forget the default “world samples” value is 4, not 1. This can be overkill on some HDRIs. If you’re getting a clean but slow render, you can try backing this value off a bit.

Um, that’s exactly what Cycles already does (see intern/cycles/kernel/kernel_shader.h:533 and below) - the idea in this thread is to add a closure-type-dependent factor that allows to sample e.g. diffuse more (because you might know that most of the noise comes from the diffuse bounces)

Well, I feel silly now. :frowning:

I feel silly too! :slight_smile:

But here I feel smart! :cool:

Hi Lukas, thank you, it’s good to know better how the integrator works. One question: what happens to secondary bounces? I mean, if a ray bounces on a only-glossy-shader material and reaches another object that has a multishader material, how is the random choose weighted? or more generally, what component is evaluated for that sample?

Wait a minute, is this why BPT is so slow with complex shaders? Say I have a material with 12 different BSDF’s and a bunch of mix shaders, no wonder it is so slow then when it’s sampling that much information at once (going well beyond the point where it would’ve allowed better quality in less time).

Could there be a possibility then of maybe have it do this weighted path tracing with the benefits of defining different sample counts per ray-type?

That is exactly the case.

the more i understand this, the more i see BPT shaped for “just-charachter-to-be-composed-later” scenario

Not necessarily. BPT works really well with lamps. See the below image:

Left is path tracing, right is branched path tracing, both were rendered for the same amount of time (~3 sec).

The first bounce lighting resolves almost instantly with BPT. The second bounce is still plenty noisy, but getting a grip on the lighting is a lot easier when the main contributions clarify quickly. For quick and dirty zero bounce lighting, it allows almost real time rendering, in a fairly complex scene with moderate hardware.

Again, this works best with lamps illuminating the scene. Meshlights are pretty slow still.

It’s complicated choosing which integrator will work best, but they both have their uses.

About 90% of the time BPT doesnt only give me less noise but it also give me less noise in less time. (I am a filthy GPU user)

Strange … we’re rendering different kind of scenes then.
I’m still not sure why for some users BPT works great and for others it’s not.
But I guess I have a tendency for using HDRI and using as few lamps as possible … maybe that’s why ^^

If my memory didn’t fail me i remember Brecht saying something like BPT isn’t really optimized yet – can anyone confirm?

I have reason to believe that BPT can give you less noise in less time providing you use simpler materials and a very limited number of bounces (as in just one or two diffuse bounces at max as per the specifications for Tears of Steel).

Path Tracing is still a prerequisite for many people because realistic materials may need a lot of different shader nodes for different components and realistic scenes require many bounces of light.

Excuse me a bit offtopic, but since you are talking about BPT :slight_smile:

When I use BPT with GPU the graphics part in the system hangs/slows much more than using PT. You can not go to blender and cancel the render, sometimes it is necessary to force reset the system. Also sometimes I had some CUDA errors and crashes using GPU and BPT. In short, BPT and GPU on my system is unusable most of the time. Is it normal that these things happen?
I think I remember reading that this often happens in some operating systems when you use the same GPU to render and display (I am using Linux 64 bits).

Did you set the registry key for TDR timeout high enough? check for example http://artificialflight.org/blog/2013/cycles-crash-cuda-tdr-error/ but think there was a link in the wiki as well.

@tobbew, hi.
I use Linux, I’m not sure if this problem also exists in Linux.
I’ve had the CUDA error a few times and I can not remember exactly when or how the error happens. But the high usage of resources by Blender when using BPT usually occurs with high values of samples. For example looking for that CUDA tiemeout problem you mention, I found this report where is shared a blend file (I clarify I do not get that error, I’m only interested in the file that there is shared):
https://developer.blender.org/T40730

If I start to render this scene, Blender kidnaps my computer, I can not do anything but wait for the render is complete. With PT some lag occurs while rendering, but I can use the computer in other tasks while Blender works. Perhaps that scene is using a very large (and wrong) value in AA Samples?

Edit:
I set render AA Sampels to 4 and anyway my computer becomes unusable while render…

If you encounter this kind of behaviour you should set AA samples high and all other samples low. The linked file gets a crash at 64 diffuse and glossy samples according to the description. Reducing those and increasing AA instead should help.

64 Glossy samples means that if an AA ray hits a glossy surface, 64 glossy samples are fired from that point into the scene. All in one go on your GPU. This can…

a) …take a long time, during which your graphics output will be at a standstill (unless you have a dedicated card for screen output and one or more for rendering).

b) …let your graphics driver encounter timeout issues.

Note that PT updates way more often so you do just encounter some lag.