## LuxCore: new convergence test code

Discussion related to the implementation of new features & algorithms to the Core Engine.

Moderators: Dade, jromang, tomb, zcott, coordinators

### LuxCore: new convergence test code

Introduction

The old generic (i.e. not TILEPATH specific) convergence test code was covered by GPL license and it had to be removed from LuxCore source (i.e. covered APL license). I have moved the old code back to lux repository and written a new convergence test. As the old test, it is mostly intended to render (efficiently) animations: instead of a fixed amount of samples or time per frame, the usage of an optimal amount of samples per frame can greatly reduce the rendering times.

The new test

The new test is quite simple and it checks the rendering at a fixed amount of samples (for instance every 64 samples per pixel): if the difference is under a specified threshold for all pixels, the rendering is stopped. The old

Code: Select all
batch.haltthreshold = 0.03

property is still used to define the threshold. The test is done on the output of the first image pipeline and if you are using a tone mapping plugin, the threshold is a value between 0.0 and 1.0 (for instance, 0.03 means a less than 3% difference).
The number of samples/pixel between each test is defined by:

Code: Select all
// Default valuebatch.haltthreshold.step = 64

Rendering animation frames

Due to the nature of noise reduction (i.e. to cut the noise by 2, you have to increase the samples count by 4) and low resolution of 32bit floating points (i.e. it is amazing how low it is ), it is usually better to use 2 halt conditions for animation frames:
batch.haltthreshold and (batch.haltspp or batch.halttime). The first is to cut the rendering times when possible and the second to place an hard cap to the frame rendering time.

Posts: 8404
Joined: Sat Apr 19, 2008 6:04 pm
Location: Italy

### Re: LuxCore: new convergence test code

Is the convergence test quick enough that we don't need to worry too much about the:

// Default value
batch.haltthreshold.step = 64

Or does making less checks actually speed up the render? I have no idea how things work, and those are likely independent threads, so most probably we could use 2,4,6,20,40,60,200, without noticing a change in render speed. I'd just like to confirm, however.
kalel

Posts: 258
Joined: Sun Jul 17, 2016 6:35 am

### Re: LuxCore: new convergence test code

kalel wrote:Or does making less checks actually speed up the render? I have no idea how things work, and those are likely independent threads, so most probably we could use 2,4,6,20,40,60,200, without noticing a change in render speed. I'd just like to confirm, however.

The test can be expansive at very high resolution (i.e. the cost scale linearly with the number of pixels) so you may want to avoid to run the test too often. However the cost was not noticeable at 800x600. Especially if you are doing GPU-only rendering, it doesn't matter very much.