You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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).
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.
The text was updated successfully, but these errors were encountered: