SSAO discussion

[Nash]

Nothing in the sky and clouds are affected by the SSAO pass. I'm happy. ;)

would you mind sharing this build?

It's just one post above mine! :P

[dpJudas]

You're probably aware of all of these... or maybe you don't see them on your computer; I won't know. But yeah, this is what it looks like on my system and what I noticed.

Hehe, I was wondering when someone would start noticing those things. My thoughts:

flickering in corners - This may be an indication that the blur isn't doing its part. I only really notice this one with the debug mode on, but generally it is to be expected that individual pixels may get wrong values due to the way it samples data. SSAO works by grabbing some pixels near the pixel being shaded and then look if their depth values are close or far away. The closer they are, the more the pass assume that they occlude the light. For speed reasons it can't afford to do too many such tests (32 per pixel right now), which means that there may be "false positives" and such. The blur is supposed to even this out.

small box far away casting shadows / aura around some things - I'm not sure sure if this is due to an error in the distance check, or the box is still close enough to affect the pixel. The ssao_radius cvar controls how far away something must be for it to not occlude. One of the limitations of screen space algorithms is that it can only sample from pixels visible by the camera. The aura may be an artifact of this fact, which means if that's the case you should see that in any commercial game too. It may be a bit harder to spot there tho, because they tend to use much more complicated geometry and things to distract you with.

shadows cut off in corner of screen - This is because the scene texture ends at the edges. That means it has nothing to sample from, and thus no data to use for occlusion. The solution is to render a scene slightly larger than the screen, but due to other parts of gzdoom today I don't think its easy to achieve. I can personally live with this artifact knowing what work it entails to do something about it.

Heck, these might even be what's happening in commercial games and I probably just don't notice them enough.

You'd be surprised what the eye stops noticing once action is going on.

[AFADoomer]

This is great work! I tweaked the gl_ssao_strength cvar down to 0.3 to make the effect more subtle, and it works really well on my Star Trek TC's ship-board map.

The corner flickering is especially noticeable if the wall texture is a light color... If you look at it with no pitch on the view (and are looking directly into the corner), it's actually a straight line right at the point of the corner.

Another thing that I've noticed with the "small box" situation (and with 3d models) is that the shadows are always cast in the shape of the wall/crate/model/etc. as viewed from the player's viewpoint, regardless of what light is 'casting' the shadow. So if I'm standing beside a model of a chair, all of the shadows are in the shape of a side view of the chair, but as I walk around the chair, all of the cast shadow's shapes change to match the current view of the chair as I move, and the shadows move around the object as I move, as if the lights casting the shadow were statically fixed in relation to the player's position.

I'm assuming this is either a limitation of the solution, or just hasn't been addressed, yet, but on some levels, the effect can be kind of jarring once you notice it (of course, as you said, you'd be surprised at what the eye stops noticing...).

[Nash]

Another thing that I've noticed with the "small box" situation (and with 3d models) is that the shadows are always cast in the shape of the wall/crate/model/etc. as viewed from the player's viewpoint, regardless of what light is 'casting' the shadow. So if I'm standing beside a model of a chair, all of the shadows are in the shape of a side view of the chair, but as I walk around the chair, all of the cast shadow's shapes change to match the current view of the chair as I move, and the shadows move around the object as I move, as if the lights casting the shadow were statically fixed in relation to the player's position.

That happens in commercial games too. I think that's where the "screen space" in the name came from. It's just fake ambient occlusion that approximates it based on what you see on the screen. It also results in hilarious "outlines" around characters and objects, making them look cartoony. :P

Real ambient occlusion would be far more complicated, requires more lights to be setup and would probably have to be baked... or be very heavy to simulate in real-time (I haven't seen a game engine do real AO/radiosity fast enough yet)...

[Nash]

dpJudas: Quick question, if I'd just like to merge your AO features into my GZDoom-derived fork, for play-around-purposes... is the "lightmath" branch the correct branch to merge from? Or is there another branch that I should pull from?

[dpJudas]

It is the correct branch, although I'm not sure so sure it was a wise idea of mine to do the SSAO in the same branch as the point light math. Still trying to figure out if I should recreate it in a new branch or not. If I do, I have no idea how git reacts if you pull the current SSAO branch into yours. Maybe keep it on a test branch in your fork?

[dpJudas]

I've managed to track down and fix the main cause of the artifacts: the random texture sampling wasn't working properly. Same for the blur. Here's the binaries with those fixes included:

https://github.com/dpjudas/zdoom/releases/tag/ssao4

At this point I pretty much consider the SSAO pass code complete. Unless someone spots some issue with the portal handling I think this is done.

[Nash]

Here comes some bug reports. ;D





SSAO is being drawn on top of fog... (screenshots from Hexen MAP08)



Weapon model doesn't have SSAO. Mod is Enjay's Gene-Tech (model-heavy project, all weapons and monsters are in 3D, really cool to see the models interact with the SSAO)



Some bugs in Arooka's portal demo:

1) The seam is visible in the circled area
2) MASSIVE FPS drop when standing at a certain position while looking at the portal (download save game made for ssao4 branch x64 version). Turning off SSAO restores my frame rate, turning it on gives me 30 FPS. Bloom, lens distortion and 8x AA is also turned on.

Still trying to figure out if I should recreate it in a new branch or not.

In my opinion, a branch only for SSAO, and a branch only for advanced dynamic lights makes more sense. I guess it's not that it TRULY matters much since this is all very WIP stuff and not meant for public consumption, but there'd be no issues on my end if they were separate. My 2 cents. :)

Oh and good job with the fixes in ssao4. Running around in Doom E2M2 shows a MASSIVE improvement in the SSAO quality... the shadows are smooooth and aren't distracting anymore. Doesn't look anything like in the video I put up yesterday. Thumbs up!

[dpJudas]

fog + ssao: yes, that doesn't look good. Need to think a bit what to do about that.

no weapon ssao: this is expected behavior. The way gzdoom prevents weapon collision with the world unfortunately means that it can't do ssao on it without a full additional pass. That is a bit too expensive just for the weapon.

portal seam: it is expected that there would be some cases where you could see where the portal is. Showing it with ssao_debug on of course makes it really visible, but the real question is how much players will notice during normal play. A normal screenshot of that place would have made it easier to judge how bad it is.

massive fps drop: what is your normal frame rate with the ssao pass enabled? Right now it will do a full ssao pass for every portal rendered, which may be too expensive. Unfortunately the only solution to this is to not do ssao on some portals - i.e. only do ssao on the closest portal.

[AFADoomer]

Mirroring the praise in Nash's post... This is gorgeous! I reset the cvars to default, and everything looks great in-game!

How are particles handled by the SSAO code?? I have a starfield effect in one map, and with SSAO turned on, the particles disappear... But if I place the same effect on a brighter map, everything looks fine.

I also am seeing significant framerate drops when portals are in line of sight (sector portals in my case, vs. line portals in his case). I go from ~65 FPS to ~35 at low resolutions, but if I bump my screen resolution up to max, I go from ~25-35 FPS to 6 FPS!

Unfortunately, if you want to test with my mod, you'll have to download the whole 90MB file (https://github.com/AFADoomer/baseTrekpk ... d/Trek.pk7)... Start a new game, 'warp 6200 1600 -1200' for several stacked-sector-style portals, or 'map titlemap' for the particle issue...

[Nash]

No weapon SSAO: Understandable. Perhaps if a full project really needs it, a user option to enable the second pass for the weapon could be added (and with warnings that enabling this pass will really drain your FPS) but at this rate, not many projects have full 3D models yet so I guess no need to put in any work here.

LINK

Portal seam: I can notice it even with textures on. BUT, again as above - not many projects use portals this way (and linedef portals are a very, VERY new feature) so... I guess unless someone really nags about it; no need to invest anything more here too? :P

Massive FPS drop: 60 FPS usually in stock or "normal" Doom maps/projects with all post processing except tonemap enabled. Perfectly playable sessions and any slowns to occur (even if there were any) have nothing to do with post processing but rather mapping issues or mods spawning too many actors as part of their special FX or whatever. It's just that portal demo that drops my FPS to 30'ish, and only in that specific spot I was standing on.

All in all, In my opinion, the only things I'd consider "important" are the fog issue and probably the portal FPS drop but again, not many projects use linedef portals extensively yet, and my report is based solely on a mapping example file, so I don't know. :P

GZDoom is almost there to looking just as good as the Doomsday engine! =D Thanks so much for these effects.

Oh and something interesting I just saw:



Map is abbuw's city map. Although you probably can't do anything about this because the skybox is a considered a "physical" sector. I'll suggest the author to switch to real GLDEF skyboxes.

EDIT: Photo-dump of said map. Some of these shots look near-photorealistic, IMO. Simply blowing my mind right now. :O

[dpJudas]

How are particles handled by the SSAO code?? I have a starfield effect in one map, and with SSAO turned on, the particles disappear... But if I place the same effect on a brighter map, everything looks fine.

First the opaque parts of a scene is rendered. Then SSAO is drawn on top of it. Then translucent parts are rendered. Particles are part of the translucent part, which means SSAO shouldn't affect them at all. I'll have to take a closer look to figure what could be causing this.

Portal seam: I can notice it even with textures on.

It is visible, but I don't think it is catastrophic. In fact, the level-of-detail model switching in Battlefield Bad Company 2 was much much worse (entire models just swapped in front of your eyes from one frame to another), and everybody praised how good looking that game was. I'll file this one under acceptable artifact for now.

60 FPS usually in stock or "normal" Doom maps/projects with all post processing except tonemap enabled.

Sorry, should have been more clear that I meant with vsync off. If the scene suddenly can only do 55 fps then that'd drop down to 30 fps with vsync on. AFADoomer gave me a good idea of what kind of FPS drop we're talking about though. I'll try some of the ideas I have for improving the portal performance - it was a bit too naive of me to just assume the GPU could handle the overhead of a brute force solution.

GZDoom is almost there to looking just as good as the Doomsday engine! =D Thanks so much for these effects.

You're welcome! We'll get past the Doomsday engine soon enough - you'll see.

[Tormentor667]

It is getting better and better, but I still have issues with skybox sectgors:


Another thing I noticed: Sound isn't working anymore with the SSAO builds.

Beyond in snowy bright maps I find the bloom effect not really usable. Can it be somehow altered that if the majority of the screen is very bright, the bloom effect gets lowered so the surrounding areas are visible again and not overblindingly bright?

Bloom on

Bloom off

[Nash]

SSAO looks nice with 3D foliage, too.

Okay, sorry for the image spam. Just having a blast playing with this. XD No more from me for the time being.

[Graf Zahl]

I believe it's absolutely necessary to implement some means to selectively exclude things from the SSAO pass.