You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

This page is currently being updated!

Table Of Contents


Introduction

Rendering effects like depth of field, motion blur, global illumination, area lighting and others require the renderer to shoot multiple rays into the scene. When not enough rays ("samples") have not been shot, the final result can appear noisy ('grainy'). The usual solution to this is to increase the number of samples (as explained here), but that typically means longer render times.

An alternative (and faster) solution is to use denoising instead. "Denoising" refers to a rendering technique that removes noise from an image. The process can be fast (in the case of NVidia's OptiX, it's near real-time) or can take a good few seconds. In both cases, though, it should take less time than what Redshift would need to render the scene if samples were significantly higher.

Redshift supports two different denoisers: Innobright's Altus and NVidia's OptiX AI denoiser.

Innobright's Altus uses a traditional and production-proven techniques to achieve its denoising effect. On the other hand, NVidia's OptiX AI denoiser uses a deep learning algorithm that has been trained with tens of thousands of images.

Innobright's Altus is a commercial product that has to be purchased separately, although Redshift users can benefit from a special offer specifically for them. For more info on this, please follow this link: https://www.innobright.com/redshift/

NVidia's OptiX AI denoiser is free.

Each of these two denoising solution has pros and cons:

Altus pros and cons

(plus) Uses production-proven algorithms so results can be more predictable

(plus) Altus sells a separate "ServerPro" version of their product would can denoise across animations

(minus) Denoising takes several seconds to compute so it's not possible to use in an interactive fashion

OptiX pros and cons

(plus) Is very fast and can be used in interactive rendering while editing the scene 

(minus) Sometimes it can't detect noise as noise (because it hasn't been trained with that particular case) so it has trouble cleaning it


It should be noted that denoising is not a silver bullet! If the image is excessively noisy, denoising can fail in multiple ways:

  • It might simply fail to denoise the image sufficiently (i.e. noise will still be present)
  • It might 'oversmooth' certain parts of the image and lose considerable amounts of detail
  • It might produce weird visual artifacts. In the case of OptiX, these artifacts might looks like brush paintstrokes
  • In animations, the noise might appear as ugly dancing 'splotches' which can be even more visually distracting that the original noise

For the above reasons, we recommend that denoising is only used to clean "the last few percent of noise". In other words, the user should still tune their settings for an 'ok' level of noise and then denoising can be employed to make the frame perfect. This is particularly important for animations.


Before denoising

After denoising (with OptiX)

Altus

The Altus denoise options can be found in Redshift's Output tab.


Altus can operate in two modes:

  • Single Pass
  • Dual Pass

Single Pass means that the frame will be rendered once and then Altus will execute denoising. Dual Pass means that the frame will be rendered twice before denoising.

In the early days of the Altus-Redshift integration, there was no Single Pass mode so the only option available to users was the Dual Pass approach. Altus needed two separate frames so that it could determine where the noise is. The drawback of this approach is that it obviously takes twice as long to render because it renders the frame twice! Some users got around this issue by tweaking their unified sampling settings and increasing the error threshold at the last second. This meant that both of these frames would be a bit noiser but that was ok because the denoiser would clean the noise.

At a later point, Innobright introduced a Single Pass approach which can determine per-pixel noise in a single pass. This approach is much more natural as it doesn't double the frame time and doesn't involve the user having to do any tricks like tweaking their unified sampling settings.

We recommend using the Altus Single Pass option, especially if you are a new Altus user.

Altus can achieve more accurate results with the use of additional AOVs. When "Automatically Create AOVs" is enabled, Redshift will automatically add any AOVs that Altus needs to achieve its denoising results. Unticking that option means that the user will manually add the necessary AOVs.

The AOVs used by Altus are: Diffuse Albedo, World Position and Bumped Normal

While Redshift is rendering, it generates some aditional images which are essential for Altus to denoise. These buffers are normally hidden from Redshift's Render View but if you check "Show additional buffers in RenderView", those buffers will appear in the Render View's AOV list and will be previewable.

The kc1, kc2, kc4 and kf settings allow the user to control the quality and "denoising strength" of Altus.

  • kc1 controls how much high-frequency detail will be retained (i.e. sharp image features)
  • kc2 controls how much medium-frequency detail will be retained
  • kc3 controls how much low-frequency detail will be retained (i.e. chunky image features)

Lower kc values will retain more detail while higher values will make the denoising stronger. I.e. it will produce smoother results but it might lose details

The kf parameter controls AOV influence. I.e. determines how much AOVs affect the denoising results. Smaller values make the AOVs affect the denoising result more. So, for example, if you have a bump map and you see Altus smoothing the lighting on it too much, lowering the kf value will help. However this will also constrain the denoiser which means that, if the image is very noisy, it will not be able to denoise it too much around the "bumpy areas" (in this example).

After the frame has rendered and Altus has denoised it, you can toggle it on or off (to better see its effect) in the Render View by pressing the  button of the Render View.

OptiX

The OptiX denoise options can be found in Redshift's Output tab.


OptiX can achieve more accurate results with the use of additional AOVs. When "Automatically Create AOVs" is enabled, Redshift will automatically add any AOVs that OptiX needs to achieve its denoising results. Unticking that option means that the user will manually add the necessary AOVs.

The AOVs used by OptiX are: Diffuse Albedo

While Redshift is rendering, it generates some aditional images which are essential for OptiX to denoise. These buffers are normally hidden from Redshift's Render View but if you check "Show additional buffers in RenderView", those buffers will appear in the Render View's AOV list and will be previewable.

As mentioned above, OptiX is a very fast denoiser however, even at this speed, it can still "steal away" render time. For this reason, Redshift contains a couple of "denoise overhead" settings for bucket and progressive rendering.

These settings control how often OptiX is executed. A setting of 10 means "execute OptiX as often as needed but ensure that it doesn't steal more than 10% of the entire frame time".

Please note that this is an estimate that Redshift does and not a guarantee that, with this setting, OptiX will take exactly that percentage of frame time

The benefit of lower settings is that OptiX will take less time. The drawback is that, before it will gets executed even N passes (in progressive) or N buckets (in bucket rendering), you might notice some "lag". That's why we have detaulted bucket to 10% (where lag matters less and rendering performance more) and 100% for progressive (where the opposite is true).

After the frame has rendered and OptiX has denoised it, you can toggle it on or off (to better see its effect) in the Render View by pressing the  button of the Render View.