What happened to Scrambling Distance? It´s been used in Theory and it will help speed up rendering

@ MaciejJutrzenka

Yes of course, you have it available in Graphicall.org, I uploaded it there so eveyrone could test it, but yes, only
windows.

Cheers!

1 Like

I made some test in some of my renders, i got a average of 20% speedup with not noticeable difference in the output:

Normal render with the official blender ->

Scramble distance 0.1 ->

I can not understand why this is not enable in the official version

4 Likes

I can see artifacts in the ‘chest’ shader

1 Like

Yes, I can see also artifacts, I think you should try with 0.2 instead of 0.1 :slight_smile:

Cheers!

2 Likes

i wish it would be linux. but i understand tht this is now windows only.

Here is my Linux build of 2.80 with Scrambling Distance and Dithered Sobol: http://Dragon.Studio/blender-2.80.tar.bz2 (later I will also upload it to graphicall, but for now I’m waiting for upload permission). Build was created in Ubuntu 18.04.1 LTS, so it may not work for older versions. It probably will work for other distributions if all needed libraries are present.

Since I found no up-to-date patches, I updated them myself. Scrambling Distance patch was easy, but Dithered Sobol patch was harder to update, a lot of code was changed since original patch was created.

If somebody wants to build 2.80 themselves with these features, here are patches I have used: http://Dragon.Studio/blender-2.80-patches.7z. The archive includes 3 patches (for current master):

  • 0001 is optional (unfinished fix by Philipp Oeser for issue T57852 “Mesh X-Mirror option not working”)
  • 0002 adds Scrambling Distance
  • 0003 adds Dithered Sobol

i have newest linux and somehow i can’t lunch this :o it dosn’t see blender as lunch file… ;x

I updated the link above, this time it points to .tar.bz2 archive which should be better at preserving executable permissions. If you still have issues with running my build, feel free to PM me, I will try to help. Alternatively, you can build your own version with patches I have provided.

Simple scenes tend to benefit more from better sampling patterns, because the sample stratification is preserved better. So you can’t easily extrapolate those results to more complex scenes, but it’s still helpful to test both, to understand the effects.

This is true, but low Scrambling Distance helps a lot to preserve sample stratification. With default Scrambling Distance, Dithered Sobol would be less useful even in simple scenes. I guess this is why most people end up using Dithered Sobol with low Scrambling Distance.

From artist’s point of view, Scrambling Distance by itself is useful to either reduce render time and obtain similar result, or to reduce noise but possibly introduce artifacts. If Scrambling Distance is too low, artifacts may not clear up after reasonable amount of rendering time.

I have used Rotating cube inside a blob from Blender Cloud as a test scene. Let’s try to render it with regular Sobol sampler, but with different Scrambling Distances (SD).

1024 samples, SD=1.0, render time 11m57s. This can be considered reference image, since SD=1.0 is the default.

1024 samples, SD=0.1, render time 8m56s. Slightly less noise, no obvious artifacts and it was rendered 33% faster, and looks almost as reference image.

1024 samples, SD=0.01, render time 7m13s - 66% faster than reference. There are visible low-frequency artifacts present. But if we render the same image at much higher number of samples, these artifacts will clear up eventually, but it would not be efficient to render this scene with very large number of samples per pixel, so previous SD value (0.1) was better in this case.

Best SD value depends on how much samples are needed to render the scene, and if chosen correctly it can speed up rendering and help reduce noise at the same amount of samples.

Now let’s compare Dithered Sobol and regular Sobol pattern.

8 samples, Sobol pattern.

8 samples, Dithered Sobol pattern.

In both cases SD=1. Dithered Sobol is a bit better, but no big difference.

Let’s see what happens when SD=0.1.

8 samples, Sobol, SD=0.1.

8 samples, Dithered Sobol, SD=0.1.

This time Dithered Sobol has noticeable advantage (less low-frequency noise).

At higher sample count Dithered Sobol stays better for as long as noise pattern is still visible. So it works better for preview in viewport and for final rendering with denoising, since dithering helps reduce “cloudy” low-frequency noise.

Clearly, SD=0.1 is not optimal for 8 samples because we can see low-frequency artifacts (exaggerated volumetric “rays”), but they are not permanent and will clear up at higher sample count. At more reasonable sample count such 128 they will look much closer to reference image and almost perfect at 1024 samples as was demonstrated above, but in both cases speedup will be 33%. This is what matters in the end - how final image will look at target sample count and that it will be rendered faster.

By using quick preview renders with SD=1.0 and then comparing it to another quick render with small SD value it is easy to identify where artifacts caused by reduced SD will be located, and then with border rendering it will be possible to quickly find optimal SD value for target sample count. For long renders optimizing SD will help to noticeably reduce render time.

But will too low SD cause unwanted flickering during animation? If it set incorrectly (too low for given samples per pixel) then it might, especially if scene contains moving light sources. But in this case this is not an issue and there is no unwanted flickering with SD=0.1.

Let’s compare two videos, 10 seconds long, they contain animation of “Rotating cube inside a blob”.

This video was rendered with SD=1.0 and regular Sobol. It has noticeable flickering because of irregular noise.

This one was rendered with SD=0.1 and Dithered Sobol. No annoying flickering in it, and it appears to have less noise.

If the animation rendered with reasonably high number of samples instead of 8 (for example, 128 or 1024) then volumetric rays and glowing cube’s texture will look more like reference image. Alternatively, SD can be increased… or left as is if the artist decides that artifacts do not make the image worse for a viewer who did not see the reference.

Some scenes can be rendered even with SD=0 without noticeable artifacts, and in such cases speed of rendering may increase by many times. Here is two examples:


And about Dithered Sobol again. Is it useful by itself (with SD=1)? Let’s try to render classic BMW scene with denoising at 35 samples to see if dithering can help denoiser do its work better:

Sobol

Dithered Sobol

Here are few differences. Sobol on the left, Dithered Sobol on the right.
BMW%20Sobol%20vs%20Dithered%20Sobol

Even though 35 samples is not enough for final render, with Dithered Sobol we will need less samples to eliminate denoising artifacts. Some elements, for example mirror blurred in the background, already look almost good enough with denoised Dithered Sobol but would need more samples with regular Sobol.

In my own production interior scenes I also noticed that Dithered Sobol is generally slightly better even with SD=1. However, with lower SD values it provides more noticeable advantage over regular Sobol.

Patch for adding Scrambling Distance setting as far as I know does not have known bugs, and for users who want to mess with advanced settings it can provide noticeable speedup even with regular Sobol. Patch for Dithered Sobol has some known issues.

5 Likes

Well this is for me one of those cases where there are no winners.
I switch between the two renders and can’t tell which is better: some details are better in one, some in the other. If I watch them with a pause of 10 seconds I couldn’t tell what is what.

Wich one?

Because the one that uses SD is 8 minutes vs 10 minutes, so there is a winner regarding render time :slight_smile:
And related to Dithered Sobol, in the zoom in of the BMW render you can see the main point I also notices, since the noise patter is more uniform there the denoiser “clouds” effect is much less percetible or is not present at all, you can see how uniform is the DS one vs the Sobol one, the denoised picture with DS is much more clean and defined, even the out of focus part.

So I see clear winners in those two cases :slight_smile:

That’s not flickering, it’s just noise. In the second video the noise is almost like in regular sobol when you disable animate seed. Not a pleasant effect unless you eventually denoise everything

While that may be true, with Dithered Sobol the denoised version would look much much better than the Sobol one, because of the reasons you can see in the BMW tests :slight_smile:

The point was exactly this. First two images in my previous message are practically identical visually, both have 1024 samples, but first image was rendered after 12 minutes and second one after 9 minutes - 33% faster. This is very huge difference. For some scenes (especially with toon shading or very simple lighting) speed up can be many more times greater than this.

It just like clamping, denoising, branched path tracing and other tricks - if used right and when appropriate, these tools can make noticeable difference in render time without introducing noticeable artifacts.

No, it is very different from regular Sobol with disabled animated seed. Regular Sobol has a lot of low frequency noise, and will need more samples just for that reason alone, with or without animated seed.

By the way, high frequency noise in Dithered Sobol is also much better. For example, compare these 3 images denoised with Radius = 1. Small denoising radius helps to preserve details and eliminate fireflies, and in this case it also will help to see the difference between regular and Dithered Sobol. Three images rendered at 128 samples.

Screenshot%202018-12-31%2000%3A04%3A05Screenshot%202018-12-31%2000%3A03%3A47Screenshot%202018-12-31%2000%3A11%3A49

Image 1: denoised, regular Sobol, Scrambling Distance = 1.0 (disabled)
Image 2: denoised, Dithered Sobol, Scrambling Distance = 1.0 (disabled)
Image 3: denoised, Dithered Sobol, Scrambling Distance = 0.1 (enabled)

Needless to say, Dithered Sobol will converge faster even if Scrambling Distance not used (and therefore less samples will be needed to render the scene). However, if Scrambling Distance set to 0.1, the scene will render 30% faster the same amount of samples without noticeable artifacts, and also samples will have less noise (so even less samples will be needed for final render).

All three images are crops from my own interior scene rendered at 1080p resolution.


The only source of light in the room is the window with portal behind it. This demonstrates that both Dithered Sobol and Scrambling Distance are useful in production scenes.

4 Likes

I’m just playing the Devil’s advocate role here :wink:
Why don’t you share some of your knowledge here to make this feature appetizing for more and more people???
For example here you showed a result but didn’t tell how to obtain it

Hi,
do you have a diff of your build on graphicall to test?

I´m sorry, nope.

That was not built by me, I was given the build by a friend, so I cannot point you towards the required patches.

I hope we can have both things in master soon, now it all depends on @lukasstockner97 and/or @brecht , but I´m pretty sure they are super busy, I hope they can find a blind spot to integrate this :slight_smile:

Well, if your friend did the work of updating the patch, it would help a lot. The feature is already controversial, if you then await that the work is done twice…

About a week ago I have posted here updated patches for Scrambling Distance and Dithered Sobol for current master (Blender 2.80).

There is also a Linux build with Scrambling Distance and Dithered Sobol.

1 Like

@brecht already said that he was going to implement them as soon as he had some time, so no controversy here I think, or if @lukasstockner97 wanted he could update the patch, the build is pretty old so I don´t know if the patches were updated or not, and in the end, I don´t know what the patches are, but, as @Dragon.Studio said, he updated the patches for 2.8, I did not remember that post, that is why I did not tell you, but now all is solved :slight_smile:

Cheers!

1 Like

Thanks for the Linux build and the diff :slight_smile:

1 Like