first of all, big thanks for pushing AO node to master so fast. I’ve been waiting for this feature for years, and now it’s finally there, in the official branch!
I’ve already posted some feedback about it in BA thread, even before it got to master, so I am putting the same feedback here as well, since it’s probably a bit more visible here.
Basically, the AO node already works very well, but still needs a few features and tweaks to be production ready. I hope these minor things can be done soon so that the AO node doesn’t end up forgotten in half-finished state like ShadowCatcher did.
First of all, Defaults:
Default amount of AO samples should be 16, rather than 8. There is still a big accuracy difference between 8 and 16 when using AO map to drive procedural material effects, but there’s not much more beyond 16.
Given what kind of effect will AO map be used for, I think it would make sense to make “Only local” parameter off by default. Most of the time, it will be used for example for some grunge on the bottom of a concrete building around the proximity of sidewalk surface, and on that sidewalk surface along the proximity of the building wall. Those will likely be two separate objects. My point is that the amount of cases where you’ll want it to have enabled will likely be a lot lower than the amount of those when you’d want to have it disabled.
This is a big one. Given the primary use case of AO map, to drive procedural material effects (since path tracers don’t need AO map to enhance low detail GI), it makes absolutely no sense to default AO color to 0.8. Users naturally expect it to output 0-1 range by default. This leaves a HUGE room for error, because:
A. Given that default color appears pretty bright, users will likely assume the color in there is 1.0 white, not 0.8 gray, and then wonder why is the product of AO map behaving oddly, especially when color corrected.
B. Even experienced users will have to edit the color for every newly created AO map, it’s just a bad default.
C. Even when you are aware of this giant room for error, you still may occasionally forget to fix it, and then waste a lot of time troubleshooting what’s wrong with the AO output.
Little offtopic: This problem is prominent also in other parts of Blender, like Glossy BSDF. Given that glossy materials are usually masked by fresnel node, defaulting reflectivity to 0.8 instead of 1.0 harms physical accuracy a lot. Most users, especially new ones, aren’t aware of it anyway, leading them to almost always produce materials of lower reflectivity than what real materials usually reflect. Overall, defaulting to 0.8 in Cycles’ shaders is a really, really bad idea. Reflective and refractive shaders should default to 1.0 white, and diffuse shaders to 0.5 gray. 0.8 default for diffuse Albedo is extreme. 0.8 is often used as a ceiling for diffuse reflectance values in most physical renderers, as very high albedo usually hurts both performance and realism.
AO map features:
It makes very little sense to allow users to change unoccluded color, but disallow to change occluded color. This feels extremely arbitrary. Either the AO map is intended to output scalar, which you can use in for example Mix RGB, and use it to map two colors, or it outputs actual colors, in that case, you should be able to set up both of them, not one. Having just one of the two colors available is quite confusing. Either both of them, or none.
I’d like to request one more feature - cone angle. Basically at the moment, AO rays are emitted from a hemisphere. This parameter would be able to “compress” a hemisphere into a narrower cone. I hope the poor drawing below will be able explain what I mean:
The reason we need is to be able to exclude some parts of the mesh, especially lower resolution curved surfaces from the procedural effects. It’s often desired to see these scratches or dust accumulated only on surfaces of certain degree of convexity or concavity. Having this cone angle parameter will basically allow us to define surface angle for the effects to occur. Here’s a rendered example:
For both the reasoning is that this node has a big impact on performance, and so we avoid settings the more expensive settings because users would leave them on even if not needed.
I’ll change the default to 1.0.
I wouldn’t be opposed to adding a second color, we need the current one for backwards compatibility.
I have to strongly disagree here. The benefits do not outweigh the drawbacks:
1, If “Only Local”, which is somewhat confusingly named setting in the first place, is enabled by the default, then users may spend a substantial amount of time figuring out why the hell is not their procedural material effect showing correctly at places. In every other mainstream renderer, such setting is disabled by default. There are certain preconceptions about how an AO map should work out of the box, and these should not be messed with.
2, I can’t agree with performance either. Here is GIF of various AO samples settings and their impact on procedural shading effect:
You can clearly see that visual difference between 8 and 16 samples is significant, while visual difference above 16 samples is negligible. At the same time, 16 AO samples add only fraction of rendertime compared to 8. It’s just a better default.
It’s important to remember that this map will be mainly used for procedural shading effects, not AO pass. Those are not necessary with path tracers anymore.
As for the performance penalty of “Only Local” option, yes there is indeed one. Actually, it seems that AO map is significantly slower if the “Only Local” option is Enabled
So we have a default which out of the box produces worse, less desirable results and at the same time is slower. I know poor defaults are kind of Blender’s mantra, but at least here, it would be good to make some exception
I’m thinking about performance in bigger production scenes, where it will make a significant difference.
With animation having Only Local off is also problematic. For example you don’t want to dynamically create rust on the floor when the character is walking on it.
But we can change the default to only local off and 16 samples, it’s a trade-off anyway.
The thing is, I’ve used this procedural approach to shading almost daily for past few years, and the amount of times I had to make the effect local only was minuscule. Yes, it’s useful sometimes for exactly the reason you say, but the default should accommodate for the most common scenario.
Hi, so I’ve been trying to utilize the new AO node for procedural shading, and I’ve stumbled upon a roadblock. There still appears to be some weirdness in how Cycles AO node handles distribution. It feels as if the cone from which AO rays are traced wasn’t spread full 180° because Cycles’ AO node seems to skip quite a lot of detail, especially in “Inside” mode compared to Corona. Here are the results of two indentically set up scenes:
First is Cycles, second one is Corona. Same radius, same color correction after the AO node. The ray distribution of Cycles AO is just odd and skips lots of important details. Increasing radius further is unfortunately not possible, as they start to hit the other side of the wall on thinner areas.
