Support for Ambient Occlusion maps

[dgovil]

I would like to propose the addition of support for ambient occlusion (AO) texture maps, so that OpenPBR may be used in real-time rasterizer contexts. AO maps are very common in these scenarios, but however are not common for path tracers. Therefore this should probably be allowed to be optional, with language suggesting how it can be used.

This would greatly reduce one of the primary friction points for adopting OpenPBR in a realtime context, especially very performance constrained scenarios where SSAO or path-traced results aren't possible.

[jstone-lucasfilm]

On the subject of ambient occlusion in OpenPBR, it seems worthwhile to reference this earlier discussion of ambient occlusion in MaterialX, which may provide useful context here as well:

Ambient occlusion in MaterialX

• At the moment, shading models such as glTF PBR have dedicated inputs for ambient occlusion, but they will have no effect on reference renders in UsdView or MaterialXView.
• This is because the visual effect of ambient occlusion is traditionally restricted to indirect lighting components, and this falls outside of the expression of MaterialX and languages such as OSL and MDL.
• It's been suggested that MaterialX could provide a dedicated input for ambient occlusion signals, for example in the surfacematerial node, and each renderer would be free to interpret it in an appropriate way (or even ignore it entirely).

https://academysoftwarefdn.slack.com/archives/C0230LWBE2X/p1694545789256329

[hybridherbst]

I would also like to see more emphasis on real-time use cases such as Ambient Occlusion to avoid fragmentation of the ecosystem by omission of industry-standard realtime features.