Light threshold broke branched path tracer #50116

New Issue

Sergey Sharybin · 2016-11-25T18:15:37+01:00

Sergey Sharybin commented

2016-11-25 18:15:37 +01:00

System Information

Linux Debian Jessie, 64bit, core i7 something. Should not really matter.

Blender Version

Current git bcd0d85.

Short description of error

The image is too noisy. Very too much noisy.

Exact steps for others to reproduce the error

Just hit Shit-Z in untitled.blend

@brecht says it's really a bug.

**System Information** Linux Debian Jessie, 64bit, core i7 something. Should not really matter. **Blender Version** Current git bcd0d85. **Short description of error** The image is too noisy. Very too much noisy. **Exact steps for others to reproduce the error** Just hit `Shit-Z` in [untitled.blend](https://archive.blender.org/developer/F406195/untitled.blend) @brecht says it's really a bug.

Sergey Sharybin commented

2016-11-25 18:15:37 +01:00

Changed status to: 'Open'

Sergey Sharybin commented

2016-11-25 18:15:37 +01:00

Added subscribers: @brecht, @Sergey

Lukas Stockner was assigned by Sergey Sharybin

2016-11-25 18:15:54 +01:00

Lukas Stockner commented

2016-11-25 23:56:34 +01:00

I've just tested the file, and there indeed is a huge difference when disabling the light termination.
However, the same seems to happen for regular PT (which makes sense, since there's only one light source).
Here are my renders (with Color Management exposure at 3):

BPT, Termination 0.05:

BPT, No Termination:

PT, also 4 Samples, Termination 0.05:

PT, also 4 Samples, No Termination:

The main problem is that this scene is pretty dark (even the bright checker squares only get up to 0.05), so the default termination value is too high here. That is a problem in general - the threshold should be relative to the area's brightness, but you don't know that before rendering...

I've just tested the file, and there indeed is a huge difference when disabling the light termination. However, the same seems to happen for regular PT (which makes sense, since there's only one light source). Here are my renders (with Color Management exposure at 3): BPT, Termination 0.05: ![bpt_t.png](https://archive.blender.org/developer/F406267/bpt_t.png) BPT, No Termination: ![bpt_nt.png](https://archive.blender.org/developer/F406269/bpt_nt.png) PT, also 4 Samples, Termination 0.05: ![pt_t.png](https://archive.blender.org/developer/F406271/pt_t.png) PT, also 4 Samples, No Termination: ![pt_nt.png](https://archive.blender.org/developer/F406273/pt_nt.png) The main problem is that this scene is pretty dark (even the bright checker squares only get up to 0.05), so the default termination value is too high here. That is a problem in general - the threshold should be relative to the area's brightness, but you don't know that before rendering...

Sergey Sharybin commented

2016-11-26 00:42:18 +01:00

If such optimization leads to a more noisy image in dark areas then i'm not fully convinced in default value for it picked up correctly: you optimized per-sample time but required to have more samples to clear up the dark areas?

Brecht Van Lommel commented

2016-11-26 14:11:13 +01:00

Perhaps when we have adaptive sampling we can do some kind of brightness estimation and adaptively change the threshold. Currently I suggest to lower the default threshold to 0.01.

I noticed the result with 1 sample the shadows look really different. This correlation problem is not new, it's the same as e1e247a99b. Adding the extra hash for every RNG dimension solves it but slows down rendering, ideally we'd find a faster way to do this hashing.

Perhaps when we have adaptive sampling we can do some kind of brightness estimation and adaptively change the threshold. Currently I suggest to lower the default threshold to 0.01. I noticed the result with 1 sample the shadows look really different. This correlation problem is not new, it's the same as e1e247a99b. Adding the extra hash for every RNG dimension solves it but slows down rendering, ideally we'd find a faster way to do this hashing.

Sergey Sharybin commented

2016-11-26 16:29:23 +01:00

Will simpler hash combine function work?

For example, default Boost's hash_combine will be expanded to something like result ^= dimension + 0x9e3779b9 + (result << 6) + (result >> 2) for the case of integer dimension and hash result. Seems to be way simpler than cmj_hash() but can't test ATM whether it solves the correlation artifact.

Will simpler hash combine function work? For example, default Boost's `hash_combine` will be expanded to something like `result ^= dimension + 0x9e3779b9 + (result << 6) + (result >> 2)` for the case of integer dimension and hash result. Seems to be way simpler than `cmj_hash()` but can't test ATM whether it solves the correlation artifact.

blender-admin commented

2016-12-01 14:27:10 +01:00

This issue was referenced by blender/cycles@1fdbf8fbba

This issue was referenced by blender/cycles@1fdbf8fbba2650b43ca390b9d9825068dab215d2

blender-admin commented

2016-12-01 14:27:10 +01:00

This issue was referenced by f812b05922

This issue was referenced by f812b05922f51c4c6c5d1c8898fb2cd6aba3f3f0

Sergey Sharybin commented

2016-12-01 14:30:23 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2016-12-01 14:30:23 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Light threshold broke branched path tracer #50116