The dark areas contain virtually no visible detail, yet they’re given the same amount of rendering attention as the bright highlights. I assumed the new Adaptive Sampling would work similarly to Lightwave’s, which focuses on details and disregards low-contrast areas (such as shadows) according to a set threshold. Rather, it seems to throw samples at noise-prone areas regardless of their actual visibility (if I’m not mistaken).
This means instead of a few seconds/minutes per 2K frame, I’m looking at over 3 hours per frame, most of which is wasted on shades of black… so for the animation I have in mind this could mean the difference between days, and months of rendering.
Adaptive sampling would probably optimize the dark areas, it’s surprising that it didn’t speed up the renders. Did you check the debug sample count pass?
Another optimization for dark areas: have you tweaked the Light Sampling Threshold?
It may be that A.S. was speeding it up a bit, but it seemed pretty negligible from my quick tests (also I was getting severe blown-out lighting artefacts in places, not sure what that’s about). It certainly wasn’t skipping over the black like LW does. Not sure how to check the debug sample count pass… I’ll have to look into that.
I tried changing the Light Sampling Threshold, but that made very little apparent difference either.
I’ve been doing some more controlled tests, and it looks like I’m making some headway with this now. The lighting artefacts I mentioned earlier appear to be related to this, since they’re remedied with the latest build.
I’ll report back with my findings after I’ve done some more testing.
By setting the AS Min Samples to 1 (that’s as low as it goes; 0 sets it to automatic), and Noise Threshold to 0.001, I managed to get a 4-5x speed increase (that’s ~40 minutes per frame instead of 3 hours something), with little discernible quality difference. So while not quite the speedup I was hoping for, it’s certainly nothing to sneeze at.
It was still getting held up in places like the ear though, which is barely legible, so it seemed like further reductions should be possible. I doubled the Render Samples to 2048 and increased the AS Noise Threshold to 0.01, and now I’m getting 10 minute renders, which amounts to something like 20x as fast as without AS. That’s more like it!
There’s some quality loss around the edges of the highlight though, so I’ll probably drop it back to 1024 & 0.001, or somewhere in-between if I can be bothered optimising it any further.
There’s SSS as well as a very fine procedural bump. The bump appears to be tripling the render times, however with my above settings most of the FG renders at about the same speed as the BG now.
Nice replica of the scene by the way (I have a separate spotlight to control the highlight). If you change the Min Samples to 1 you’ll see a nice speedup with no apparent quality difference. Weirdly I’m getting the grainy brightness issue again with your file - it’s being applied in the composite layer by the looks of it:
Try updating the 2.83 alpha. I haven’t tested the file, but I had serious wacky issues with AS a few days back, that is fixed in the version I use now.
About AS vs non-AS noise at very high samples, I have read that other users are not getting the same results, and with AS there is a bit more noise.
But about rendering times in dark areas without noise compared to bright areas with noise, clearly dark areas are much faster. By the way, do you use CPU+GPU to render? For this type of tests it is better to use one GPU only or CPU only, in order to better compare tiles speed.
I forgot to connect Image output in the compositor, it was left by default in Sample Count which is for debug.
Another thing I have noticed with this scene, is that with AS render times it depends on tile size (time differences is not so noticeable without AS): AS_tile sizes.blend (819.5 KB)
(using render border here)
Shouldn’t a bigger tile render more efficiently than a small tile with AS? It looks like the tile size speed increase overweights the AS speed increase.
I really don’t know how it should be, it’s probably what you say. I had only done a little testing in this scene using render border in shiny part. So I said that I did not want to establish any general rules.
Probably depending on the scene or part of the scene this will change.
What I don’t like is that the render time can change so much depending on the tile size in different scenes using AS. Supposedly developers had managed to make Cycles render with GPU have a similar render time with large tiles or small tiles. But with AS enabled rendering times may vary greatly depending on the tile size.
I remember that was a thing at some point, but then, from my limited experience, it went back to “larger tiles are faster with GPU”, making the whole GPU + CPU obsolete in some scenes. I didn’t follow the development close enough to say what made it revert back to its previous behavior. And this was without AS.
If you change the Min Samples to 1 you’ll see a nice speedup with no apparent quality difference. Weirdly I’m getting the grainy brightness issue again with your file - it’s being applied in the composite layer by the looks of it:
