[WIP] BasicSSAO – Added optional smoothing

And a much more realistic setting:





I don’t want to sound pessimistic, but you are going through he exact same process that i did with SSAO.

Your SSAO is nice, but exhibit a severe banding artifact, that can be clearly seen on the dragon shot around the back leg and the tail. This can go unnoticed if you have dark textures like the rocky wall in sponza, but on bright textures, it’s very noticeable.

JME SSAO was like this before and performed a lot better than now.



To avoid this you have to keep a very low sample radius making the SSAO look more as an outline than a real AO. That’s why you have better details on yours

You can’t blur this bands, or at least not if you want to have good performance, because to have an efficient blurring of this you’d have to use a blur with a huge kernel and it would be even more expensive than SSAO itself.



So next step would be to randomly spread the ssao samples to avoid the banding. Hence the famous noise texture, but this has the draw back of making the scene looks grainy.

Hence the convolution pass. You’ll try basic gaussian, but you’ll notice some bleeding over edges, then go for bilateral blur with an additional depth texture fetch and end pretty much to the same result as JME SSAO.



Moreover JME SSAO is far from perfect and still has some kind of blinking artifact on the edges of the screen when the sample radius is fairly wide.



That’s why I’m planning to go on a completely different implementation.(MSAO)



Of course your SSAO can do the trick, give descent results, and maybe faster than previous JME SSAO. But all is a trade of between quality and performance.

2 Likes
@nehon said:
I don't want to sound pessimistic, but you are going through he exact same process that i did with SSAO.
Your SSAO is nice, but exhibit a severe banding artifact, that can be clearly seen on the dragon shot around the back leg and the tail. This can go unnoticed if you have dark textures like the rocky wall in sponza, but on bright textures, it's very noticeable.
JME SSAO was like this before and performed a lot better than now.

To avoid this you have to keep a very low sample radius making the SSAO look more as an outline than a real AO. That's why you have better details on yours
You can't blur this bands, or at least not if you want to have good performance, because to have an efficient blurring of this you'd have to use a blur with a huge kernel and it would be even more expensive than SSAO itself.

So next step would be to randomly spread the ssao samples to avoid the banding. Hence the famous noise texture, but this has the draw back of making the scene looks grainy.
Hence the convolution pass. You'll try basic gaussian, but you'll notice some bleeding over edges, then go for bilateral blur with an additional depth texture fetch and end pretty much to the same result as JME SSAO.

Moreover JME SSAO is far from perfect and still has some kind of blinking artifact on the edges of the screen when the sample radius is fairly wide.

That's why I'm planning to go on a completely different implementation.(MSAO)

Of course your SSAO can do the trick, give descent results, and maybe faster than previous JME SSAO. But all is a trade of between quality and performance.


Though, I see what you are saying, to be fair... let me post some of the shadow maps now that I removed the temp code I had for falloff... some settings are stunning with almost no artifacts visible. Because you can adjust the detail/wider area occlusion setting and the blending of the two... you can find the exact setting that works for you. I'll use the same dragon model with no texture at multiple settings tomorrow, as I would love to get your feedback about them and see if you still think the detail layer ends up looking more like outlining. I have a feeling you won't, but /shrug... no telling until you see them.

I do however see what you are saying. There will always be a trade off... but the link to the new approach to AO that you posted has a particular aftifacting in it that I think ends up being worse than what we have now. Because of the downsampling/upsampling... you can see pixelation between where occlusion should happen and where the shadow map actually rendered it, leaving a reverse outline in places. This could be blurred out, I guess, but... no matter the approach, there will always be issues.
1 Like

I had a few minutes lol… here are 3 shots of the last settings I was playing with. I post more subtle and more drastic tomorrow.













The only artiffacting I can make out at first glance is where blender hacked the import of the .obj file ;)>

Here be a video with what I would consider pretty stunning results considering no blurring. If you compare it to looking around your own house, you’ll see that it (at a minimum) is producing proper AO. There are no large fuzzy black blotches… there is a decent amount of the detail that you actually see when looking around… and the dispersion seems fairly accurate as well.



@nehon I understand your skepticism… but a 57% increase in performance and much more realistic looking ambient occlusion has got to be worth something, yeah? :wink:



http://youtu.be/2-Cxi1dsWtg

4 Likes

That looks really good. I guess objects only occlude against themselves or do other objects occlude as well?

@zarch said:
That looks really good. I guess objects only occlude against themselves or do other objects occlude as well?


They do... you can set both fine detail and dispersion (wide area reflection) radius' independently to encompass other objects of course. However... as neat as it looks... it's not very realistic. I think there is a fine line between AO and shadow casting. In the case of the model used in this scene, everything is one object... I just have the setting adjusted to what I think looks most real.

Proper AO is hard anyway… especially so in screen space. Most AO techniques concentrate on the “shadows” when AO is actually caused by light reflection. (I’ve always sort of thought “ambient occlusion” was a misnomer but I guess it serves well to describe the technique of faking what is really happening without ever approaching modelling what is really happening.) To me all of the techniques kind of fall down on the larger surfaces where AO should be much bigger, especially in the corners. In screen space, you’d have to do soooo much sampling to achieve this.



The Cornell box is a pretty good illustration. I think these SSAO techniques would have real problems with the subtle, and large, shading on the back wall near the ceiling, for example.



So, given that these techniques will never (and can never) possibly look right… I think it’s best to pick techniques that are fast, add visual interest, and are not obviously wrong. Your version seems to score points there… even if it doesn’t necessarily go as far as it could.



In other words, options are good in this case.

This is good. But this is closer to an outline to a proper AO.

I don’t want to deny your work really, you’ve been doing really great. I just want you to understand what i was aiming with SSAO : fake global illumination. I didn’t quite achieved this, and that’s why i want to change the implementation.



Here you have nice self shadows, but with a very low radius. The good test in this scene is the shadow under the curtains. You should have a diffuse smooth shadow under them with proper AO. Here they are just outlined a bit making the shadow looks weird.

You can grab the obj scene and render it in blender to see what i mean.

Many AO are like yours, and that’s completely fine for a lot of games.

Just look at how Starcraft 2 SSAO looks like and you see what i mean.



Again, you did great, maybe we could integrate your filter somehow in the current SSAO and set it as the “Fast AO” configuration. But there is still more work to do on AO.

maybe @t0neg0d could make SSAO that could work on older/integrated graphic cards?



case on my laptop(with newest drivers) with JME SSAO i have same problem like here:

http://hub.jmonkeyengine.org/groups/general-2/forum/topic/testssao-example-not-working/



when other games(new games) Ambient Occlusion work fine, no problems.

Maybe they use other technique, don’t know. But it would be nice to see working AO on that laptop.

i hope MSAO will be that technique, that work everywhere.

Yupp, the current SSAO does not work on my macbook either… :confused:

@oxplay2 said:
maybe @t0neg0d could make SSAO that could work on older/integrated graphic cards?

case on my laptop(with newest drivers) with JME SSAO i have same problem like here:
http://hub.jmonkeyengine.org/groups/general-2/forum/topic/testssao-example-not-working/

when other games(new games) Ambient Occlusion work fine, no problems.
Maybe they use other technique, don't know. But it would be nice to see working AO on that laptop.
i hope MSAO will be that technique, that work everywhere.


I was able to repro this on my machine here while working on this. It had to do with the use of the texturemap in the shadowmap creation. I can't remember the specifics, but I'm 99.9% positive that this will not happen with this version, as there is no use of the original texturemap in the ssaomap creation potion of this.

I'll post the code for this sometime today, as I'm not sure if there is much more I could do to increase the visuals without killing performance.

@nehon said:
This is good. But this is closer to an outline to a proper AO.
I don't want to deny your work really, you've been doing really great. I just want you to understand what i was aiming with SSAO : fake global illumination. I didn't quite achieved this, and that's why i want to change the implementation.

Here you have nice self shadows, but with a very low radius. The good test in this scene is the shadow under the curtains. You should have a diffuse smooth shadow under them with proper AO. Here they are just outlined a bit making the shadow looks weird.
You can grab the obj scene and render it in blender to see what i mean.
Many AO are like yours, and that's completely fine for a lot of games.
Just look at how Starcraft 2 SSAO looks like and you see what i mean.

Again, you did great, maybe we could integrate your filter somehow in the current SSAO and set it as the "Fast AO" configuration. But there is still more work to do on AO.


My thoughts on this were.... there is a BasicShadowRenderer and then there is the PSSM... this could be JME's BasicSSAO,

EDIT: Updated with fixes - See Original Post for code as it is being maintained there now

2 Likes
@oxplay2 said:
hehe :)

i don't know what exactly FixedFunc was doing.(because it was not a time to make shaders for me)

but i know it was made deprecated couple months ago. It do nothing now.


I had one last thought of something to add to make things a bit easier for setting up SSAO. The default settings are pretty nice looking but set for a particular model scale (the one used in the test scene). I think I may add a scaleSettings(float scale) function so you can globally adjust all settings for the scale you choose for your game (basically... pass in 0.25f and setting would all be 1/4 of what they were... yes... I know... I am speaking the obvious lol). But, aside from this... I think it is done. I hope >.<

well, it’s not hard for users to make scale modifier themselves :wink:

but let it be.



i think this shader is complete now. will need only some fixes, if there will be problems.



my laptop is weak, but i imagine how good graphic would look with:

SSAO + Bloom + dof + fog + blur(only in some situations) + FXAA + MotionBlur(this shader was somewhere on forum)

Updated the code with performance optimization… nearly double performance by default… yay.



Original post now contains the maintained code.

2 Likes

@oxplay2 @kwando If either of you would be so kind as to test this on the problem machines… I would really appreciate it!

2 Likes

I will try it when time allows :slight_smile:

1 Like

@t0neg0d



i tested it now. you should add it to:

http://code.google.com/p/jme-glsl-shaders/



or wait, maybe devs will add it to JME libs.



i needed to remove FixedFunc, because of:

java.lang.UnsupportedOperationException: In material: MatDefs/BasicSSAO.j3md
The 'FixedFunc' technique name no longer has any special meanining.
To support fixed pipeline mode, remove that technique's name entirely.


but when removed, it work perfect :) congratz!

here is proof from debug mode:

http://img717.imageshack.us/img717/9397/workingr.png
2 Likes

@t0neg0d



from my next observation:



setScale - in documentation is said that 0.2f is default, but setting it to 2f give same result like dont use “setScale”.

0.2f give much stronger result. so 2f is default, yes?





basicSSAO.setUseDistanceFalloff(false); - setting it to false give:


SEVERE: Uncaught exception thrown in Thread[LWJGL Renderer Thread,5,main]
com.jme3.renderer.RendererException: compile error in:ShaderSource[name=Shaders/BasicSSAO.frag, defines, type=Fragment, language=GLSL100] error:ERROR: 0:18: '' : syntax error incorrect preprocessor directive
WARNING: 0:18: unexpected tokens following the preprocessor directive - expected a newline
ERROR: 0:96: '' : syntax error incorrect preprocessor directive
WARNING: 0:96: unexpected tokens following the preprocessor directive - expected a newline