Russian roulette for path tracing

Category:feature request
Assigned:David Bluecame
Status:ready to commit


After talking with Rodrigo about this, I think one improvement for our next event estimation path tracer is using a russian roulette algorithm similar to the one used in photon mapping for performing an early termination of paths that does not make a significative contribution to the convergence progression. There are lots of documentation nowadays about implementing this tech in path tracing and Arnold uses this technique to accelerate their path tracing algorithm. Thanks !

Links: (page 14)



Very interesting :) I guess this with Embree Acceleration should provide very good time/ noise ratio !

Olivier Boscournu __ riofranco design  Montpellier _ France


Assigned to:Anonymous» David Bluecame
Status:active» needs review


I'm doing some tests with russian roulette in path tracing and I'm getting interesting results. However, please let me know if this is what you expect.

* "normal" pathtracing (without roulette). Render time: 5m 42s


* New pathtracing with russian roulette. Render time: 2m 13s. Much faster but more noise than the normal path tracing for the same amount of samples.

russian_roulette1 - without roulette.png 252.84 KB
russian_roulette1 - with roulette.png 274.77 KB


Status:needs review» ready to commit

This change will be implemented in the next YafaRay version. There will be a new parameter "Russian Roulette" in Blender Exporter, next to the "Bounces" path tracing parameter.

For the XML interface, there will be a parameter for the "integrator" section. For example, to enable russian roulette in the path tracing integrator, insert this line in the integrator section:

<russian_roulette bval="true"/>


Another example, russian roulette disabled. PathTracer: Overall rendertime: 153.939s


And same scene, with russian roulette enabled. PathTracer: Overall rendertime: 32.6924s !!   The image is noisier, especially in the darker areas, so it will need more AA passes, samples and/or path tracing samples to get an image with similar quality as the one without roulette, but still I think there will be an overall speed gain, but it needs to be tested thoroughly with real life examples.

russian_roulette1 - roulette disabled.png 486.43 KB
russian_roulette1 - roulette enabled.png 530.23 KB


I've modified the new russian roulette algorithm so now, instead of having a boolean parameter to enable/disable it, we will have a min_bounces parameter to better control the speed/quality ratio.

Therefore the parameter <russian_roulette bval="true"/> will no longer exist, and in its place we will have this:

<russian_roulette_min_bounces ival="0"/>

    * If this parameter is set to 0, russian roulette will be enabled.
    * If set to the same value specified in depth (max bounces), russian roulette will be disabled
    * If set to a value between 0 and max bounces, then russian roulette will only start be applied after this number of bounces, so we can get decent sampling in dark areas for example and get a good speedup with less noise.
The lower this parameter is, the more speed and more noise.

Also, the new parameter min_bounces is now shown in the parameters badge and log files.


A setting of min_bounces = 20 (which is equal to depth or max bounces) disables the roulette and the result takes 1min 20s in being rendered in my system:


If we enable roulette by setting min_bounces=0 (which is like enabling it for all rendering), we get a much faster render but with a noticeable noise in the darker areas:


However, now with the new min_bounces parameter we can control better how roulette will work. For example, a min_bounces=4 gives us a much faster renderer than not using roulette at all with min_bounces=20, but the noise and overall result is very similar to having not roulette (at least in this example):

Therefore, it looks like there is a certain value for min_bounces that will give you a very nice speed/quality ratio!  I guess it will depend on the scene and is to be "tweaked" by users, but still it should improve things when doing path tracing

russian_roulette1 - min_bounces 20.png 1.09 MB
russian_roulette1 - min_bounces 4.png 1.1 MB
russian_roulette1 - min_bounces 0.png 1.15 MB



For your reference, the way I setup the new path tracing russian roulette is based on the idea from the first link that samo shared in the original feature request. The changes in YafaRay are here:  and here:

The basic idea is to terminate paths depending on their probability and a random number.

The criteria to terminate a path is: probability [0.0 to 1.0] for a path is calculated based on its throughput (mainly its contribution). Then a pseudo random number generator generates pseudorandom values [0.0 to 1.0] for each path. If the path probability is smaller than the pseudorandom value, the path is terminated.

I hope this makes sense. Best regards!


Status:ready to commit» active

The implementation of the new russian roulette for path tracing is flawed because of incorrect pseudo-random number generation, which was taken from bidirectional integrator. See

I have now to find a solution for the problems with pseudo-number generation in both path tracing roulette and bidirectional integrator


Status:active» ready to commit

I hope this change has also solved the probable randomness issue in the roulette here too: