xycaleth
New SSAO Algorithm
This is continuation of my previous failed experiments with AO. I rewrote ssao.glsl completely, it looks good IMO.
Issues:
- AO affects player models a bit. (TBH this is present in a lot of games, idk what to do with it) I like it very much anyway.
Video: https://www.youtube.com/watch?v=1tx_PHvTj0g
Screenshots:
r_ssao 0
r_ssao 1
Droideka best class (C)
What improvements does this have over the existing SSAO implementation?
I have a few issues with your implementation:
- I'm really not liking the black outline that this implementation gives around everything. This is really noticeable around the sides of the ship in the lighter textured map.
- it just looks like the image is made darker when ever there is a depth discontinuity, regardless of whether the object is already lit or not.
What improvements does this have over the existing SSAO implementation?
It looks smoother and doesn't have flickering (!). The existing SSAO looks even worse while moving. When I tried it for the first time, I thought it was a bug.
Old SSAO:
New SSAO:
The new SSAO doesn't have this garbage on corners and walls.
Old:
New:
I'm really not liking the black outline that this implementation gives around everything. This is really noticeable around the sides of the ship in the lighter textured map.
Perhaps, as I said earlier such effect is present in many games, I would even like to keep it (because players look more intensive) but I should improve it first. (and make ssao radius configurable)
it just looks like the image is made darker when ever there is a depth discontinuity, regardless of whether the object is already lt or not.
I didn't notice anything. Can you please screenshot something?
Improved my shader a lot:
Frame 1: NoSSAO (r_ssao 0): Frame 2: SSAO (r_ssao 1, r_ssao_lightmap 0): This doesn't make the image darker as you wanted. :P Frame 3: SSAO + applying lightmap (r_ssao 1, r_ssao_lightmap 2.2360679): The existing formula from my shader just improved it.
Firstly, I will say that the map you've chosen in your screenshots probably isn't the best one to use to show off SSAO. I don't think there's anything in the screenshot which would benefit from having SSAO... you probably want something which has a few players and less light sources.
Perhaps, as I said earlier such effect is present in many games, I would even like to keep it (because players look more intensive) but I should improve it first. (and make ssao radius configurable)
No, please don't keep it. Game developers are actively trying to avoid exactly this dark outline which older/naïve SSAO algorithms would give. It looks terrible and is in no way an accurate representation of ambient occlusion.
I didn't notice anything. Can you please screenshot something?
Here's part of your without SSAO image: it's the rectangle just to the right of the "Spectator" text.
I'm mainly pointing out the floor - the gradient there comes from the lightmap. Should adding ambient occlusion affect that? I don't think so, the area is fairly well lit and nothing is occluding it.
Here's with your SSAO:
There's two problems I have with this:
- The whole image is now darker. Why? What is occluding the top of the ship? Not in the screenshot, but this is especially noticeable in front of the cockpit on top of the ship.
- There's a thick black outline along the edge of the ship, when it doesn't make sense to have one (it never makes sense to have a black outline on anything unless you're rendering a cartoon...).
This is still a problem in your new screenshots too. This is the top left corner of the image:
Without SSAO:
With SSAO:
There shouldn't be a black outline where there's a depth discontinuity.
I appreciate your help, but I don't think this is the right direction to take - if the problem with the existing SSAO algorithm is that it flickers when you move, and has darkening on corners, then I think those should be fixed instead of replacing it entirely with something else.
There is one problem left and I can't fix it.
Seems SSAO is rendered after the fog. How does the fog work in rend2?
Ssao is rendered before the fog actually, but the ssao buffer simply gets stamped on the render buffer after everything has been rendered. This will also result in bad ssao when transparent surfaces were rendered. Fog will be applied as a separate stage per object right now. Solution for this problem could be applying the ssao before rendering fog stages and transparent objects. The other solution which I would personally prefer, is passing the ssao buffer to the lightall shader and apply it only to the ambient term of the light and remove the blit of the ssao buffer.
I don't know this part of code well, you can merge these commits and fix it yourself. :P This is the best solution.
Sorry haven’t had time to review in full. I think it’s starting to look good but I have a few suggestions regarding your sampling pattern. Will try to reply this weekend
Only sampling depths sideways and up/down doesn't look very good - it almost looks kind of pixelated. I think this needs to be changed to sampling in directions all around the currently pixel, not just left/up/down/right.
Done.
SSAO Pixel (example):
No, it doesn’t make sense to apply MSAA to SSAO or any of the post processing effects. It only works on aliasing from geometry edges
I guess, everything is done except bug with fog and translucent areas.
There's still a few comments you haven't addressed... but going to go through everything again now anyway
...and SSAO flickering is not resolved but I noticed that the same thing happens with glow.
https://youtu.be/jo7oPZ4k0Tg
I think we should find the reason of flickering first. I can't configure SSAO with that problem present in rend2.
https://www.youtube.com/watch?v=8d41OgfXZ4Y&feature=youtu.be
Can you please help me with flickering of glow and ssao?
Well, its two different problems from the same origin. Both algorithims use downscaled buffers. For the ssao you could try increasing the buffer size to match the viewport size and check if the flickering disapears. Look in tr_image.cpp for the "tr.screenSsaoImage = ... " and remove the division for width and height. This should be enough. You could try the same with tr.quarterImage[x] which is used as buffer for the ssao scaling. For the glow you can simply reduce the passes via cvar to 4 or something and look if its still appealing to you.
Well, its two different problems from the same origin. Both algorithims use downscaled buffers. For the ssao you could try increasing the buffer size to match the viewport size and check if the flickering disapears.
I've noticed that when I worked on SSAO shader. I changed buffer size for a test but the problem was still there.
Look in tr_image.cpp for the "tr.screenSsaoImage = ... " and remove the division for width and height. This should be enough. You could try the same with tr.quarterImage[x] which is used as buffer for the ssao scaling. For the glow you can simply reduce the passes via cvar to 4 or something and look if its still appealing to you.
I don't know how this should help but when I did that the whole screen started to flicker. :D
Well, https://www.youtube.com/watch?v=fH8xLlcZ5uE look at this video and you will see that SSAO image is flickering (horizontal and vertical lines) even if it doesn't match the viewport.
The problem is not with the viewport anyway I think.
The flickering is also present in vanilla renderer. I'm curious now what it could be?