Mysterious noise in final render not present in viewport render

Viewport Render with 1024 samples and OpenImageDenoise
image

Final Render with 1024 samples and OpenImageDenoise
image

There are no objects or lights that are set to be visible in render but not visible in viewport.

This happens in 2.90, 2.83, 2.82

Does anyone have any idea what’s happening?

I should mention that I created my lights with the Extra Lights addon (https://www.blendermarket.com/products/extra-lights) and chose the option to automatically adjust the exposure based on the strength of a candle light. So my exposure is set to 9 but I don’t see why that would be a problem since the viewport render is perfect.

Viewport in the middle of rendering 1024 samples
image

Viewport applied OIDN denoising after 1024 samples had rendered
image

Final Render with 1024 samples and OIDN
image

I have also tried rendering with up to 4096 samples. Still get the same problem.

The Optix denoiser is absolutely useless on this scene. It looks like a bad jpeg with extra jpeg.

I disabled depth of field and get the same problem in final render but not problem in viewport.
image

open4v03.blend
2020-09-19

blender 2.90

Still using lights based on extra lights addon.
Trying to determine the source of the counter top noise in final render. That noise does not happen in the viewport with viewport denoising.

I can’t find any objects that are set to be hidden in viewport but visible in render.

Maybe the AI is at fault and doesn’t know what to fill that space in with at high res? Rendered smaller image. Still had the problem.

Disabled depth of field so the counter top is in focus. Still have the same problem in final render but no problem in viewport.

After some more testing my best guess is that the AI is looking at what the image looks like at exposure zero and doing the laziest tweaks that look fine in that super dark version but look like ass when you crank up the exposure.

So based on that guess I set the Color Management exposure back to the default of zero and under Film I cranked that other exposure value up to 10.
This gave the same bad result in the final render and no problems in the viewport render.

After more testing it seems adaptive sampling is the source of my problem. With just FOUR samples the final render looks passable as long as I turn off adaptive sampling.

This is depressing. 3 minutes to render without adaptive sampling & with denoising. 40 seconds to render with adaptive sampling & with denoising, but it looks like total garbage because the denoiser is outputting trash when used in conjunction with adaptive sampling.

Adaptive Sampling ON with Min Samples of 1 makes no improvement.

Adaptive Sampling ON with Min Samples of 32 makes no improvement.

Adaptive Sampling ON with Min Samples of 300 (actual render samples 900) does look correct and with a render time of just 1 minute.

Tried again with adaptive min samples set to 134. It was not enough.

Nothing lower than 300 gives acceptable results.

Setting adaptive min samples to zero and playing with the noise threshole value now.

A noise threshold of 0.1 looks the same as setting actual render samples to a super low value like 4.

0.025 made almost no difference.

0.0025 looks as bad as the original problem. Not messing with Noise Threshold anymore. Set it back to zero and set min samples to 350.

Did a test with stronger world light and while min smaples 350 was enough for the counter top and floor, it was nowhere near enough for the back wall.

Turning adaptive sampling off completely and doing a full resolution render at 900 samples.

It took 15 damn minutes to render.

It looks correct. It does not look as good as the other version that do not use the Extra Lights addon’s candle lights. That is probably because the other version has more lights and warmer lights and they all play into the nice depth of field blur.

2020-10-08

Increased exposure under Film from 1 to 10.
Reduced exposure under Color Management from 8.5 to 4.25
Adaptive Sampling ON
OIDN denoise ON
900 render samples
1920x1080 100%
Render time: 7m30s
I can now render with adaptive sampling enabled and not get garbage from the denoiser.
This makes no sense because much earlier I tried cranking the Film exposure up to ten and still had the same problem.
Maybe a bug related to this was fixed in Blender version 2.90.1?
I forgot Adaptive Sampling > Min Samples was set to 350. I set it to zero and the problem is back again. So maybe increasing the Film exposure did not help at all?
Set min samples to 50. No improvement.

Changed Render > Advanced > Light Threshold from 0.000167 to zero. No improvement. I think this is supposed to make blender not ignore low strength lights.

2021-02-10

I just noticed my Render > Light Paths > Max Bounces are all stupid LOW values:
total:8, diffuse:0, glossy:1, transparency:8, transmission:2, volume:0

Increased them to: 12,12,12,8,4,4
Doing this did brighten up the scene a bit and improve light in some of the glass bottles but it did nothing to help with the denoising problem in final render.

Noticed that the fog volume object is invisible in viewport but visible in render. It doesn’t hurt anything to turn it on in viewport. It doesn’t fix anything to turn it off in final render.

Whoops, somehow I’m so blind I did not notice the chairs are off in final render as well. I’m having trouble hiding the original chair collection instance that is parent/child face instanced around the circle.

Removing fog and adding chairs to final render does not improve the denoising issue on the counter top.

Reduced world light from .050 to zero. Still no denoise problems in viewport. AND the denoise problem in final render WENT AWAY.

Increased world light to 1.0 - In final render the counter top no longer has denoise issue but the rest of the scene has issues in ever slightly shadowed area.

Reduced world light to 0.25 and the counter top has the issue again. It still goes away if I disable Adaptive Sampling.

Left adaptive sampling disabled.
World strength 0.100
2000 samples, denoising on
Light Paths Max Bounces all set to 128
Render camera is the one on the stairs looking down
Added a chandeleir to the kitchen for more light back there.
1920x1080 100%
rendered in 1h3m.

Also in earlier versions of this scene with regular default exposure settings and normal strength lights the same problem happens where turning adaptive sampling on dramatically decreases the results of the denoise.

So, 2 years later this problem is gone in the latest blender version but there is a new problem with one of the chairs. I got a good explanation from someone who seems confident in their understanding

Probably the same applies to the original problem.

Now, moving on to the next mystery. Why does this old scene render not much faster, and sometimes slower than the most recent version that has more objects with more complex shaders?

OLD: open4-extralights-v03.blend  
NEW: RENDER TEST open10.B.01 - 0 no pack.blend

starting point of new: http://thinsoldier.com/blender/done/Restaurant%20%20open10.B.01%20-%20libs%20packed.blend

[ OLD ] render settings:
Blender 3.4 beta
resolution:   1920 x 1080 100%
noise thresh: 0 (automatic)
max samples:  2000
min samples:  350
pattern:      progressive multi jitter
light paths:  128 [ 128 128 128 128 ] 128
clamping:     0 and 10
filter glossy 1, reflective on, refractive on
RENDER TIME:  2m 26s
old 00.jpg

[ OLD ] render settings:
Blender 3.4 beta
resolution:   1920 x 1080 100%
noise thresh: 0.01
max samples:  2000
min samples:  1000
light paths:  24 [ 14 8 12 0 ] 10
clamping:     0 and 10
filter glossy 1, reflective on, refractive on
RENDER TIME:  1m 56s
old 01.jpg


[ NEW ]  render settings:
Blender 3.4 beta
resolution:   1920 x 1080 100%
noise thresh: 0.01
max samples:  2000
min samples:  1000
light paths:  24 [ 14 8 12 0 ] 10
clamping:     0 and 10
filter glossy 1, reflective on, refractive on
RENDER TIME:  2m 36s
new 00.jpg

OK, maybe mystery solved. The old file originally had far too many light bounces (128) while the new file has a lot less (24).

Hmm, I wonder how slow the new file is with a lot more bounces.


[ NEW ]  render settings:
Blender 3.4 beta
resolution:   1920 x 1080 100%
noise thresh: 0.01
max samples:  2000
min samples:  1000
light paths:  32 [ 32 32 32 32 ] 32
clamping:     0 and 0
filter glossy 1, reflective on, refractive on
RENDER TIME:  2m 37s
new 01.jpg

Strange, it’s only about one second slower than before. What if I use 128 bounces like the old scene?

[ NEW ]  render settings:
Blender 3.4 beta
resolution:   1920 x 1080 100%
noise thresh: 0.01
max samples:  2000
min samples:  1000
light paths:  128 [ 128 128 128 128] 128
clamping:     0 and 0
filter glossy 1, reflective on, refractive on
RENDER TIME:  2m 28s
new 02.jpg


WTF? It’s even faster than before? Oh. Because of the adaptive subidivion being generated on the frst render but not the 2nd render. If rendered from scratch both 128 bounces and 24 bounces both render in about 2m 28s. So I’m still confused as to why I get the same render time with vastly different bounce amounts.

I notice that there is no difference that I can see between new02 and new01. Is cycles determining that no more than 32 bounces are necessary and just stopping there even though I set it to 128 bounces? There is a clear difference between new00 and new01.

Were the 2 scenes rendered in the same version of Blender? Do they have similar settings?

If yes, I would need to see what each one looks like. Cycles render times are not affected very much by polygon count. It’s more about the scene’s layout, the materials and the lighting, and what materials are directly visible to the camera and their size in the image.

Please see updated previous post. The new mystery is: why does the new scene with a lot more bounces render faster than it did before with a lot less bounces?
Nevermind. I think I know why. First render has to calculate adaptive subdivision geometry. Second render does not.

1 Like

I notice that there is no difference that I can see between new02 and new01. Is cycles determining that no more than 32 bounces are necessary and just stopping there even though I set it to 128 bounces? There is a clear difference between new00 and new01.

Can you shed some light on why bump maps sometimes cause light leaking from the outside? The bump map on the ceiling isn’t supposed to look like that in new02.jpg. It’s light from outside somehow creeping in. It can be fixed by adding a solidify modifier to the plane. I’d just like to understand what is happening there. I encountered a similar problem with both bump maps and displacement maps in other scenes.

When it comes to diffuse bounces, each additional one adds an increasingly small effect, because energy is lost every time light bounces off an object. In an average, standard 3D scene like this, you will struggle to see a difference past about 5 diffuse bounces, it will just make the render slower for no reason. If there is no other image to compare with, people would even judge a render with 2 or 3 diffuse bounces as being realistic. The only case where having 64 diffuse bounces could make a difference is if your scene was made of almost perfectly white materials, but that is unrealistic, bad practice and will just be very noisy.

However, when it comes to glossy bounces, having a large number can be usefull if you have glass objects, because it will allow for the complex internal reflections to be properly rendered.

And of course, a high number of transparent bounces can be needed if you have lots of alpha transparency, like a tree with leaves done using transparent textures (but that is very slow, Cycles prefers large polygon counts rather than transparent textures).

So, every bounce type has situations where a high number makes a difference, except for diffuse bounces where a handful is all you need.

I just did a small test and the bump appears to leak light, but only if you use the displacement slot. Is this your case? If I instead use the bump node, the problem disappears.

In this scene it doesn’t matter if I use bump or displacement, but in another scene that is a close up of a product the displacement as bump looks noticeably better than using the bump node for some reason.

However, since the last time I really played with these scene I have learned come to the conclusion assumption that the numbers on the bump node combine to represent meters or centimeters or millimeters so this bump is actually pretending to get the lighting of geometry that was displaced by 1.18 meters and It’ll probably look fine if I set it to 2mm

yup, seems so

1 Like

I seem to remember that the bump node is slightly buggy and incorrect on curved surfaces, so that might be why.

That makes sense. My specific test didn’t show leaks because of large numbers, but I could see it happening, especially considering bump has no shadowing.

I tried using lower bump values with a high contrast image via the brightness/contrast node but the higher I cranked the contrast the more the light leak came back.

So I decided to just cover such problem areas with more objects to block the light.


Interesting…

So changing the settings of the bump can cause leaks, but changing the image itself doesn’t?

It seems bump is in fact quite limited and needs to be used with caution. But I guess that’s to be expected, a fake, flat effect can only do so much.

edit: saw your other post, well it seems only true displacement is guaranteed to give the correct result, if one can affford it.

I actually can afford it on this scene as actual displacement but not as adaptive subdivision displacement. My problem with actual geometry displacement is even geometry distribution. There are some holes in the wall for shelves where I had to add more geometry to make the shape. Those areas with more geometry get significantly more displacement detail and look odd. They also tend to get distorted in a way that is related to the shape of the polygon in their area. So, triangles, n-gons, and rectangles look especially ugly.

1 Like

Yeah, part of affording displacement is planning the model for it from the start. Every bump method gets used where it performs best.

Solution to the original problem of this thread is that older versions of Blender were not actually using adaptive sampling in the viewport. The scene needed a lot of samples to avoid noise and using adaptive sampling was not producing enough samples to have a good result.

So this bug had me thinking I could get a high quality render faster by activating adaptive sampling because that is what the bug tricked me into believing was happening in the viewport.

1 Like

As for the 2nd half of the thread complaining about the light leak of the bump node. It turns out that I don’t really need the bump node to get the rougher look I wanted for the wall texture.

I had overlooked a mix node in the material that was sucking detail out of the base color map. Once I disabled that the wall looked rough enough even without a bump map. :cry: so much time wasted.