Worse render result with Russian Roulette Termination #52313

New Issue

David Morris · 2017-08-09T08:52:04+02:00

David Morris commented

2017-08-09 08:52:04 +02:00

Using Russian Roulette sometimes results noticeably more noise (build 6af7d7e) than regular probabilistic termination in Blender 2.79 RC1 with the same render time.

2.79 RC1 (512 SPP, 69.73 s)	`6af7d7e` (512 SPP, 54.05 s)	`6af7d7e` equal time (670 SPP, 69.59 s)

Max and min samples were set to 8 and 4 respectively in RC1.

monument5 279rr.blend

A second scene tested with build 4d428d1 exhibits the same results.

2.79 RC1 (256SPP, 34.98s)	`4d428d1` (256SPP, 24.13s)	`4d428d1` equal time (380SPP, 35.28s)
{F718070 }

TESTmonument3-RR.blend

Using Russian Roulette sometimes results noticeably more noise (build 6af7d7e) than regular probabilistic termination in Blender 2.79 RC1 with the same render time. |2.79 RC1 (512 SPP, 69.73 s) | 6af7d7e (512 SPP, 54.05 s) | 6af7d7e equal time (670 SPP, 69.59 s) | ----- | ----- | ----- | ----- | ![rr0.jpg](https://archive.blender.org/developer/F701502/rr0.jpg) |![rr1.jpg](https://archive.blender.org/developer/F701505/rr1.jpg) | ![rr1-et.jpg](https://archive.blender.org/developer/F701509/rr1-et.jpg) Max and min samples were set to 8 and 4 respectively in RC1. [monument5 279rr.blend](https://archive.blender.org/developer/F701497/monument5_279rr.blend) A second scene tested with build 4d428d1 exhibits the same results. |2.79 RC1 (256SPP, 34.98s) | 4d428d1 (256SPP, 24.13s) | 4d428d1 equal time (380SPP, 35.28s) | ----- | ----- | ----- | ----- | {[F718070](https://archive.blender.org/developer/F718070/TESTmonument5-RR0.jpg) } | ![TESTmonument5-RR1.jpg](https://archive.blender.org/developer/F718071/TESTmonument5-RR1.jpg) | ![TESTmonument5-RR0.5.jpg](https://archive.blender.org/developer/F718069/TESTmonument5-RR0.5.jpg) [TESTmonument3-RR.blend](https://archive.blender.org/developer/F718077/TESTmonument3-RR.blend)

David Morris commented

2017-08-09 08:52:04 +02:00

Changed status to: 'Open'

David Morris commented

2017-08-09 08:52:04 +02:00

Added subscriber: @pixelgrapher

Sergey Sharybin commented

2017-08-09 11:23:11 +02:00

Added subscribers: @brecht, @Sergey

Brecht Van Lommel was assigned by Sergey Sharybin

2017-08-09 11:23:11 +02:00

Sergey Sharybin commented

2017-08-09 11:23:11 +02:00

@brecht, think solution here could be to use curve with a bit "steeper" tangent when close to 0. Experimented a bit with sqrtf(sqrtf(max_throughput)) and color_scene_linear_to_srgb(max_throughput). This scene seems to behave better. Think we can use some simplified version of sRGB-like curve, maybe pow(max_throughput, 1.0 / 3.0).

@brecht, think solution here could be to use curve with a bit "steeper" tangent when close to 0. Experimented a bit with `sqrtf(sqrtf(max_throughput))` and `color_scene_linear_to_srgb(max_throughput)`. This scene seems to behave better. Think we can use some simplified version of sRGB-like curve, maybe `pow(max_throughput, 1.0 / 3.0)`.

Brecht Van Lommel commented

2017-08-09 13:35:26 +02:00

Optimizing the curve for this scene is going to make it worse in others. I'll do some tests with other exponents as suggested, but importance sampling will always make some scenes worse so it's a matter of figuring out what works best on average, and some scenes will inevitably be worse.

In this specific scene, the image converges poorly due to caustics, which can be solved by setting Filter Glossy to 1. Without that, more samples actually make the image more noisy in some ways, because more fireflies start appearing.

Optimizing the curve for this scene is going to make it worse in others. I'll do some tests with other exponents as suggested, but importance sampling will always make some scenes worse so it's a matter of figuring out what works best on average, and some scenes will inevitably be worse. In this specific scene, the image converges poorly due to caustics, which can be solved by setting Filter Glossy to 1. Without that, more samples actually make the image more noisy in some ways, because more fireflies start appearing.

Brecht Van Lommel commented

2017-08-09 13:38:54 +02:00

Note that the optimal choice may also be different once we have adaptive sampling, since that gives you more leeway to risk noise in some areas of the image if it speeds up other bigger areas a lot.

Sergey Sharybin commented

2017-08-09 14:08:41 +02:00

Note that the optimal choice may also be different once we have adaptive sampling, since that gives you more leeway to risk noise in some areas of the image if it speeds up other bigger areas a lot.

I'm not sure if that's an excuse on current termination or not. If so, then it just doesn't sound right. We should not leave users with a more noisy renders just because somewhere in the future we might possibly have adaptive sampling. If we add adaptive sampling, then we can re-tweak termination criteria to what works best with it. Don't see anything wrong or bad with that.

I'm not saying the suggested changes are the way to go, just saying there is room for possible improvements, but surely more investigation needed.

P.S. While we are on this piece of code again, it feels like name path_state_terminate_probability()is inverted. It's more like path_state_keep_ray_active_probability(). It is confusing that terminate probability of 1.0 doesn't terminate, but keeps ray active.

> Note that the optimal choice may also be different once we have adaptive sampling, since that gives you more leeway to risk noise in some areas of the image if it speeds up other bigger areas a lot. I'm not sure if that's an excuse on current termination or not. If so, then it just doesn't sound right. We should not leave users with a more noisy renders just because somewhere in the future we might possibly have adaptive sampling. If we add adaptive sampling, then we can re-tweak termination criteria to what works best with it. Don't see anything wrong or bad with that. I'm not saying the suggested changes are the way to go, just saying there is room for possible improvements, but surely more investigation needed. P.S. While we are on this piece of code again, it feels like name `path_state_terminate_probability()`is inverted. It's more like `path_state_keep_ray_active_probability()`. It is confusing that terminate probability of 1.0 doesn't terminate, but keeps ray active.

Brecht Van Lommel commented

2017-08-09 14:23:59 +02:00

Not saying that we should tweak it for adaptive sampling now, just mentioning it as something to keep an eye on.

I think the standard term would be "continuation probability".

Not saying that we should tweak it for adaptive sampling now, just mentioning it as something to keep an eye on. I think the standard term would be "continuation probability".

Brecht Van Lommel commented

2017-10-19 00:02:16 +02:00

Changed status from 'Open' to: 'Archived'

Brecht Van Lommel closed this issue

2017-10-19 00:02:16 +02:00

Brecht Van Lommel commented

2017-10-19 00:02:16 +02:00

I did a lot of tests here with different powers and formulas, and didn't find anything that seems clearly better overall than what we have now. If we gradually make termination more conservative, noise in this scene goes down gradually but render time in other benchmark scenes goes up gradually too. There does not appear to be any magic point that gets us the best of both worlds. For now I'll just consider this a trade-off we do to make rendering scenes faster on average, even if it's worse for some scenes. I also suggest to just use filter glossy, which is enabled by default now, to get rid of the main source of noise in this scene.

David Morris commented

2017-10-19 21:22:18 +02:00

Is it possible to offer both the original and new termination methods available for the artist to optimise at their own discretion?

Brecht Van Lommel commented

2017-10-20 16:44:18 +02:00

We could, but it's something we should avoid unless absolutely required. There's dozens such sampling strategies that we could make configurable. In practice doing that often makes it harder to control noise as trying out all the combinations is too much work for users anyway, and too much work for us developers to ensure they all the combinations work well together or even measure the impact of sampling changes.

YAFU commented

2017-10-24 20:48:16 +02:00

Added subscriber: @YAFU

YAFU commented

2017-10-24 20:48:16 +02:00

I think using SSS I am getting different result between 2.79 release and master:
2.79:

Master:

Scene:
test_sss.blend

From master there seems to be some more noise, but also lighting and reflections change. Filter Glossy=1 does not seem to change things much.
Just mentioning this here in case there is something wrong with it, mainly in lighting and reflections.

I think using SSS I am getting different result between 2.79 release and master: 2.79: ![cpu_2.79.png](https://archive.blender.org/developer/F1063573/cpu_2.79.png) Master: ![cpu_master.png](https://archive.blender.org/developer/F1063577/cpu_master.png) Scene: [test_sss.blend](https://archive.blender.org/developer/F1063580/test_sss.blend) From master there seems to be some more noise, but also lighting and reflections change. Filter Glossy=1 does not seem to change things much. Just mentioning this here in case there is something wrong with it, mainly in lighting and reflections.

Steffen Dünner commented

2018-08-20 10:10:11 +02:00

Added subscriber: @SteffenD

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

Worse render result with Russian Roulette Termination #52313