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
Yes, we discussed both approaches, but at the end decided to implement it as a post-process (with the mentioned limitation) as a more performant solution. In this case, the scene is rendered, and its depth buffer is used to generates ssao, which is then blended into the scene.
The better solution, which we might do at some point in the future, renders the scene into depth buffer first. Then using this depth texture it generates ssao texture (this is the same step as the current implementation does). Then the whole scene is rendered again, while the ssao texture is used during the lighting computation. The extra cost here is having to re-render the scene one more time to have access to its depth before the scene with lighting is rendered.
The post process AO added in #3266 is much needed. However, it naively multiplies the AO with the final image (
gl_FragColor.rgb = inCol.rgb * ssao;
)This is a problem when using realtime lights, since lit and shadowed areas are darkened equally by the AO:
![SSAO](https://user-images.githubusercontent.com/56446466/201687516-27b80e35-12ed-49ef-aaf6-83c21726a441.jpg)
Compare this to using baked AO textures in the ambient slot (in which lighting is calculated correctly):
![BakedAO](https://user-images.githubusercontent.com/56446466/201687521-a84ae6ed-413b-4a3a-beed-ba062ab463f1.jpg)
SSAO should behave the same way AO textures do. The current behavior produces results that look "dirty".
The text was updated successfully, but these errors were encountered: