I and @Ali_RS had a little talk about ao strength in gltf.
so what about the ao multiplier i remember it wasn’t straight like assigning metallic mult for example
mat.setparam(“metallic”,vartype.float,1f);
can it be done for ao too i can’t see ao too in def
also didn’t even notice about ao map multiplier.
Looks like gltf supports “strenght” factor for ao map. .
so does it need to implement in the shader below:
I think they are different, lightMap is usually used for baked lighting and can have color, but AO maps get read as a grayscale texture and are just used to simulate crevices on a model where less natural light reaches.
It seems like the PBR shader was written so they both can use the same texture because there would never be a good reason to use both together, since you might as well just combine the ambient occlusion lighting into the lightmap to do 1 texture read instead of 2.
But I’m pretty sure that this is how you would want to change the PBR shader to use AO strength, just multiply AOStrength by the final AO value right after its retrieved from the lightmap or metallicRoughnessMap texture reads.
vec3 ao = vec3(1.0);
#ifdef LIGHTMAP
// ...lightmap / ao code here...
#endif
#if defined(AO_PACKED_IN_MR_MAP) && defined(USE_PACKED_MR)
ao = aoRoughnessMetallicValue.rrr;
#endif
ao *= m_AoStrength;
And then I think that if anyone needs to scale their lightmaps, then a seperate m_LightMapStrength variable should be created to do that, since it is technically possible to use a LightMap while also using AmbientOcclusion if the AO value is coming from the packed MeatllicRoughness map.
Yeah I think this way is actually the right way to do it for a strength factor for AO, since a higher strength should mean that the dark parts of the AO map get darker, resulting in more intensity and contrast in the AO map.
The way I suggested with multiplication was wrong since it would just be a scale factor and would make the whole model brighter if > 1 and all darker if < 1, and that isn’t what you’d expect from an AO strength factor.
if ao is 1 and m_AoStrength is 2, then ao=max(ao,0.0) would give ao = 2, which doesn’t make sense. am i wrong?
this keeps ao between 0 and 1 for any value of m_AoStrength
pow is a common way to control contrast of image, is not much expensive tho, if we use power function correctly we won’t need use clamp since for any positive value of m_aostrenght ao will be 0-1
i mean how much difference there is between the dark and light areas of the ambient occlusion map a higher contrast means more visible shadows and creases on the model a lower contrast means more subtle and smooth shading on the model
the logic you use to scale the ambient occlusion effect can affect the contrast of the ao map ex, if you use a linear logic like this:
ao = 1.0 + m_AoStrength * (ao - 1.0);
then you are basically adding or subtracting a constant value from ao depending on m_AoStrength this will change the brightness of the ao map but not the contrast.
however, if you use a nonlinear logic like this:
ao = pow(ao, m_AoStrength);
then you are raising ao to a power depending on m_AoStrength this will change both the brightness and the contrast of the ao map
OR
i’m completely in a wrong understanding of situation…
IMO in most cases, adjusting the ambient occlusion from the code after the model is exported is unnecessary. However, if the specifications require it, we should support it as defined to better integrate with tools that expect a certain behavior from the exported models.