SSAO only calculated in vectorLightP.hlsl?
by Lukas Joergensen · in Torque 3D Professional · 01/26/2014 (3:02 pm) · 9 replies
Hey guys
I'm not sure if this is really a bug or not, but it seems like SSAO occlusion is only calculated in vectorLightP.hlsl?
Doesn't this mean that only Sun and Scattersky has an influence on SSAO, and not pointlights and spotlights?
This piece of code is ONLY found in vectorLightP.hlsl:
It's trivial to add to pointLightP.hlsl as well, but would this be wrong to do? Does the PointLights somehow calculate SSAO anw, or is there another reason for this?
I'm not sure if this is really a bug or not, but it seems like SSAO occlusion is only calculated in vectorLightP.hlsl?
Doesn't this mean that only Sun and Scattersky has an influence on SSAO, and not pointlights and spotlights?
This piece of code is ONLY found in vectorLightP.hlsl:
// Sample the AO texture.
#ifdef USE_SSAO_MASK
float ao = 1.0 - tex2D( ssaoMask, viewportCoordToRenderTarget( IN.uv0.xy, rtParams2 ) ).r;
addToResult *= ao;
#endifIt's trivial to add to pointLightP.hlsl as well, but would this be wrong to do? Does the PointLights somehow calculate SSAO anw, or is there another reason for this?
About the author
IPS Bundle available at: https://www.winterleafentertainment.com/Products/IPS.aspx
#2
Also, I haven't found any discussions on these issues on GG.com nor any other websites, is it just an issue with our implementation of SSAO?
01/26/2014 (10:06 pm)
But.. Doesn't that mean that in-door scenes doesn't have any SSAO?Also, I haven't found any discussions on these issues on GG.com nor any other websites, is it just an issue with our implementation of SSAO?
#3
01/27/2014 (6:13 am)
I do have some SSAO with indoor scenes; I mean if you pull the sliders in the PostFX panel you'll see the differences. However, I always find those different from outdoor scenes with a Sun object (not as strong). Those scenes have multiple spotlights, so Ron could be right about looking horrible!
#4
I'd suggest someone investigates it, my scenes are far too simple to provide any useful data, it would just make sense for SSAO to be sensitive to the lights in the scene.
01/27/2014 (6:16 am)
Ah yeah, I found that the Sun DOES apply SSAO to indoor scenes.. I just find it.. Weird..I'd suggest someone investigates it, my scenes are far too simple to provide any useful data, it would just make sense for SSAO to be sensitive to the lights in the scene.
#5
Ron
01/28/2014 (3:47 am)
Not really, since it is a screen space shader, then it's calculated AFTER all of the lights and stuff are already calculated and rendered. You can see it on denser interior scenes. I know my little FPS levels work well with SSAO and SSDO and where I have the point lights/spot lights effects the overall appearance. It even works well with animated lights. I have a 'warning' light when a door opens (spinning spot light) and it looks and works fine. (at least with my version). Also, you could go into more depth with the lights but, in the end it will make your calculation way to complex and slow down render time.Ron
#6
But in my head at least, DSSDO should be run for each light, as it needs the direction from the lights to compute where occlude the scene.
01/28/2014 (3:54 am)
I don't know about the SSAO, since it's generally not influenced by lights.But in my head at least, DSSDO should be run for each light, as it needs the direction from the lights to compute where occlude the scene.
#7
Ron
01/28/2014 (4:07 am)
Which is part of the reason a true dynamic SSDO is problematic. It will basically take a bit of rewriting the lighting source code. This is why I got stuck on the 'color bleed' portion of my shader project. However, I think you COULD do a decent job of approximating the effect by grabbing the color data in the scene and lerp blending that data using the depth buffer. (Take your SSDO and basically 'colorize' the effect using the screen pixel info) I have not gotten around to that yet though so it's just a theory.Ron
#8
Well I do have some color bleeding in my shader screenshot, just having some angle-issues atm, that I'm having a hard time resolving because I'm honestly a noob at this.
But I'm doing it in a seperate pass, that is I split the DSSDO in 2, one for occlusion, that creates a mask, that the different lights in the scene use to occlude the generated lights.
And then I'm doing a pass "PostRender"
(I'm not naive, I know this procedure will create issues with other PostFx's that shouldn't be included in the calculation, like LightRays, I'm just taking it one step at a time.)
01/28/2014 (5:17 am)
Huh I thought you had gotten color bleed in there?Well I do have some color bleeding in my shader screenshot, just having some angle-issues atm, that I'm having a hard time resolving because I'm honestly a noob at this.
But I'm doing it in a seperate pass, that is I split the DSSDO in 2, one for occlusion, that creates a mask, that the different lights in the scene use to occlude the generated lights.
And then I'm doing a pass "PostRender"
SceneManager::getPostRenderSignal().notify( this, &AdvancedLightBinManager::_onPostRenderPass );Where I run over all the lights once again and calculate indirect lighting, using the color information from the backBuffer.
(I'm not naive, I know this procedure will create issues with other PostFx's that shouldn't be included in the calculation, like LightRays, I'm just taking it one step at a time.)
#9
(I'm a noob as well... regardless of what others think.)
01/28/2014 (5:43 am)
ahh ok so you are about as far as I got. Just looks like we took a different approach to it. I like your approach a bit better than mine and honestly, yours looks better. (I think my bleed was an 'accident', since I did not expect it.)(I'm a noob as well... regardless of what others think.)
Associate Ron Kapaun
3tdstudios.com
At least I think this is why it was handled like it is.
Ron