It’s okay to have an opinion, but it’s a different thing to continually try to make a general thread into one that’s about your opinion.
A new thread making the case for the scrambling feature can be made. Otherwise, it will bury any attempt to draw attention to the newest commits.
We probably wouldn’t use blender in our productions without scrambling and dithered sobol. It would be easier to just use redshift. Blender is losing out on potential studios using cycles because other render engines consider how expensive rendering is. TBH cycles is going to die if they don’t add rtx anyways. Octane Arnold and renderman have already have working results. Considering you can get nearly 100GB of vram with nvlink and quadros Cycles will be the new blender internal of the industry which is pretty funny considering I’m a cycles fanboy. I Constantly have to convince people not to switch to big name render engines. And I can easily convince them when I show them the results I can get with our build. But after I show them and convince them I have to tell them “eh well you can’t actually download blender and do this out of the box”
With rtx there is much more speed to gain and they should focus on getting that to work but still scrambling should be able to work with it giving an even bigger increase in performance
I too hope RTX support gets rolled into the mainstream application soon. I hear RTX support is workable but difficult/shotty at the moment.
I would purchase 4x RTX 2080 ti’s tomorrow if I knew NVLink was a real possibility.
PLEASE Blender devs, Focus on RTX + NVLink integration!
Unfortunately, the Blender Foundation has arguably been under-prioritizing overall performance and speed since the 2.3x series (which is when I started to use it 14 years ago). It hasn’t become a big deal until the 2.8 viewport recode and the dawn of Eevee. One also needs to keep in mind that from my experience, questionable and confusing priorities is more or less a trademark of FOSS in general (which is not as evident as it used to be, but it’s still there).
Onto the general issue of performance, considering where the tech. is headed, there could end up being a situation where Cycles and Eevee see the heavy cross-pollination of technologies or even a full-on merge (though the latter is unlikely unless Eevee can be relicensed under the Apache 2).
Now I would fully back your quest to see your favorite patches in master providing Lukas can solve the bias issues with more extreme values (which can take a very long time to clear up). Since your posts seem to indicate a claim of knowing more on how pathtracing should be done than Brecht and Lukas, why not submit a patch with the issues resolved?
I’m pretty sure than Brecht said during the developer stream at the conference that he was hoping to focus more on Cycles soon. I think it is frustrating when code is not committed which seems to be relatively simple such as the scrambling distance but the patch you linked to is easily applied. I’m guessing this is more of an issue if you are hoping to send files off to render farms etc. It should also be noted that P366 hasn’t actually been submitted for code review!
The only argument to not include it is that the user can introduce artifacts and get undesired results … what the hell? Then please remove 95% of the options because the user can fuck up there too.
Clamping, Samples, Caustics, Bounces, Pixel filter width … if the user just randomly changes stuff there he will get undesired results too, is this reason enough to remove those settings?
Blender is a software for professionals so don’t treat them like babys!
I know this is a stupid question in the midst of algorithms and patches and serious things, but -
Does anybody know where the cycles Render button has gone in 2.8? I can’t find it anywhere. 
It’s not there anymore, you have to go on the top “render” menu
Again, judgement based on your personal opinion… wise would be to just let it go, let decision makers make their choice.
@Blended_Blue
IMO, RTX platform as it is now, just looks too closed & too risky to invest in… too early, since all we’ve seen is a bubble. Already, all around, there are simply many, many problems rising just with it’s AI denoiser.
For starters, optimizing what is predictable & reliable appears a difficult task. ppl just get too biased, too soon. That is why i suggested “trial en mass” (get it in master, observe and decide) - since human by nature is also very unpredictable & unreliable (but vastly superior when using intelligence) - only real experience, life reveals the truth.
With elephants over Alps.
are there any tutorials/docs on how to use it available ?
You see if what I wrote here helps you at least to start:
Back on the subject of actual commits, Lukas Stockner has been returning to subjects related to denoising and you can now generate the passes without actually using the denoiser.
https://lists.blender.org/pipermail/bf-blender-cvs/2018-October/115572.html
It might seem useless at first glance, but this is actually a needed feature for animation denoising.
This goes hand in hand with the ability to have the original noisy image as a pass by default (so as to try to fix artifacts like black pixels in highlights using compositing nodes).
https://lists.blender.org/pipermail/bf-blender-cvs/2018-October/115512.html
Another thing Lukas worked on meanwhile is improving the result of the artifact-free bumpmapping committed earlier this year.
https://lists.blender.org/pipermail/bf-blender-cvs/2018-October/115489.html
Great!
thx Lukas!
lukas is in the fire mode!!!
many thanks
Lots of interesting topics, but I wonder is there something like lightcaching in the plans for cycles? Or is it considered forbidden technology?
IIRC, it was mentioned as planned, but i lost sight of it.
Thanks a lot, is not so easy to figure it out alone
I just read this interesting thread about microfacet roughness. I don’t know if this has already been discussed here, but it’d be great if this could be implemented in the Cycles Principled shader.
Yep it’s already been discussed. The principled shader already corrects for Fresnel Halo on rough glossy objects, but does so in a very different way to how the microfacet roughness appears to corrects for it.
I don’t think there are currently any plans to implement native microfacet roughness into any cycles shader though…it took us a while to actually convince a few people that the effects was even real 
The node group that fell out of the discussion you linked to is an artistic approximation and isn’t really based on any of the underlying maths in the papers that were linked in the thread.
And I was actually hoping this would be implemented in princibled shader by 2.8… Oh well…