The noise in renders come from rays in pixels beside each other traveling along completely different paths and resulting in different colours/intensity as the rays bounce off different objects with different material properties and hit different light sources.
As such, you might believe that there is no noise in the albedo and normal passes used by denoising, as no shading is applied to them and the shading is what’s causing most of the noise. And with no noise in the albedo and normal passes, the denoiser shouldn’t produce noise when denoising the final render. This is mostly true. But there are a few exceptions that can mean you have noisy albedo or normal passes:
Ray traced depth of field. The blurred look of out of focus regions with doing ray tracing depth of field requires a lot of samples to resolve properly and rays can no hit much large regions than before. So if you have a low sample count, it will be noisy. The albedo and normal passes used by denoising also include the depth of field effect to avoid artifacts during denoising, and as such, these passes have similar sets of noise to the standard ray traced pass.
Reflections and refractions. When rendering a reflection or a refraction, Cycles has to make a decision between doing different tasks. “Bounce off the refractive thing like glass or pass through it with this ray?”. This introduces noise. And if the object has a rough surface, more noise is introduced as rays head in relatively random directions as it reflects or refracts off the object. Because the albedo and normal passes include reflections and refractions, they inherit some of the noise from this step.
And there are other situations where noise can end up in your albedo and normal passes.
Try it out for yourself. Render a scene with a really strong depth of field or a rough refractive object or something at a low sample count and look at the normal or albedo passes.
These noisy albedo and normal passes are what’s causing the issue with noise showing up denoised renders. And it’s only a issue with “CleanAux” on and “Prefilter” off. Because with “CleanAux” on, OIDN assumes that the albedo and normal passes are noise free, and tries to retain as much detail as possible. But they’re not noise free, and as such the “retain as much detail as possible” thing results in the denoiser retailing a lot of the noise that is in the albedo and normal passes. Prefiltering is an extra step that tries to remove noise from the albedo and normal passes by denoising them.
You might be wondering, “Why does the prefilter option exist. It’s there to remove noise from the albedo and normal passes, but with cleanaux off, it’s assumed that these passes are noisy and as part of the denoising process, they kind of have the noise removed from them?”
This is because the “prefilter” option does a better job at removing noise while retaining detail in many circumstances when compared to just turning off “cleanaux”. However, I said “many circumstances”, as such you may wish to turn the setting off to avoid some issue with it. Also, the prefilter step takes extra time to process which may be less than ideal if speed is what you want (which is something you will want for viewport rendering in the beginning).
Ok, thanks for the explanations, you are really very helpful. I was just hoping that a smart AI technology would solve things for us. Now it would seem that the user would need to know in advance when a pass may or may not be noisy in order to make decisions.
So, what do you think would be the best solution for fast denoising on viewport at low render samples with OIDN? (most of the time you will want to use low render samples in viewport). There are many scenes that leave annoying noise at low render samples when Prefilter=OFF in current Cycles-X (this does not happen with your patch CleanAux=OFF for Prefilter=OFF). And as you said, Prefilter=ON takes longer, not ideal for Viewport.
I have suggested to the Blender developers that the “CleanAux” setting (the one causing issues) is turned off in viewport rendering to work around the issue of the viewport looking noisy while denoising and prefiltering is off. Hopefully this change is implemented soon is it makes a lot of sense to do so. Keep in mind that Cycles-X is still in development and changes like these are more likely to be accepted. However, this is likely to happen next week at the earliest as it is a weekend and the developers take time off in the weekends (which they deserve)
As for working around issues with noise showing up in final renders with prefiltering off, a few options exist:
Let the user turn on or off “CleanAux” along with “Prefiltering” to get the result they need (Sergey says this needs evidence to backup the decision to put this setting into the UI)
Tie “CleanAux” to “Prefiltering” (what ⚙ D12094 Cycles-X: Turn off "CleanAux" when turning off prefiltering to avoid some artifacts. does). This way, when you turn “Prefiltering” off, you don’t get noisy renders. However, it means you lose some detail in some specific renders (mainly renders with high sample counts and noise free albedo and normal passes with “Prefilter” off and “CleanAux” on (which is impossible to achieve with the patch linked above))
Just assume that users know what they’re doing and know the technical limitations of different settings, and if they don’t know what they’re doing, will leave the denoising settings at the default settings (which is “prefiltering” on, so the user is significantly less likely to experience issues)
Create a smart algorithm that tries to automatically determine if prefiltering or cleanaux should be on and remove the control from the end user. But as with all smart algorithms, there will be edge cases that don’t work and so I’m not sure if this will happen.
Actually, looks like Nvidia devs have already found a way to ‘solve’ some of the problems. It’s only a matter of time before they’ll find a way to implement something similar into their denoiser.
There is no reason to think that once Cycles X gets path guiding and many-light sampling, that those two features can’t be combined with OIDN to help you get a clean render in all circumstances.
As a result, it is too early to draw conclusions from my perspective.
In practice you’d probably just always leave prefilter on. There’s always settings you can tweak to make things slightly faster or less noisy, but you don’t have to.
Those features will not solve that problem, nor will any other advanced light sampling algorithm. All denoising algorithms involve some amount of guessing, and the algorithm can guess wrong.
Generally, at a given noise threshold you should get an image of acceptable quality after denoising. There’s no point at which this is “solved”, it’s a continuous optimization process, tackled from 3 sides:
Improve denoising so it works at higher noise thresholds
Improve sampling to get to that noise threshold faster and with fewer samples
Improve algorithms and UX to so users don’t have to tweak settings to get desired render quality
Update again. Just tried to tweak different settings to find out why. I’m not sure but probably related to Exposure under Film? The exposure under color management does not really affect it, while the one under film seems to be directly changing the size.
If anybody knows what is happening, explanation would be appreciated.
What caught my interest was that this was based on the Müller paper I assume the Cycles devs are looking at, and in this video it’s said that they only added three lines of code to the Müller one so it would actually be easy to include:
Don’t know if the devs are planning to include this, just want to share this since it sounds like an easy thing to include along the Müller’s Practical Path Guiding (if what he said about only three lines of code is true).
I know couple others pointed this too, I do not have OPTIX listed as a device as well. Is this a temporary situation? I was hoping to use CycleX in an ongoing project.
Definitely CleanAux=ON and Prefilter=OFF (Current Prefilter box unchecked in official Cycles X) gives the best result regarding preservation of fine grain textures (very useful for interior scenes I guess). This is problematic in Glass/Transmission and Glossy/Metallic if Normal pass is used. If this is not resolved at some point, depending on the material used we could use different OIDN configurations in different render layers.
In official Cycles X to obtain a fast and noiseless Viewport at low render samples with OIDN without using the slow Prefilter if Glossy or Transmission is used, for the moment the best is Prefilter=OFF and not use Normal pass
I did a Cycles X ‘scalability’ test that I call - Expectations vs. Reality. I took my scene and rendered it at different resolution and then I compared results to what I was expecting. I used 1080p as a baseline and based my expectations on the number of pixels. I decided to post the results because they might be useful. To make things easier to read, I rounded some numbers. You can scroll to the conclusion to see the expectation vs. reality result:
Resolutions:
4320p: 7680 x 4320 (33 177 600 px)
2160p: 3840 x 2160 (8 294 400 px)
1440p: 2560 x 1440 (3 686 400 px)
1080p: 1920 x 1080 (2 073 600 px)
720p : 1280 x 720 (921 600 px)
@Florian-10 and @Kurk and others. As you have noticed, OptiX is currently missing from the user preferences. There are a few potential causes for this:
You’re using out dated GPU drivers that are no longer supported as of a recent change in Cycles-X (although, the change that would cause this issue was introduced a few weeks ago, so this probably isn’t the cause as you probably would of noticed earlier)
The build bot used to provide Cycles-X builds for users isn’t compiling with OptiX properly. This will probably be fixed soon.
Note: OptiX has not been removed from the Cycles-X branch of Blender and I do not believe it will be removed in the near future.
Does this mean that other render engines give as a result albedo and normal passes without noise even at 1 render sample? Do they apply noise reduction to those passes or do those engines generate those passes without noise natively? Is it theoretically possible to correct/fix this in Cycles?
If we’re talking about path tracers with arbitrary scenes: no, no and no.
If we’re talking about a different rendering architecture (for which a denoiser like this may not be applicable), or limited scenes without certain noisy effects, then you can get noise-free (ignoring aliasing) albedo and normal passes.
