Adaptive sampling

This page details how REDsdk can be used with a dynamic adaptation of its sampling quality, to generate faster images, while preserving image quality. Adaptive sampling is a technique that is specific to software ray-traced images. There are two modes for using adaptive sampling in REDsdk:

See the Adaptive sampling controls paragraph down the page for details on these two modes.

Brute force ray-tracing vs. adaptive ray-tracing

The default REDsdk setup use a brute force ray-tracing approach. This means that for a given pixel to compute in an image a constant computation effort is allowed to it. This amount of computation effort is the result of the ray-tracing rendering options that are turned on for the image processing: reflect & refract depths, shadowing depth, ray cutoff, light cutoff, anti-aliasing, etc...As a result, we get an image with a variable noise level per pixel, that depends on the frequency of the phenomenon we have to sample (reflections, shadows of tiny objects, etc...).

Let's consider a simple scene to illustrate this point:

A brute force processed image.

As we can see, we have no noise in completely dark areas, a very small noise in completely lit areas due to the surface of the ligh and we do have much more noise in penumbra areas, where the investment per pixel is not enough to generate a noiseless, perfectly smooth, signal.

Then, the idea behind processing the image using adaptive sampling is to tolerate a user specified noise level everywhere in the image. As soon as this noise level is reached for a given pixel, we can stop calculating for it, and thus we can save time, focusing calculations in image regions where there's more complexity to handle. The image below illustrates this point. This is an amplified view of amount of calculations saved per pixel:

Brighter areas are those where we skip the more calculations.

As we can see, regions of the image that are fully obscured (those in full shadows or behind the lightt) are receiving a limited amount of calculations due to the fact that for each sample fired, we just get a black color. Therefore, we quickly see that the signal is constant in these areas, so we quickly stop calculating redundant samples there and concentrate on other image areas. At the opposite side, penumbra regions are shown as the darker ones in the image above: due to the fact that we're in penumbra regions, we need to compute more samples before we can eventually reach the wished noise threshold.

Practically, compared to a brute force image, adaptive sampling will remove useless calculations and progressively equalize the noise level in the image. For limited changes in the image, the usage of adaptive sampling can save a lot of time compared to a full brute force image.

Turning on adaptive sampling

Adaptive sampling requires three options & engine parameters to be effective:

  1. The image must be rendered with software anti-aliasing turned on, using RED::IViewpointRenderList::SetSoftAntiAlias, possibly at a higher level than for regular images to allow for more adaptation.
  2. The sampler used must be set to the progressive HM sampler, by switching the RED::OPTIONS_SAMPLER value at the resource manager level.
  3. The wished quality must be specified using the RED::OPTIONS_RAY_ADAPTIVE_SAMPLING_THRESHOLD value, or an amount of time allowed to compute the image must be set using the RED::OPTIONS_RAY_ADAPTIVE_SAMPLING_ALLOWED_TIME option. See below for typical values for these settings.

Adaptive sampling don't require any other change to the scene rendering options.

Adaptive sampling controls

Adaptive sampling controls

The "sampling window" depicted in the picture above translates the quality that can have the final image. For instance if the RED::OPTIONS_RAY_LIGHTS_SAMPLING_RATE is set to 16 this means that up to 16 x 16 rays will be fired to estimate the quality of the lighting at one point. If we fire all 256 rays we're on the right of the image and if we fire less, we're on the left of the image. This is for the orange bar in the picture above. Now moving the RED::OPTIONS_RAY_ADAPTIVE_SAMPLING_THRESHOLD to higher values (lower the quality: move the slider to the left) or to lower values (higher quality: love the slider to the right) will cut the image calculation when the wished quality level has been reached.

So, we have two main levers to control adaptive sampling:

  1. Values for sampling options (RED::OPTIONS_RAY_LIGHTS_SAMPLING_RATE and RED::OPTIONS_RAY_GLOSSY_SAMPLING_RATE) define a rendering window: this bounds the minimal and maximal quality in the final image. It'll not be possible to get out of this window, whatever the other options values. Increasing the light and / or glossy sampling rates will move the window toward a better quality, reducing sampling rates doing the opposite. On increasing or decreasing sampling rates, the whole window is moved, so the lower quality boundary moves as well as the higher quality boundary.
  2. Then, the value of the adaptive threshold (RED::OPTIONS_RAY_ADAPTIVE_SAMPLING_THRESHOLD) caps the maximal quality to the user specified threshold. Note that reducing the threshold increases the maximal quality and vice-versa. If the threshold is too small, then the image will render as if there were no adaptation. If the threshold is too large, the image will render as if there were with no adaptation, as if it were rendered with lower sampling options.

Typical values for adaptive sampling are:

But we have another lever we can trigger which is the RED::OPTIONS_RAY_ADAPTIVE_SAMPLING_ALLOWED_TIME. If set to a positive value in seconds, then the adaptive threshold set by RED::OPTIONS_RAY_ADAPTIVE_SAMPLING_THRESHOLD will be ignored and the computer will spend that amount of time processing and refining the image. It'll stop after having spent approximately the requested amount of time.

There are two limits to the time that'll be practically taken by a calculated image: