Cycles: Add optional probabilistic termination of light samples based on their expected contribution
ClosedPublic
Actions

Authored by Lukas Stockner (lukasstockner97) on Sep 9 2016, 4:18 PM.

Details

Reviewers

Brecht Van Lommel (brecht)

Group Reviewers

Cycles

Commits

rCa3796eabad34: Add optional probabilistic termination of light samples based on their expected…
rBfeb48223466a: Cycles: Add optional probabilistic termination of light samples based on…
rBS26bf230920cb: Cycles: Add optional probabilistic termination of light samples based on…
rCc8cbe6cdf623: Add optional probabilistic termination of light samples based on their…
rB26bf230920cb: Cycles: Add optional probabilistic termination of light samples based on…

Summary

In scenes with many lights, some of them might have a very small contribution to some pixels, but the shadow rays are traced anyways.
To avoid that, this patch adds probabilistic termination to light samples - if the contribution before checking for shadowing is below a user-defined threshold, the sample will be discarded with probability (1 - (contribution / threshold)) and otherwise kept, but weighted more to remain unbiased.
This is the same approach that's also used in path termination based on length.

Note that the rendering remains unbiased with this option, it just adds a bit of noise - but if the setting is used moderately, the speedup gained easily outweighs the additional noise.

There are two ToDos: First, the UI placement and name/description of the option, and second, the problem that with the current code, the termination random value is always generated, even when it's not needed.

Examples coming soon, I'm uploading with arc.

Diff Detail

Repository

rB Blender

Branch

rr_light (branched from master)

Build Status

Buildable 155
Build 155: arc lint + arc unit

Event Timeline

Lukas Stockner (lukasstockner97) updated this revision to Diff 7402.Sep 9 2016, 4:18 PM

Lukas Stockner (lukasstockner97) retitled this revision from to Cycles: Add optional probabilistic termination of light samples based on their expected contribution.

Lukas Stockner (lukasstockner97) added a reviewer: Cycles.

Lukas Stockner (lukasstockner97) updated this object.

Lukas Stockner (lukasstockner97) mentioned this in rB530673685b50: Experimental build containing updated denoising and various other patches.Sep 9 2016, 9:39 PM

So this is like D832: Cycles: Experiment with low light threshold, but unbiased. Very interested to see what performance / noise looks like.

It indeed seems a better version of my previous experiments. Nice to see the ideas were up and done properly!

Curious to see some real-life scenes speed/noise comparison tho.

Okay, finally here's a test - Sponza with a lot of lights:

No termination (default):

Threshold 0.02:

Threshold 0.1:

Threshold 0.4:

A difference in noise is noticeable in some areas (for example, the dark door(?) at the right), but in general the speedup easily makes up for that.

Lukas Stockner (lukasstockner97) mentioned this in rBc319d47f8e7c: Another experimental Cycles build.Oct 3 2016, 4:11 AM

The results look great in this scene. Is this branched path tracing with sample all lights? That should be the case where it helps most.

This scene only has diffuse, it might work even better with less rough BSDFs, as they can have a long tail with little to no contribution.

The main risk here I guess is for dark scenes, where you might have display color space conversion boosting dark areas or users increasing exposure in compositing.

intern/cycles/blender/addon/properties.py
271	Maybe a better description: "Probabilistically terminate light samples when the light contribution is below this threshold (faster but noisier)."
273	Can we add a reasonable soft max here, maybe `1.0`?
intern/cycles/kernel/kernel_emission.h
89	Could use a more descriptive name, like `rand_terminate`
151	I suggest to go with max channel rather than average.
intern/cycles/render/integrator.cpp
68	We should enable this by default I think, something like `0.1`? I would be somewhat conservative here as we don't want dark areas where it's difficult to get rid of noise. With adaptive sampling this kind of thing could probably be more aggressive, but currently the noisiest areas determine the overall required number of samples for the image.