If the new features don’t cause crashes, don’t affect render output or performance at all when set to their default values, AND can be hidden as Experimental features, that seems like a strong argument for inclusion.
2 Likes
As far as I know, they comply with all those things. 
Scrambling distance isn’t just super fast in the preview, it also looks very cool.
I think this is argument enough to put it under experimental.
I use blender not only because some tools are better, i use blender especially because it’s more sexy than other applications and i have more fun while doing things, for me this is the most important part of a software.
After all some of us sit more than 8 hours a day in front of this app.
So please just put it there and let us have fun
3 Likes
as far as I can read, this is what he thinks…
There’s actually this comment from the patch coder:
which by the way one could answer “If I don’t notice I don’t care”
But here is the long version:
As you could tell, for animation (which is the primary goal for Cycles) this isn’t good, except
Those explanations can be applied to the denoiser, if you denoise with a low sampling level, it will flicker, of course if you enter bias in the render, you will have to be aware of some details.
The thing is this does the same thing, if you render up to a point were there is no effect visible, there is no trouble with this, there is a key thing here:
“if you know what you’re doing, you can get good results with it”
And the same thing applies to Branched Pathtracing, I find Branched Pathtracing far more complex to use than Scrambling Distance, if you set things wrong you will get bad AA, maybe not for a frame of the animation were you can´t see glass, but if you have the branched path tracing with a wrong configuration you will end up with a pretty ugly looking glass in the middle or your animation for example.
The same thing applies to Simplify AO bounces, if you configure it too low and you don´t have visible glass in your frame all is good, but if you go to a frame were there are two overlaped pieces of glass suddenly you can end up with a black object in your render.
All those things apply to any advance setting of any renderer, no matter if it´s a pathtracer or not.
What users need is a good looking render in the less possible time with the less possible noise, we don´t care about the mathematical estimation of the amount of noise present in the image if we cannot notice the noise (Dithered Sobol… that BTW there is no explanation on why is not implemented), I understand this is impòrtant for adaptive sampling, but so far we don´t have adaptive sampling either.
The thing is, it´s perfectly reasonable that this is present under experimental, is pefectly reasonable that this could be placed under “simplify” instead of sampling, there are a lot of things that are perfectly reasonable, but this is a feature that while it may not work in some situations (exactly the same as the denoiser and the simplify AO Bounces or many other things) it works in many situations and it help us to render faster and cleaner.
And there is another key thing, after many tests with our current project, I cannot see any kind of break in the renders, nor other users have seen any kind of problem, of course if you render a complex scene with 10 samples you will notice A LOT of problems, but if you don´t have scramble distance you will also notice A LOT of problems, named noise hehehe
So I don´t see a reason in all those explanations to no include Scrambling Distance and Dithered Sobol as experimental features for advanced users, any user can break a render with the current settings (it is as simple as lowering the number of bounces in pathtracing)
Another example, if you put the Clamp Direct and Clamp Indirect values to wrong values you will be breaking your final image, you will loose your highlights, you will break your lighting, but that is no reason to avoide having it.
There are a lot of features that can be related to those two explanations and are present in cycles, so I don´t see that a problem, specially when Theory has been using it for a long time with success.
Cheers!
2 Likes
This is the part that I understand the less… if he refers to animation, as I said is the same with the Denoiser, you could think that your noise level is ok for the denoiser to render an animation and after rendering it you end up with a lot of clouds floating in your screen, but you only notice this if you render an actual animation.
What is the solution?
Render a few frames and check if everything is correctly working, wich is the same solution that Lukas proposes to check if scrambling distance is breaking your frames.
Just call the properties section “Very Advanced Settings” lol. That should scare people away.
2 Likes
Also, regarding what he thinks, what you posted is something Bretch said at the begining of the thread, I´m asking right now, after many users have tested it, there is even a case study with several tests, other users report no problems so far, so precisely because he said:
“Anyway, I’m not entirely opposed to having this option in the Advanced sampling panel. But I would first like to see some clear evidence of the speedups this provides, comparing render noise levels and time on some non-trivial scenes. When I did some tests in the Cycles benchmark scenes the results were not really convincing.”
So right now, there has been several testing by several users, and we could have MUCH MORE if this is implemented in master under experimental, because a lot of users would be able to use it without having to use an outdated build that has AO Bounces broken in some situations for example.
So that is why I´m asking right now to him, I already know his opinion from the begining of the threa, and there is no reason to quote him I think, I refer to updated thoughs
Cheers!
1 Like
@lsscpp have you tested it in some of your production scenes?
I find that the most powerful situation is to have it with dithered sobol and AO Bounces, we only need a separate AO Bounces setting to aboud low AO Bounces values returning black glass, but that´s another story and I think it´s another feature, completely different, and that could require further development of course.
Cheers!
I’ll look at adding these to Cycles when I have time. Or maybe @lukasstockner97 wants to submit an updated patch.
I still miss clear comparisons to see the effect of scrambling distance and dithered sobol individually though, to see what the effect of each is, since they are very different things.
6 Likes
Ok, understood, separate testing.
The main effect for Dithered Sobol (apart from giving a less noisy effect, but that may be subjective) can be noticed with denoising, it avoids clouds with the denoiser since the noise is more evenly distributed, I´ll try to do some renders as soon as I can, I showed that in the videos, but I understand you don´t have time to watch them (I sincerely understand it… it gets 2 hours!!!)
Cheers!
EDIT: btw… THANKS!!!
1 Like
Fair enough
Well I actually currently use an old Theory build (scrambling distance, but no sobol dithering) and often I find myself trying to lower the distance value. Nothing bad happened so far. I’m rendering interiors, for animations I can’t tell so far.
Anyway: in my experience scrambling+sobol dithering (I tried a graphicall build) gave me a problem: I had a mirror in a scene that was very noticeably darker.
Scrambling distance alone is faster indeed, but only if set to very low values as in around 0.1. Otherwise it needs more and more samples, at the point that I can render with distance 1 anyway not feeling the need to “break the pathtracing paradigm”. What indeed I found it useful for is to set it veeery low for viewport performance.
As for the tests i saw here I don’t think they are good because they show pretty good results in both cases: let me see something clean with scrambling and noisy without, in the same rendertime! Last @AdamPreisler pictures for example: 3333 samples, 10+ hours vs 7+ hours, ok but how was the not-scrambling render after 7:30 hours? wasn’t it clean already anyway?
Finally, to make it clear: I’m not against this feature, but I kind of trust devs decisions. If this eventually lands in master I think it should be treated in some special way: maybe we need a new dedicated cycles panel for pathtracing hacks (along with ao bounces, clamping and the like)
Cornell box are not a good test case. We need comparisons in real production scene
LOL… You mean like an archviz scene with 1 light source?
No, he meant that cornell box is not a good test scene. It does not in any way represent complexity of an average scene.
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.
errata corrige: the darkening was because i tested with too much scrambling.
So, my fault: sobol dithering alone doesn’t give me artifacts.
Can someone drop me the link to the blender for windows that have this? and i will test this on some production sceens and will post all the data. i wish it would be linux. but i understand tht this is now windows only. however i have one system on windows so i can do test there.