Adaptative sampling is not a magic solution that will resolve any kind of noise. For the renderer to properly measure the noise level, you need enough sampling 1st, or it won’t make the difference between noise and lights/details.
How many min. samples do you have in your scene ?
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 471.96
Blender Version
Broken: version: 3.0.0 Alpha, branch: cycles-x, commit date: 2021-09-06 18:07, hash: rBd8088307847c
It appears volume rendering has gotten worse. In the render below when the volume is inside another volume it gets masked out by the inner volume object material. Previously it was performing same as 2.93.
2.93 latest RC vs CyclesX
1 Like
There was a scene provided by another user that shows a similar issue to the ones you’re talking about. However from testing with the latest Cycles-X it seems that this issue only occurs in the viewport when the noise threshold is set to 0. 0.1 seems to be fine, same with probably a lot of other values.
Caustics can also be a cause for problems with adaptive sampling:
I thought that issues like the one with caustics was caused by the light being highly unlikely to hit. As such most rays end up traversing through the scene and hit various parts of the scene that have vary little variance, resulting in very little noise in that area. And so the adaptive sampling system just assumes the noise threshold had been reached and stops. But if it continued sampling, at some point a ray will eventually hit the light resulting in a bright spot detected as “a lot of noise” and the adaptive sampling system won’t stop prematurely. Obviously with the case of caustics this issue can be assisted with different rendering techniques, some of which are planned for the future of Cycles?
Both scenes can be found here: https://drive.google.com/drive/folders/1R1Hm3QTknvEtC5Cu5TK3CN34XNiBQFVN?usp=sharing
41ce217d3ce9 GUI/CLI vs. 7bbe12b64f46 GUI/CLI
Win10 2004 / 3600X / 16Gb / GTX1660 (471.68)
Barbershop scene (CUDA, 2048x858, custom camera position, 100 samples, OIDN):
41ce217d3ce9
GUI: 95
CLI: 82
7bbe12b64f46
GUI: 89
CLI: 82
Profiler:
Additional notes:
-
For some reason 7bbe12b64f46 crashes a lot. Besides that, having ‘Persistent data’ on crashes Blender when your press F12 or breaks the renderer (usually) after the first render (CUDA).
-
I encountered a problem (or not?) with the tiled rendering. I tried it with my one of my test scenes. I set the image resolution to 2k (2560x1440) and then tried different tiles settings. It worked just fine with tiles set to 256, 512 and 1024. But when I set it to 2048, Cycles rendered both tiles, but right after the second tile denoised they both disappeared and I ended up having no picture at all. Just a blank screen with the time stamp of the rendering time (saved picture was just black). The same happened when I set the image resolution to 8k and the tile size to 4096. All four tiles were rendered just fine, but after the last, 4th, tile was denoised - the picture disappeared again. I tried the same with CLI and saw a bunch of errors after each tile:
- Error writing tile Could not open “E:\Downloads\Blender\Program\BlenderTemp\blender_a08428\cycles-tile-buffer-9604-2099307596352.exr” (bad allocation)
- called OpenEXROutput::write_tiles without an open file
- Error writing tile called OpenEXROutput::write_tiles without an open file
- Error opening tile file E:\Downloads\Blender\Program\BlenderTemp\blender_a08428\cycles-tile-buffer-9604-2099307596352.exr
- Error reading tiles from file.
Cycles had no problem rendering 8k image with the tile size set to 1024 or with Auto Tile disabled.
1 Like
in my scene GPU + cpu takes almost twice as long compared to GPU. could someone check please, my pc is old. I use cyclesx 06-sep-21.it only happens with this scene
I leave min samples at 0. But even if I raise min samples to 256 or 512, noisier area stops refining as soon as it hits min samples and still gets less samples overall.
I think the issue is with how Cycles measures noise in general. Maybe it doesn’t take into account gamma and exposure of the final output? For example, if I save my image with gamma 1, then shadow area is almost black so it makes sense to stop sampling it early because the noise is not visible there anyway. Unfortunately in sRGB mode noise is still very obvious.
Just a theory though.
Is it possible to share your sample scene ? I’d like to do my own test with the same setup as yours.
Here you go Unique Download Link | WeTransfer
Although I doubt there’s something wrong with the scene. I’m noticing the same behaviour in other scenes.
For me as well. It seems that cpu is holding back the gpu, judging by the gpu usage graph.
But I noticed something interesting with gpu only - optix takes 1m23s to render, meanwhile cuda takes only 15s ::
1 Like
I tested your scene and performance was all over the place. It ranges from 21 second to 2 minutes and 30 seconds.
b.7bbe12b64f46
Profiler:
I also tested it with 3.0 Alpha Master branch (7beb4a0e0a49) and results were all over the place as well. Performance ranged from 43 seconds to 4 minutes and 30 seconds.
Profiler:
1 Like
I don’t think Cycles takes that into account, there was a similar idea proposed a few days ago but I was against that.
I think it might be the light threshold? It samples less of the light below the threshold brighness and makes the darker part noiser:
I tend to turn it to 0 when its assumption regarding which part the image is darker fails. Maybe you can try this.
EDIT: Oh, just read Nequine’s post below, it looks like it’s completely unlreated to light theshold, it is simply the scene being hard to converge.
So, I’ve done some tests with your scene, and your scene is quite hard to converge for the renderer as your lighting is coming at 85% from the background shader with a strengh of 50. Adaptative don’t have much work to do here.
Your scene :
Without the background shader :
But in a second time I tried to match your lighting by using the area light used as a portal, to give an alternative solution. While better than the background shader, I was surprised how poorly the area light resolved at 128 min samples/1024 max sample, 0.05 noise threshold. I also forced min 2 bounce lights.
And with 512 min samples :
Here 2 other tests. 128-1024, 4 bounces, 0.005 light cut off and 1 quad light. ( sorry for the camera that doesn’t match ) :
Cycles -
Guerilla Render, a full progressive adaptive renderer that is, imo, a reference :
Guerilla held the render much longer ( 8min vs 12min ) but ended up with a more evenly distributed noise, which is more in line with what we can expect from the adaptative option.
In hope those little test can help.
3 Likes
What’s up with this whole thing where people model in Blender not up to scale of 1 meter = 1 meter? This is not the first time I see a Blender scene with environment that feels like it’s a doll house. AFAIK it is recommended to have everything up to the real world ‘scale’ (1m=1m) if you want to achieve realistic (physically based) lighting. Am I missing something?
Your scene:
This is ‘kind of’ up to ‘scale’:
5 Likes
Yes, it’s a quite difficult scene, probably the worst case scenario for interior lighting, but that makes it a good test case. But can you elaborate on how you did that second example with area light used as a portal? Because I’ve already put portal lights in windows, and they help to reduce the noise a bit, although not as much as I expected.
But the issue here is not that the scene is hard to resolve. Without adaptive sampling even shadows clean up pretty well in a couple minutes. It’s not like rendering caustics, that you know are not gonna converge in a million years. The problem is that adaptive sampling work in a counter-productive manner here. For some reason red area hits noise threshold first, even though it’s still very noisy and stops sampling. Meanwhile blue area that is lit by direct light keeps getting more samples, even though it’s already pretty clean.
Surely, adaptive sampling should be doing the opposite and giving more samples to noisier parts of the image. My only explanation is that Cycles cannot properly detect noise in darker values right now for some reason.
Dunno about other people but my scene has correct scale, because it’s been modelled according to measurements of a real location. Keep in mind that this is a small attic apartment with a low ceiling which might throw off your sense of scale. For example kitchen top is at 85cm so that guy in your “correct” example would be about 130cm tall. 
Also difference in scale is too small anyway to cause any issues with accuracy. It would need to be off by orders of magnitude.
For the setup with the area light, I just disabled the background shader and used the area you created as a light emitter instead of a portal.
And from my own test, the noise doesn’t clear that well even without adaptative. You need to use very high samples to get it clean.
For the adaptative to properly do its job, it needs to be able to discern the noise from the details. In your test here it is so noisy that Cycles can’t make the difference. Hence why the area in the light keeps getting hit, it detects the noise properly and tries to sample to get to the noise threshold you gave him.
But like I showed with the comparison with Guerilla Render, it should be able to pick up the noise here, the way it is behaving right now is not predictable at all. Which is, imo, counter intuitive with the way an adaptative renderer should work.
Strangely, recent builds struggle with same scenes cyclesX Build(8988fcc49436) easily renders. They either crash or run out of VRAM. kinda wierd considering recent builds are close to master. I hope the developers have answers to such crucial issue.
You are right, sorry if my comment offended you. That attic thing and kitchen top at 85cm is what messed with my sense of scale. Here is why:
1 Like
I see that the adaptive sampler behavior is more predictable when the raw values are lower or closer to the color management transformation. In your case the intensity of the world may be causing problems. You can check it with this blend. Render scene 01 and then 02, you will see a big difference in samplecount pass and render time, but the results are very closed, I only change de raw data exposure and world intensity.
I also see that it can be problematic with the use of the nishita sky texture because the adaptive sampler will spend a lot of time sampling the areas that are too bright since the adaptive sampler seems to not take into account the exposure in the film panel.
1 Like
I did a quick test with your solution with my area light setup. Sadly it didn’t help at all.
build 66a5b1f6e50d, cpu, 512min samples 1024 max samples, 0.05 noise threshold, both around 8min rendertime
150W Area light, 1expo in film tab-
100W Area light, 2 expo in film tab-
As a reference, I post again the Guerilla Render image. 128min/1024max samples
I have to add what we should NOT trying to fiddle around with the linear image outputed by the renderer. This should not be a valid all around fix for a sampling issue.
What you need to compare is Samplecount pass, you could do a test with 100W LAMP vs 1000W LAMP and compare the SAMPLECOUT? We are trying to have less samples in the bright area
The bright area are clearly not the problem here.
Why would I completely cheat something that should not be done anyway?
In your test scene I got lower render time ( so less samples used ) when your sky exposure was lower and film exposure higher. I gave a test with the same 1expo difference and it didn’t got any significant result. So doing it with a 1000w light should give me worst results than we already have.
Or maybe this film exposure is doing wrong from the start ?