Ambient occlusion and dynlight shaders with point light math

Moderator: Graf Zahl

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Ambient occlusion and dynlight shaders with point light math

Post by dpJudas » Wed Oct 05, 2016 10:30

Just a small update on my progress on this thing: I've hooked up the normal stuff to a gbuffer for the SSAO pass and updated it to use it. I've also added back the support for using plain render buffers for the scene when SSAO is off. That should fix the performance regression.

The main thing missing right now is a minor math bug of some sort in the ssao.fp or its uniforms that causes it to attenuate things a little strangely right now. I'll try see if I can crack this nut later today so we can do some more testing with this PR.

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Ambient occlusion and dynlight shaders with point light math

Post by Nash » Sat Oct 08, 2016 10:35

Is it too late for a suggestion? :mrgreen:

How about a "Weapon model draw mode" option in the GL preferences?

0: Clear depth buffer
1: Don't clear depth buffer
2: Clear depth buffer + shaders

Arranged from fastest to slowest (?)

0 is what GZDoom is currently doing

1 will allow shader effects on the model, at the expense of level clipping

2 is the slowest, does the depth buffer clearing and then the additional pass needed to allow SSAO to appear on the model

I personally wouldn't mind using mode 1 because it's not often that I position myself so close to the wall that I start to see the weapon model sink into the wall... but the added realism and depth of the SSAO on the weapon model is much more significant to me as the model will stay on the screen most of the time. Also, some commercial/modern games actually have this problem with the first person hands sinking into the level geometry but to be honest, it doesn't bother me at all.

Mode 2 is for people with very powerful hardware who wouldn't mind the performance trade-off for the best visual settings.

In my opinion, the whole weapon model business will become more obvious when models are lit per-pixel and users will expect to see the shader effects also applied to the 3D weapon. :)

Just my 2 cents!

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Ambient occlusion and dynlight shaders with point light math

Post by dpJudas » Sat Oct 08, 2016 11:29

There is an easier way that doesn't require any user setting like that: glDepthRange.

Basically, you can tell OpenGL to split the depth buffer into layers: range [0-0.9] would belong to the scene, [0.9-1] to the weapon model. The main catch with this is that it requires the 3D weapon model to be drawn at a different point in the code. It needs to be rendered as part of the opaque pass, just before SSAO is applied.

What is showstopping this PR at the moment is mostly some math bug in the shader that I haven't been able to track down yet:
Image

Generally it looks alright most of the time, but with that bug in there I can't say to Graf that I tested it and found no issues myself. :(

User avatar
Rachael
Developer
Developer
Posts: 3606
Joined: Sat May 13, 2006 10:30

Re: Ambient occlusion and dynlight shaders with point light math

Post by Rachael » Sat Oct 08, 2016 11:47

Looks fine to me, other than the weird lighting off the center. >_> But I noticed QZDoom (with openGL on) doesn't have that problem - how old is the SSAO in QZDoom?

Did you try swapping r_fakecontrast on and off?

Also - it's the very nature of "SSAO" (screen-space) that no matter what it will never be perfect. You aren't doing true ambient occlusion at all.
Spoiler: Zen Sarcasm

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Ambient occlusion and dynlight shaders with point light math

Post by dpJudas » Sat Oct 08, 2016 12:06

The QZDoom version is a slightly earlier version of my ssao branch. It is from just before it switched to the normals provided by Graf. But I'm pretty sure it isn't the vertex normals being wrong as I've tested that possibility already.

It is true that SSAO is never perfect, but it should still be "perfect" relatively to what it can see on the screen. The floor pixels can see the wall on that screenshot and should shade accordingly.

Edit: looking a bit further at my own picture I can understand why the floor isn't as dark. There's more floor in front of the wall than there's wall in front of the floor - if that makes sense. So maybe it really does look like it is supposed to.

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Ambient occlusion and dynlight shaders with point light math

Post by dpJudas » Sun Oct 09, 2016 5:22

Okay, I think this code is now working as it should. Tried playing a bit Frozen Time and didn't see any errors at 1920x1080 (ran it with 4xMSAA). The 90 degree corner thing also doesn't seem to happen anymore on my computer after the switch to gbuffer normals.

Jaxxoon R

Re: Ambient occlusion and dynlight shaders with point light math

Post by Jaxxoon R » Tue Oct 11, 2016 23:43

Eruanna said to post feedback here sooo...
decal.gif
decal.gif (244.9 KiB) Viewed 173 times
Noticed here that occlusion was being applied to the blood decals when standing at certain distances/angles from them, and tended to pop on and off as I moved. Also encountered some nasty bleeding when SSAO is enabled for portals, which only seemed to occur with plane portals and sky viewpoints:
bleed.jpg
bleed.jpg (76.33 KiB) Viewed 173 times
All of these were taken from QZDoom-q0.1alpha-150, by the way. No idea at all how to reproduce the decal thing, but the SSAO bleeding appeared 100% of the time a plane portal or sector skybox were on-screen. It also seems like the screen-edge fade out is far more aggressive in this version.

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Ambient occlusion and dynlight shaders with point light math

Post by Nash » Thu Oct 13, 2016 11:57

Can confirm about the SSAO being applied to decals... was playing Brutal Doom and noticed these weird black blotches on the wall splats. Also tested with QZDoom.

Now, I hate to be a party crasher, but in my most humble opinion, I think the SSAO + fog aesthetic isn't quite there yet... allow me to explain.

Image

These images I'm posting are simulated compositions done with Photoshop. Currently what the SSAO is doing when there is fog, is that it's just turning shadows into the fog colour. I don't think that still looks correct... BTW, the SSAO is indeed there in the image to the right, it's just subtle. :D The SSAO layer is applied 1 layer underneath the fog layer, which is the top-most in my simulated composition.

IMO, shadows should always be black (darkness), and the diminished lighting AKA fog should be applied on top, after the SSAO. Like the following pipeline (BTW ignore that huge block of white on the SSAO pass for that door - that door is actually a voxel, which, understandably, is skipped from the pass):

Image

EDIT: Below is an actual in-game screenshot of how SSAO looks like in-game, for comparison to my Photoshop simulation

Image

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Ambient occlusion and dynlight shaders with point light math

Post by dpJudas » Thu Oct 13, 2016 12:48

I think the decals thing is due to incorrect normals on the decals, although I haven't looked at the normals to confirm this. Only other explanation is that the decal being slightly in front of the normal in the depth buffer is noticed by the SSAO pass. What makes me lean more towards the first possibility is mostly that I didn't see this in the reconstructed normals version.

I agree that the fog blending doesn't look good on those screenshots. There's two places in the shader that controls how fog fades:

1) The "Lighting or fog" color for a fragment is calculated in main.fp at https://github.com/dpjudas/dpDoom/blob/ ... in.fp#L276.

2) Combining "Final" is done in https://github.com/dpjudas/dpDoom/blob/ ... ine.fp#L38. It does this by first taking the normal scene (Base + Lighting or fog) and then alpha blends the result of ssaocombine.fp on top.

Based on your screenshots I'm not entirely sure if #1 is calculating the right color for a black pixel in fog.

Edit: I'm spotting at least one bug in #1. It should say "fogdist = max(16.0, distance(pixelpos.xyz, uCameraPos.xyz));" now because pixelpos is no longer in eye space as it used to be in an earlier version of the code. There's also some possibility that the color is too bright in some cases, as I can see that if uFixedColormap == 3 then the main function multiplies its fog stuff by 0.75 for some reason.

User avatar
Graf Zahl
GZDoom Developer
GZDoom Developer
Posts: 7148
Joined: Wed Jul 20, 2005 9:48
Location: Germany
Contact:

Re: Ambient occlusion and dynlight shaders with point light math

Post by Graf Zahl » Thu Oct 13, 2016 13:25

You may be correct about the normals. I don't think I set them for decals so they take whatver value there was before.

You can look up how the wall code uses gl_RenderState.SetNormal and copy that to RenderDecals or whatever function you think is the most appropriate.

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Ambient occlusion and dynlight shaders with point light math

Post by dpJudas » Thu Oct 13, 2016 17:03

Thanks. That did the trick nicely.

dpJudas
Developer
Developer
Posts: 798
Joined: Sat Jul 23, 2016 7:53

Re: Ambient occlusion and dynlight shaders with point light math

Post by dpJudas » Thu Oct 13, 2016 17:17

@Nash: I've committed the bug fix to the AmbientOcclusionColor function and also merged that into QZDoom (not sure if you that or my ssao branch to test). Please let me know if it fixes the fog thing. If it doesn't, I need some instructions on getting to exactly that location your screenshot is from.

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Ambient occlusion and dynlight shaders with point light math

Post by Nash » Thu Oct 13, 2016 23:44

dpJudas: Awesome! I'm a little swamped with work today, so I'll just wait for the next scheduled QZDoom build to give the new SSAO stuff a try. :D

User avatar
Rachael
Developer
Developer
Posts: 3606
Joined: Sat May 13, 2006 10:30

Re: Ambient occlusion and dynlight shaders with point light math

Post by Rachael » Fri Oct 14, 2016 0:17

Pushing one now. It should appear in 10-15 minutes.

The entire process is automatic, now, except for scheduling, I still have to trigger that manually.
Spoiler: Zen Sarcasm

User avatar
Nash
Developer
Developer
Posts: 1226
Joined: Sun Sep 25, 2005 1:49
Location: Kuala Lumpur, Malaysia
Contact:

Re: Ambient occlusion and dynlight shaders with point light math

Post by Nash » Fri Oct 14, 2016 4:27

Can confirm the fixed blood decals in OpenGL, and SSAO + fog actually looks good now.

I'm proud to say that this is the first time I am seeing SSAO + fog that actually does not look wrong; where all of those Skyrim ENBs have failed. ;) Amazing work dpJudas and thank you so much for this! In my opinion, this is ready to be in GZDoom. No glitches on my end, on all SSAO quality levels.

EDIT: Actually, I might say it's not 100% complete if the weapon model does not get touched by SSAO but it has already been explained why this might not be address initially due to performance issues? At any rate, unless a mod really, really, really looks bad without the SSAO on the weapon models (and unless someone actually comes around and complains about it), I think that can be postponed for later.

EDIT 2:

Spoke too soon. ;( There's a nasty bug with portals and SSAO.

Save game for the famous Arookas portals.wad [QZDoom-q0.1alpha-173-g2a0ab96-x64] https://www.dropbox.com/s/2w58ysvx1kz55 ... 1.zds?dl=1

Portal SSAO is set to "1".

Locked

Return to “Closed Feature Suggestions”

Who is online

Users browsing this forum: No registered users and 1 guest