I create the CHALK STYLE PRO addon, which creates wireframe renders with AO.
It throws an error in 2.83 but runs fine in 2.82. This is because the Ambient Occlusion menu item isn’t available as shown in the screens below.
In order for it to work, AO has to be turned ON in the EEVEE settings. Is this a bug, or should I code around it?
Wasn’t this effectively the same in 2.82? In that version, even though the AO pass showed up, it would be entirely black/empty if Ambient Occlusion was not also enabled in the settings.
The Bloom pass works the same way now; it will not show up unless it’s actually enabled in settings.
No, in 2.82 it worked fine even if AO was turned off in EEVEE.
I mean, how could there be an AO pass if you tell eevee to not do AO? Here’s what I see in 2.82:
2.82 without AO for eevee settings:
In any case, render passes aren’t free, so I don’t believe they’re available unless the option is enabled. The initial commit for them listed GPU memory concerns for instance: https://lists.blender.org/pipermail/bf-blender-cvs/2020-February/136094.html
If it’s not a bug then a setting that disappears from Menu A if a different setting in an entirely disconnected Menu B in a different part of the interface is off is a poor UX design. All options should be present in Menu A; if they’re blocked from being used for some reason (due to settings in Menu B) then they should be present but greyed out rather than removed so the user is at least aware of their existence and that something is blocking their use.
A grey option allows the user to begin the inquiry “Hey, what is blocking this?” This is discoverability in action. Completely remove the option and the user won’t even realize that there is an option for them to discover or any inquiry to be made in the first place. In order for them to understand that something is missing from Menu A requires that the user already has knowledge of Menu B and the state of its settings.
Sure, I’d agree to that. But it’s off topic for the problem / question in this thread. The problem / question would’ve still been asked: “Why wasn’t it grayed out in 2.82 but is grayed out in 2.83; do i need to work around it?”
Yes, I see you are correct. But, when I:
bpy.context.space_data.shading.render_pass = 'AO'
then:
bpy.ops.render.opengl(write_still=True, view_context=True)
I get the following image in 2.82:
even with AO set to false:
bpy.context.scene.eevee.use_gtao = False
so, is it a bug and if so, who’s bug is it? 82 or 83?
@JeroenBakker, I think ideally the AO pass always works regardless if AO is enabled in the render properties. Not sure if there was an intentional change here.
This could be added back.
When the AO pass is enabled it influence the light and combined pass even when not enabled as a scene setting. The reason is that the AO pass will be used during the surface shading. Doesn’t seem difficult to add some logic there to not use the AO pass in this case.
You could follow https://developer.blender.org/T77267 for the progres.
