Worse render result with Russian Roulette Termination
Open, ConfirmedPublic

Description

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.

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)

Details

Type
Bug
David Morris (pixelgrapher) created this object with edit policy "Custom Policy".
Sergey Sharybin (sergey) triaged this task as "Confirmed" priority.Wed, Aug 9, 11:23 AM

@Brecht Van Lommel (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).

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.

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.

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.

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".