For me it works if I insert a color ramp node between the checker and the ao node and set the black value to something slightly above 0,0,0.
Maybe it’s an optimization that ignores the AO shader with a distance of zero?
Interesting, I tested the CPU renderbug (from 4 posts above) on my old machine and it works fine there too. So it’s definitely a hardware/OS specific bug. Anyone with Win 10 or a similar CPU (Intel Core i7-5820K) here?
My old Computer:
Intel Core i7 CPU 920 @2.67GHz
Windows 7 64bit Home
Btw: In the Testbuild from Lukas it worked fine on my system. So it’s something that got introduced with the changes to master.
Yup, all fine here.
CPU Intel X5650, with 2.8 and 2.79 daily (18.06.2018), on w7sp1 x64 pro
Where’s scrambling distance @lukasstockner97 eh eh we all know it can speed up renders by 30% or more on gpu. Allowing near real time toon effects and 0 noise renders. We need scrambling why isn’t it here 
6 Likes
Aha. You’re right. There is an optimisation which skips nodes with zero influence but I thought that it only worked with values and not textures. This would mean that it would skip any property driven by texture with pure black. I think I’ll make a bug report then.
I noticed that the AO BSDF is no longer available, and this node output does not contain a BSDF socket. are old scenes now not compatible if they used the AO node?
I believe the versioning will automatically insert an emission shader between the AO and the output. But there’s only one fun way to find out…
Yep, it works fine, this file was created with 2.79 and opened in 2.8 The color from the AO node plugs directly into the green socket and is converted to emission in the background
Note that this now works with all sorts of color to shader sockets. This is a great gain in ease of use and paves the way to some nice Node-Wrangler like features.
1 Like
I just tried the new AO node and it is fantastic. Thank you, Lukas, for this important feature.
Just to go sure, it is not yet fully supported by EEVEE, right?
I plugged a noise texture into the distance input of the AO node and it works perfectly in Cycles but goes back to the default AO in EEVEE. Is that correct or am I doing something wroing?
Implicit conversion of color to pure emission of 1.0 output is great. It also implicitly converts the float sockets as well.
Excellent! No more constantly adding an emission node to test outputs.
Correct, it is not currently fully supported in eevee
1 Like
Believe it or not, the work that @lukasstockner97 is doing on this front is some of the most important work going in to Blender.
Currently, Cycles is not colour managed in any way, nor is Eevee. Lukas’ effort is working towards this goal. This facet essentially locks both rendering engines out of contemporary content generation including HDR, typical 2012+ household televisions, all 2016+ Apple products, a good number of Android based cellular phones, and a sizable chunk of current generation computer displays coming to market.
It is an absolutely huge facet he is working on.
8 Likes
Yes, it is buggy. You can see it in the video I’ve made: https://www.youtube.com/watch?v=skZrCFsnjDI
Brecht committed a fix yesterday for my bug report here https://developer.blender.org/T55528
So it should be in today’s build. I will check in the evening
Had the render artifacts with the AO-Node on another computer. Of four tested machines, two had the bug. Filed a bug report here https://developer.blender.org/T55563
In case people don’t look at the bug report link:
This problem occurs only on Windows with VS2013 builds on CPUs that support AVX2. For now, just download a “new compiler” build from the buildbot and it should work.
Why does this bug exists only in VS2013 build?
maybe i’m wrong but i do remind reading something about “updating” the build bot for windows so that the old builds can be removed.
( i assume most devs use vs2017 on windows, 2013 is quite aged).
I always wondered why there where 2 builds, and thought maybe the new one isnt guaranteed to work or so, but now there is proof that the newer builds are better then the 2013 option.
It’s most likely a compiler bug in msvc (we have ran into this before) that got fixed in newer msvc verisons. we’re pretty close to dropping 2013 support anyhow, so this it just one more nail in its coffin.
1 Like
Surely the developers will be aware of the release of this document…
http://www.iliyan.com/publications/ProjectedSphericalCaps
3 Likes