Many models missing AO channel
elalish opened this issue · 9 comments
Some examples: https://modelviewer.dev/fidelity/#khronos-SheenCloth, https://modelviewer.dev/fidelity/#khronos-2CylinderEngine, https://modelviewer.dev/fidelity/#khronos-BrainStem
When comparing to path-traced renderers, which we should always be doing, it's not really a fair comparison if the model hasn't had its AO channel properly baked, as this extra data is required to help rasterizers achieve realistic results. This is a common enough problem in the glTF ecosystem - we should not encourage the idea that it's somehow optional for PBR models.
This issue really only applies to SheenCloth as 2CylinderEngine is not in the new repo and BrainStem was converted and is not up to the usual license standards.
@elalish : Can this topic be opened as an issue on Sample Assets for just SheenCloth?
If there is no response to this comment by 27 Nov, then this issue will be closed.
That looks like fabric-level AO, which I'm not sure is even necessary (would probably look the same baked into the baseColorTexture). AO is for geometry-level occlusion, so the dark parts in the folds. That is completely missing, and makes the rasterizers look terrible compared to the path tracers. I'm guessing it'll need a non-tiled UV map or something.
AO is for geometry-level occlusion, so the dark parts in the folds.
I'd have to disagree with this — there's no reason you can't or shouldn't bake AO with greater detail than your geometry. Similar to how we bake small concavities into normal maps and remove them from geometry.
Agreed with @elalish that baking AO without tiling would improve the visual result for SheenCloth.glb, though. Especially in a PBR showcase model, that's worth doing. For 2CylinderEngine.glb and BrainStem.glb, I have mixed feelings, one is animated and the other looks strongly as if it is meant to be animated or disassembled, for which baked AO would probably be the wrong approach, compared to SSAO or other techniques.
@elalish , @donmccurdy : Would it be sufficient to handle on SheenCloth as there are issues with the other two models?
This needs to be commented on with intended resolution by 1 Dec or it will be closed.
Yes, that works for me. Who contributed the original? Any chance their modeling program can bake out AO and re-export?
@PatrickRyanMS Can you comment on the SheenCloth AO?
I'd have to disagree with this — there's no reason you can't or shouldn't bake AO with greater detail than your geometry. Similar to how we bake small concavities into normal maps and remove them from geometry.
I agree with @donmccurdy in that there is value in having an AO channel with the texture as we never know with models that are shared how close a camera is placed to the model or if the user changes the tiling factor at all with a tiling texture. Having that detail AO can be a good thing.
That said, I don't see a way to mix the tiled AO from the authored material with an atlased AO baked from the mesh in glTF so one will have to win out. I can certainly bake an atlased AO from the mesh, but I also think it would be a great addition if the spec allowed us to be able to produce a mix of both AO contributions by multiplying the tiled AO with the atlased AO to produce the final AO. It seems that with tiling textures, having the ability to mix a second atlasted AO texture from mesh authored to a second UV set would give the best results by respecting both the mesh occlusion and any occlusion baked into the tiling texture set.
For example, the material below comes from the Adobe Substance 3D material library and is authored with AO:
If using this material as a tiling material in a glTF asset, we would lose that AO in favor of AO baked from the mesh if the material was used as a hot-swappable material for an asset with variants.
Here's the update KhronosGroup/glTF-Sample-Assets#81