Hello, apologies for the potentially "google-able" question.
I'm struggling to understand why AO needs to be it's own map in modern renderers. Is it only relevant for baked lighting in Unity/UE? I know many stylized games or mobile games simply bake this information into the diffuse. Why do platforms with extra processing power opt to keep it separate?
Replies
The occlusion is kept separate because it should not affect direct lighting, which is any lighting that comes from strong light sources, for example the sun, a flashlight, etc.
Raytracers calculate occlusion automatically, as part of global illumination and light bounces. So the ambient occlusion map is typically ignored by them.
In most rasterizers that support physically based rendering (PBR) the occlusion texture is packed along with two other grayscale textures (roughness and metalness) into a single bitmap, using the R G and B channels. This keeps the material efficient for downloading and for memory usage during rendering.
So it’s really pretty cheap to include. And it does make a visual difference.
the lighting solution can only work with geometry so any extra surface information you're adding with textures can't be properly represented.
That's not quite how the renderering pipelines of game engine evolve or get used. It doesn't matter *one bit* if this or that feature gets added (for instance, a renderer having some way to simulate the occlusion of light in crevices) - this is just and always will be a tool in a toolset.
Even using an engine with the best-of-the-best implementation of realtime AO ever doesn't mean that there can't be benefits in having it also as a texture pass, or even as some of it baked in the diffuse texture. Especially since dirt gathers in cracks ... exactly like an AO pass.
Just because these 3 things (realtime AO, AO stored as a texture pass, and AO hard-painted into the color pass) are using the same acronym "AO", doesn't mean that one replaces the other.
It's always the same issue of people taking the name of something technical at face value as opposed to actually experimenting with it and using it for what it is. And that's why it's so important for a team to have experienced artists who are willing to push back against the sometimes dogmatic decisions of techart.
You're of the good kind !
Epic themselves generally suggest using AO textures for small cavities and letting SSAO/SSGI/Lumen/DFAO do their jobs.
AO being baked into textures isn't necessarily a bad thing, it can simulate dirt and grime even if you're getting AO elsewhere.
Often times with textures you got albedo and normal that need to be their own textures, then roughness that can be channel packed, metallic for some textures, and then a left over spot that could be something like AO, a mask, or emissive. AO is just an easy thing to default to.
But I think we’re talking about real-time rendering here, which is all about shortcuts, like using baked occlusion, and deciding how you want to mix it in your shader. At which point you can decide you want to mix it into diffuse or not.
BTW you can also use baked AO for specular occlusion, which helps with real-time rendering for metals and occluding self-reflections.
https://docs.unrealengine.com/5.0/en-US/bent-normal-maps-in-unreal-engine/
Baking specular occlusion into a texture is the same as baking ambient occlusion into a texture - you do it so you can insert information that doesn't exist in your meshes into the lighting system.
The bent normal stuff is about manipulating the surface normals used for indirect lighting. Bent normals can reduce unwanted specular highlighting but that's because it prevents the specular highlighting being there in the first place rather than occlusing it after the fact.
It's not unusual to lump specular occlusion in to the same pass as ambient occlusion (I believe UE4 does it) as it generally gives good enough results
We create our 3D scans with a cross polarized setup, which creates textures with essentially the real Albedo color values of the scanned object.
Even with all UE5 features turned on (except hardware raytracing features, which is prohibitively expensive for realtime rendering atm) the assets with their real Albedo colors often look rather "boring" / flat.
Turning off static lighting in the project settings helps, since only then the Ambient Occlusion channel actually has a proper effect in UE5.
Still, I end up multiplying the AO into the Albedo texture, at least at a low opacity, in my material.
In a way I'm glad that it looks like I'm not the only one doing this. Since it's sacrificing some realism for the sake of a subjectively nicer looking scene.
All that said, this isn't something you should consider applying or varying on a per-asset level. Art and technical direction should dictate how or if AO maps are used in the shading pipeline.
It's the best way we have to handle mouth interiors/nostrils etc with current lighting setups and since cinematics sell games the character artists get to have all the fun toys
It's still one extra RGB texture . Not for characters but I use specular scalar black&white channel plus a bit of AO in albedo too and IMO it works no worse visually. Or texture reads are no more an issue for modern games?