DaemonEngine / Daemon

The Dæmon game engine. With some bits of ioq3 and XreaL.
https://unvanquished.net
BSD 3-Clause "New" or "Revised" License
296 stars 60 forks source link

SSAO displayed above fog from behind wall #537

Open illwieckz opened 2 years ago

illwieckz commented 2 years ago

On this screenshot (hangar28 map), there is a fog between the player's eyes and the wall, though, the SSAO dark corner is visible.

ssao above fog from behind wall

I noticed SSAO is not done on skybox textures, so maybe we can exclude such surface as well.

For a start, we must check if SSAO is drawn on surfaces with nolightmap, I guess it must not.

illwieckz commented 2 years ago

We may think about doing SSAO before fogging, but maybe just making sure SSAO is not drawn on nolightmap surfaces if such surfaces are using nolightmap may be enough.

illwieckz commented 2 years ago

I confirm this surface has nolightmap, so SSAO should not be painted. I've verified the SSAO GLSL code has exception for skyboxes, but not for nolightmap surfaces.

illwieckz commented 2 years ago

In GLSL code, the skybox check is done by reading the depth map and testing if the depth is at its maximum, the same method can't be done for nolightmap.

slipher commented 2 years ago

I think "screen-space" means that it is a post-processing effect operating on the entire screen at once, so there is no operation on individual textures.

illwieckz commented 2 years ago

Yes, and it looks like skybox pixels are detected by testing if current pixel in depth map has maximum, so to exclude nolightmap surface from SSAO we would have to do a special map, that looks uselessly costly, or maybe there is a way to hack the depth map, but I'm not sure there is some remaining channel to store extra data in.

slipher commented 2 years ago

I was wondering if SSAO even makes sense in a game with pre-computed lightmaps. Probably most of the recessed areas it detects would be the interaction map geometry with itself, which could be found at light-mapping time. Or areas within models themselves, which the modeler should account for himself to make sure it looks good with naive lighting.

https://vr.arvilab.com/blog/ambient-occlusion suggests that it is still useful because lightmaps may be too low-resolution compared to the map geometry.

illwieckz commented 1 year ago

What SSAO is useful for is for angles between models and the map, even if SSAO like dirtmapping is physically wrong (or not that right), it can really help the mind to not falsely believe the model is floating above the floor by clearly showing there is an angle between the world surface and the model surface and that those two surfaces make a contact.

VReaperV commented 1 month ago

Since global fog is done over SSAO, I'm assuming this refers to quake3 fog.

I think we can just move that fog into a separate stage rendered with shaderSort_t::SS_ENVIRONMENT_NOFOG and shaderSort_t::SS_POST_PROCESS, which is done after SSAO.

VReaperV commented 1 month ago

Also the issue description seems to have an incorrect image linked (it's not hangar28 and I don't see pretty much anything in it).