## A new (optionally Biased) Path Tracing render engine

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

Moderators: Dade, jromang, tomb, zcott, coordinators

### A new (optionally Biased) Path Tracing render engine

Introduction

I have worked for a while on a new (optionally Biased) Path Tracing render engine (available on this branch: http://src.luxrender.net/luxrays/file/8832569e5f67). At the moment, only a CPU version (i.e. BIASPATHCPU render engine) is available but the OpenCL version will follow soon (i.e. when the CPU version has been well defined). The new render engine is a major departure by classic LuxRender/SLG path tracer even if Lux's RenderingHints and DistributedPath SurfaceIntegrator have tried to achieve the same result in the past. The major philosophical differences are:

1) High emphasis on the first (non specular) path vertex. LuxRender/SLG path tracer usually put the same effort on all path vertices (relaying on Russian Roulette to cut the less important). BIASPATHCPU handles the first as a special case (i.e. it is the most important) by introducing path splitting (i.e. multiple different paths start from the first vertex).

2) Very tight control on when/where rays and samples are fired. Firing more samples per pixel is the only answer to noise with classic LuxRender/SLG path tracer. BIASPATHCPU is different: you can fire more rays only where the noise is present. For instance, if you have the surface of glossy material, you can just sample that particular material with more rays (i.e. spending computational resources only where they are needed).

3) Very tight control on if/when/where bias is introduced. Fireflies are one of the major problem with path tracers. They are often unable to sample some specific kind of light path and the end result are a lot of fireflies. BIASPATHCPU gives you a tight of control on which kind of light paths are sampled and offers the choose to totally remove the fireflies (by introducing bias).

Follows a detailed explanation of all new major features. SolidAngle's Arnold users may find many of the following concept familiar. The select the new render engine:

Code: Select all
renderengine.type = BIASPATHCPU

New image reconstruction algorithm (i.e. pixel filters)

LuxRender uses an image reconstruction algorithm (starting from samples) that come more or less directly from PBRT: every sample affects all the pixels inside the radius of the pixel filter. This has 3 major drawbacks:

1) It is computational expansive. For instance, with a filter size of 3 (i.e. the default value), every sample will affect up to 9 pixels;
2) Lux has to render extra pixels on the image border in order to avoid "seam" problems;
3) A thread can not have exclusive access to a pixel (i.e. locks or atomics are required).

Nowadays #1 and #3 are just plain terrible for parallelism and GPUs in general. I can not stress enough how bad they are in today multi-threads world (note: PBRT 1 was a single thread renderer). So I switched to a different algorithm where samples can affect only one single pixel and their density follow the pixel filter weight (this has the effect to produce about the same result of PBRT pixel filtering). The new image reconstruction algorithm opens the door to Tile Rendering.

Tile Rendering

Tile rendering has few advantage over LuxRender classic rendering:

1) a thread/OpenCL device can have exclusive access to a tile, avoiding any kind of locks or atomics while rendering the tile;
2) a thread/OpenCL device need to store only the tile (for instance 32x32 pixels) instead of the complete image (i.e. a lot of GPU memory can be save);
3) tile rendering exhibits a better cache locality providing about a 5-10% speed up over classic Lux rendering.

This is an example of tile rendering in action:

The 12 yellow squares are the tiles rendered by 12 threads following an Hilbert curve. tile size can be set with the following parameter:

Code: Select all
tile.size = 32 (default value)

Note: by default, the rendering will always terminate when all tiles have been rendered.

Multi-pass rendering

Multi-pass rendering can be enabled in order to not stop when all tiles have been rendered. This will effectively mimic the classic LuxRender "never ending" rendering. Mostly useful for rendering single images. Parameter:

Code: Select all
biaspath.multipass.enable = false (default value)

Progressive rendering

Progressive rendering is mostly useful for previews. Instead of rendering all the samples of a single pixel (and taking a lot of time for showing a complete image), it will render only one sample per pixel at time, producing a first version of the image in a very short time. Parameter:

Code: Select all
biaspath.progressiverefinement.enable = false (default value)

Radiance clamping is a very simple trick used to minimize fireflies. When enabled, it places an upper limit on the value that a single sample can have:

An image is worth a thousand words !

Code: Select all
biaspath.clamping.enable = false (default value)biaspath.clamping.maxvalue = 10.0 (default value)

AA sampling

Set number of samples per pixel. It should be increased only to avoid image plane aliasing artifact and depth of field noise. Nothing else, there more specific settings for removing other kind of noise. Parameter:

Code: Select all
biaspath.sampling.aa.size = 3 (default)

Note: 3 means 3x3 (i.e. 9 samples).

Direct light sampling

Set the default number of shadow rays for direct lighting sampling. Parameter:

Code: Select all
biaspath.sampling.directlight.size = 1 (default)

Note: 3 means 3x3 (i.e. 9 rays). You can also override the global setting on a per light base by using the following parameter:

Code: Select all
scene.infinitelight.samples = 3scene.skylight.samples = 3scene.sunlight.samples = 3cene.materials.whitelight.emission.samples = 3

Note: 3 means 3x3 (i.e. 9 rays).

Direct light sampling strategy

By default, BIASPATHCPU uses a "all uniform" light sampling strategy for first path vertex and "one importance based" strategy for all other path vertices. You can force the usage of "one importance based" strategy for the first vertex too with the following parameter:

Code: Select all
biaspath.lights.samplingstrategy.type = ONE

or:

Code: Select all
biaspath.lights.samplingstrategy.type = ALL (default)

This is mostly useful to render scenes with thousands of light sources.

Light near start (introduces bias)

This is another little trick that can provide good results. When an area light touch another surface, it can easily generate fireflies because the square of the distance is at denominator of computation. By setting a minimum distance from the light source to receive light solve the problem:

Parameter:

Code: Select all
biaspath.lights.nearstart = 0.001 (default)

Light low threshold (introduces bias)

This parameter is used to avoid to sample light that have a too little contribution to the current sample. Mostly useful when rendering scenes with many light sources and/or to reduce rendering time. Parameter:

Code: Select all
biaspath.lights.lowthreshold = 0.001 (default)

Diffuse, Glossy, Specular material sampling

Set the default number of rays used to sample Diffuse, Glossy and Specular surfaces. This is an example of glossy material sampling with 1x1 rays Vs. 7x7:

Parameter:

Code: Select all
biaspath.sampling.diffuse.size = 2 (default)biaspath.sampling.glossy.size = 2 (default)biaspath.sampling.specular.size = 1 (default)

Note: 3 means 3x3 (i.e. 9 rays). You can also override the global setting on a per material base by using the following parameter:

Code: Select all
scene.materials.shell.samples = 3

Note: 3 means 3x3 (i.e. 9 rays).

Total, Diffuse, Glossy, Specular path maximum depth (introduces bias)

Set the maximum number of total, diffuse, glossy and specular bounces of a path. Parameter:

Code: Select all
biaspath.pathdepth.total = 10 (default)biaspath.pathdepth.diffuse = 1 (default)biaspath.pathdepth.glossy = 1 (default)biaspath.pathdepth.specular = 2 (default)

Diffuse, Glossy, Specular, Emission material visibility in indirect rays (introduces bias)

This is the main tool to remove fireflies and enabale/disable the visibility of a material (i.e. area light, a specular object, etc.) in indirect rays:

Parameter:

Code: Select all
scene.materials.whitelight.visibility.indirect.diffuse.enable = 1 (default)scene.materials.whitelight.visibility.indirect.glossy.enable = 1 (default)scene.materials.whitelight.visibility.indirect.specular.enable = 1 (default)

Example: Unbias Vs. Bias

This is a simple example of what BIASPATHCPU can be used for:

The following BIASPATHCPU parameters have been used to reduce noise and remove fireflies:

1) Glossy LuxBall shell and light source are not visible in indirect rays (in order to remove fireflies ... and caustics);
2) Lights are sampled with 3x3 rays (in order to reduce shadow noise);
3) Glossy LuxBall shell is sampled with 3x3 rays (in order to reduce glossy noise);

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

### Re: A new (optionally Biased) Path Tracing render engine

I've been waiting for this post so much.
Linux builds packager

SATtva

Posts: 7164
Joined: Tue Apr 07, 2009 12:19 pm
Location: from Siberia with love

### Re: A new (optionally Biased) Path Tracing render engine

CyLux, if you will. I'd love to try it asap!
zsolnai

Posts: 519
Joined: Sun May 22, 2011 6:17 pm

### Re: A new (optionally Biased) Path Tracing render engine

- New image reconstruction algorithm (i.e. pixel filters);
- Tile Rendering;
- Multi-pass rendering;
- Progressive rendering;

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

### Re: A new (optionally Biased) Path Tracing render engine

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

### Re: A new (optionally Biased) Path Tracing render engine

Very interesting, it's always great to be able to control every aspect of a renderengine. The part about image filters was new to me.
I'm looking forward to test this engine

B.Y.O.B.

Posts: 5181
Joined: Wed Nov 10, 2010 4:10 pm
Location: Germany

### Re: A new (optionally Biased) Path Tracing render engine

very good news!!

I'm very curious where development will go... but the start is very promising.
marcatore

Posts: 122
Joined: Sun Aug 09, 2009 4:17 pm

### Re: A new (optionally Biased) Path Tracing render engine

Great results Dade, cant wait to try it

moure

Posts: 422
Joined: Sun Sep 26, 2010 4:32 am
Location: Greece

### Re: A new (optionally Biased) Path Tracing render engine

Code: Select all
renderengine.type = BIASPATHCPUtile.size = 32

This params in .scene or .cfg file ??

Edit: in .cfg, of course

povmaniaco

Posts: 220
Joined: Tue Sep 01, 2009 1:27 pm
Location: Barcelona, Spain

### Re: A new (optionally Biased) Path Tracing render engine

povmaniaco wrote:This params in .scene or .cfg file ??

Edit: in .cfg, of course

Yup and you need a couple of other settings to render LuxBall correctly with BIASPATHCPU, you can use this .cfg (http://src.luxrender.net/luxrays/raw-fi ... uxball.cfg, don't forget to press '0' key or set renderengine.type = BIASPATHCPU) and this .scn (http://src.luxrender.net/luxrays/file/8 ... uxball.scn).