Need more information.
Description
Description
Related Objects
Related Objects
Event Timeline
I did some tests with this but found there to be no way we could enable this by default, since it simply does not converge fast enough to the correct results even with low values. This is probably just the wrong approach to the problem, and we need to look more at sample ordering, sorting or increasing occupancy with a split kernel.
Thanks for testing it.
Can you elaborate a bit please?
This project was fully rendered with scramble distance and dithered sobol, we never use one without the other:
And the times were reduced nearly to a 50%, and the amount of samples was also reduced since there was less perceived noise.
May be something that works better with dithered sobol? like Adaptive Sampling uses progressive multijitter.
BTW another question regarding this, at what values have you tested?
The speed of convergence was different depending on the scramble distance value you used, usually with standard scenes or animation we use from 0.2 to 0.5, it accelerates quite a bit but the difference between those and pure cycles in results at lower samples is not big.
For scenes where we want a big speed up and it's going to be a single image, we could use even up to 0.02, the difference is bigger, but since there is no animation involved at some samples the glitches it may generate are not perceived anymore, and it's way faster than without SD enabled.
BTW SD is never enabled by default, it's an advanced option for the user, so you know you introduce some bias while accelerate the render.
And let me stress this out, we never use it without Dithered Sobol, the results are not comparable.
Anyways, if you think there is a better alternative to accelerate cycles quite a lot, but at the same time retain a perfect result, and this means we cannot get SD, I'm all in favour of it, but if it means waiting another 2 to 3 years, then it makes no sense.
As artists/users we need results now, our clients asks us to be on pair with our competition or they simply stop being our clients, and the speed up is something totally required, no matter if it comes in form of Scramble Distance, GI Cache or any other technique, but it does not matter if we are talking about 2.90, because we've been waiting a long time for some cycles optimizations, and you know why I'm so worried about this because I told you in some conversations.
This feature has sometimes been shown to be useful and has even been used for production. But it is also true that this should be used by people who know what they are doing and who know the limitations of the feature. Would people be happy if "scrambling distance and dithered sobol" is added and maintained at least as an experimental feature?
Just to clarify @Brecht Van Lommel (brecht) when you mention sorting for split kernels, you mean accumulating samples and sorting them to better feed shaders/kernels for SIMD/occupancy for stuff like incoherent/GI rays? Something I'm interested in also that wouldn't introduce bias afaik if done right.
I have a branch, but I imagine I can extract a patch.
The branch with Cycles modifications, that are basically lightgroups, dithered sobol, scramble distance and the modification of some sampling variables to push a bit more the gpu's, is this one:
https://github.com/juangea/boneMaster/tree/bone-cycles_290
I just add my git as an additional remote over the blender repo, so nothing weird to get it, I imagine it could be faster for you to just pick the branch, because I'm a bit slow with all the patch-management thing.
I just updated it, so it's based on today's master.
If you still want me to try to extract the patch tell me and I'll try to do my best.