SESSAO (High-Quality SSAO w/ Color-Bleed)

@Seith OH! Here's a question: Is the alpha channel in the _exact_ same map (named such) as it is for a stock Unity shader? Also, is the cutoff value named the _exact_ same thing? If not, the STUPID replacement shader system unity uses to render the camera depth normals pass will not 'see' it correctly.

 

THANK YOU SO MUCH FOR THIS!!!!!

Look, I'm not a shader expert (which is why I use Shader Forge in the first place). But naming the main diffuse/albedo texture "MainTex" instead of "Maintex" changed EVERYTHING. And from my uneducated, narrow "I'm-just-a-user" point of view this is indeed profoundly stupid.

Just look at the difference:



(Of course in this picture the dark outline is quite noticeable but in-game, with the actual textures, it looks just fine)

Again, thank you so much for pointing me in the right direction, @xenius !

 

However now I notice another huge problem with the SSAO + vegetation shader:

https://dl.dropboxusercontent.com/u/101126402/2015-07-07_12-20-25.mp4

The SSAO creates many flickering artifacts with the branches animation (using vertex offset). I've played with the SSAO settings and unfortunately it seems the artefacts cannot be removed this way.

So my question is how can one fix this issue? Is there a way to exclude some layers from getting SSAO maybe?

I do wish @sonicether would step in to fix those problems or at least let us know he's working on a solution.

 

I'm sorry I haven't been more in-touch with you guys. Indeed, it's quite frustrating having to deal with all of these problems with Unity's depth-normals texture. I'm working on quite a few serious projects right now, but am also working on the problems recently pointed out. It seems that, in that video, the replacement shader that renders the depth or depth-normals texture isn't offsetting vertices like the vegetation shader you're using does (and the movement here is created by vertex shader, correct?). I wish I could think of a simple fix for this, but at the moment I can't. The only fix I could imagine working would be to edit the replacement shader and include the same vertex shader for objects rendered with a specifically tagged shader. If you'd like help with this, I'll gladly help out. Just send me a PM.

Fixes for Mac problems are coming soon.

 

@Seith Question for you: What kind of tree is that? Is it speed tree, a tree-creator tree, or something custom?

 

It's a custom tree, using custom Shader Forge shaders.

 

Ahhhhhh, yes, you're kinda F***ed then. If its not an option in the camera-depth-normals replacement shader, it won't be see properly for that pass. There's simply no way around it currently. It totally bones any custom shaders. Would expect it to be broken for speed-tree S*** as well.

 

What a comforting thought. Oh wait. It's not.

That's crazy. I get what you're saying but that's... disheartening to say the least. I've just spent two days trying to get this to work. Until @sonicether finds a way to make this work I can't use this SSAO. It's back to Unity's Ambient Obscurance for me. And trying to fix the distance issue with it.

 

Do you really need SSAO? you can probably bake AO into the entire scene and characters, and it'd still pop enough and work fine with dynamic time of day. The only reason it's unfeasible in my game is because it's quite large open world. If you know you'll be in closed environments, and a lot of the level is fixed (doesn't transform), the value of SSAO drops sharply.

I'm not a terribly big fan of SSAO. It's only really good where you can't bake it ie a dynamic character is standing flush next to a wall, or where the feet meet the floor. And for those there's sphere occlusion ie last of us style shadows, which in tandom with PBS AO, can deliver almost identical visuals for a fraction of the cost.

Perhaps a better train of thought is figuring out how to bake AO to lightmap only, and have it still affected correctly by changing lighting conditions.

It's probably eating heavily into console performance as well.

 

@Seith The Unity Ambient Obscurance works because (from what I can tell) it only grabs the depth buffer, instead of the camera-depth-normals texture. Tis the reason its well... so soft and noisy. Its only doing depth comparison sampling without taking into account surface facing direction.

I did talk to Joachim (ShaderForge) about this issue. Right now one could theeeoretically do a work around of modifying the unity-internal camera-depth normals replacement shader to take into account custom shaders that modify depth/cutoff. As there's no auto way to do it you would either need to do it yourself, or pay someone to if SSAO (that isn't the included obscurance) is really important to your aesthetic.

The long-term solution to this is convincing Unity to allow a meta-pass to be used that's defined _in_the_fucking_shader_ for this pass, but knowing how Unity works, that's likely to happen some time between 5.4 and never. One can hope though, as this effectively renders _anything_ that relies on Camera-Depth-Normals a minefield.

 

@hippocoder Thanks for you suggestion. However I'm very happy with the idea of clicking a checkbox on a camera component and getting SSAO this way. Anything requiring baking is far beyond the scope of my patience and my workflow I'm afraid.

@xenius Yes, any time the shader would be changed in Shader Forge a new version would have to be manually created to match the vertex offset algorithm (in the case of vegetation/wind). This is not good. At all.

And I understand if you want to do "Monument Valley" you don't really care about those kind of "limitations".

But I want to believe that Unity is interested in the AAA graphics market. That's the vibe I get when I look at the Blacksmith demo. Although you're right; until more people discover that you can't use SESSAO (or SSAO Pro) and vegetation at the same time (unless you've got a shader wizard in your team) not much is going to change.

I do have hope though; almost each time I got in touch with Unity peeps they looked at the issue and often came back with a solution. Let's hope this is going to be one of those cases.

 

@Seith You have a prominent and truly visually impressive game. I would think in this moment that if you attempted to use a bit of your own clout speaking with UT, you might be able to get some movement (or at least an answer) about dealing with this cam-depth-normals issue from them. Considering this issue extends to things working with tesselation as well, I would think that they would do something..

 

Thank you sir! I have extended my tendrils. Pray the Ancient Ones favor the omen...

 

good luck, man if anyone can do it - it's you

 

Is there a way to vote for this on feedback? If enough people see it as a worthwhile enterprise, the overhauled new feedback section might be worth our time.

 

@sonicether @xenius I haven't heard back from Unity yet, but that's ok because EVERYTHING IS WORKING NOW!!!!!

That's right, custom forward animated vegetation shaders rendered in deferred do not cause any see-through issues with SSAO anymore! You still have to do some leg work to include your custom-tagged shaders in Camera-DepthNormal but hey, at least it works!

With a big thank you to SonicEther (he did 95% of the work) and several kind souls over the forums, no more "transparent" vegetation!!



(Note that it addresses issues with both SESSAO and SSAO Pro)

And for anyone interested here's how to manually translate a Shader Forge shader (with animated vertices) into the SubShader needed to include in Camera-DepthNormal: https://docs.google.com/document/d/1clA4vrGj1Fi4xdsQ53u7lXdyla31YalJG225aKQO7NU

 

Thanks for the research on this Seith!
I could possibly build this into Shader Forge itself, making it add sub-shaders to the depth normals file.

However, it's a rather unstable thing to do. For instance, importing a SF shader must make it write to that file without opening SF, which is currently nontrivial, or, you have to open every shader once to make it work properly.
And when you update Unity, the shader file is replaced, forcing you to reopen all shaders using depth normals + vert offset again.

This is one of those things where I can make a "solution", but where Unity should be the ones to properly look into addressing this.

I'll pull some strings and floats

 

Thanks for the update Joachim! Just saw the exchange with Aras on Twitter (thanks for including me). Poor Aras. Caught in vacation between my tendrils and your strings...

 

I am trying to give shape to a cloud of particle, self shadowing.
SSAO is something that's commonly used for that.
SESSAO doesn't seem to work with particles.
Is there a workaround?

 

I was wondering, is there a way to make a shader or material that this specifically ignores? I have an object I'm using as a sorta wall that makes anything behind it invisible, and I need SESSAO to not work on it so that the edges in the model aren't shown in the middle of space.

 

Hello there!

I recently started using SESSAO and I love the look of it, especially the colour bleeding!
Thank you for your good work!

But I have a problem with some custom shaders (the AO is shining through). I looked through the thread and this seems to be a common problem--however, the shaders in questions are opaque forward rendering shaders rendered in deferred and don't have any transparency.
For example, this happens with the following shaders.
https://www.assetstore.unity3d.com/en/#!/content/7238
https://www.assetstore.unity3d.com/en/#!/content/22143
Also: The default "Unlit" shader, for example
I tried to rewrite the shaders the way written above, but I cannot get it to work.
Now I'm wondering if I missed something and if there's anything that I could do to make it work.

Do you have an idea?

Thank you for your help!
- KW

 

SSAO cannot work with semi-transparent particles because it relies on information in the depth buffer, and only one "surface" can be store in the depth buffer in any pixel. Thus, semi-transparent objects can't write to the depth buffer properly.

Hmm.. You could try disabling ZWrite in the shader http://docs.unity3d.com/Manual/SL-CullAndDepth.html

There are a few things to look for. Make sure the main albedo texture property is named "_MainTex". Also, ensure that, right after the SubShader begins in the shader, you've got: Tags { "RenderType"="Opaque" }

You'll also want to make sure that ZWrite is On.

Let me know if that helps.

 

Thank you for the pointers!
I made sure that these things are included, however, it does not seem to work.
Changing the Fallback-Shader helped in some cases, but not always.
Do you have any other ideas?

Thank you for your time, I really appreciate it!
- KW

 

SE could you comment on what's up with having no word on lens flares on your SENBDL thread please.

 

@DivergenceOnline Dude, he said he was _playing_ with it, with no guarantees, and he's working on a GI system. Being impatient/pushy over non-trivial _additions_ to a $20 asset is a touch unreasonable.

 

Not when he has a history of disappearing for six months or more at a time, it isn't. As a purchaser of 100% of his products and at full retail cost, merely asking for "a comment on..." a feature he himself demonstrated is nowhere near "being pushy". If you think so, might I invite you to develop a slightly tougher skin.

 

Alright, my problem is solved now.
In case of opaque shaders being troublesome, assigning the right fallback shader can fix the problem (which is not the case for the Unlit shader, for example), and the skin shader was fixed by removing the hardcoded offset (though it needs to be said that the programmer did write that playing with the offset could help, it was my mistake to not simply zero it out).
Everything's working great now~

Thank you for your patience, and thank you for your good work!
- KW

 

The particles use cutout shader.

 

Hi,

I am very glad with SESSAO, but I have a bug.

When I turn ON the play mode, black pixels shows up and there is no AO applied.



Turning OFF then ON the SESSAO during play mode fix the bug, but that is not ideal.



Unity version 5.1.1f1, deferred, linear, DX11

 

upload those images to imgur or something ... those dropbox links are probably only visible to you

 

D'oh ! I took the wrong link.

Thanks for pointing it out to me.

 

Hmm... Perhaps this is an issue with execution order of image effects attached to your camera. http://docs.unity3d.com/Manual/class-ScriptExecution.html

I'd try adding SESSAO.cs to the custom order and putting it after the default time. That may fix the issue. Let me know if that works.

Also, if you could let me know what other image effects are on your camera that'd be helpful, either way.

 

Thanks a lot, that fix the issue.

I am not sure about the place were I schould put the SESSAO.
The order of my image effects is :

TOD_Rays (god rays from Time of Day)
Deluxe Eye Adaptation (from Delux Tonemapper)
SESSAO
SENBDL
Deluxe Tonemapper
Antialiasing
SSR Effect
Contrast Enhance

 

dude, Anti-alias after SSR, always.

 

Here's the order I'd suggest:

SSR Effect
SESSAO
TOD_Rays
SENBDL
Deluxe Eye Adaptation
Deluxe Tonemapper
Antialiasing
Contrast Enhance

SSR first because I'd imagine having SESSAO over SSR might be beneficial. Swap them if it's not. Then TOD_Rays because you don't want SSR or SESSAO drawing on top of the rays. At that point, all the heavy "scene" shading is done, proceed to do bloom, eye adaptation, tonemapping, antialiasing, and contrast enhance.

 

Thanks guys !

I have to place the SSR after the Eye Adaptation, otherwise I have ugly reflections.
And I put the SENBDL after the Deluxe Eye Adaptation, because I dont want the bloom to be used to ajust the tonemapping and this is what the Eye Adaptation does.

 

It used to work great with Oculus Rift in the previous SDK but updated to 0.7 and it feel broken.
Built with U4.6.8 oculus Sdk0.7
Used to work with U4.6.5 Sdk0.6.0.1
Anyone else?

 

@sonicether @Acegikmo or @xenius I was wondering if any of you guys had any news about UT implementing what is needed for custom transparent forward shaders to write to CameraDepthNormals properly. I've been having the artifacts on my vegetables for months now.

 

Color bleed is broken.
this

turns into this

 

@sonicether @Teejay5 Was there a solution for this? Reading through the thread I didn't see a response, I'm having this same error myself and would really like to fix it somehow.

 

Unfortunately no, I haven't gotten a response about this issue. But this is the first time hearing that someone else has the same problem; what are your computer specs?

 

Damn. Hopefully @sonicether has a solution.

It's not actually on my computer, but the first other computer I tested on (sent build to a friend)
The specs are:

Mid 2011 iMac OSX 10.10
OpenGL 2.1
AMD Radeon HD 6750M

 

flags < (1 << kHideFlagsBits)
UnityEngine.Object:set_hideFlags(HideFlags)
SSAA.internal_SSAA:StartSSAA()
SSAA.internal_SSAA:Update()


dont know what is that ((
work, but cant build, cose of that error

edit:
found out that ssaa (https://www.assetstore.unity3d.com/en/#!/content/37214) cant work with sessao
any tips?

 

@zelmund What do you mean the two don't work together for you? I have 4 scenes using both of them (granted it gets expensive as SSAO effects at greater-than-screen-size) get super pricey.

 

im using unity 4.
do you?

 

@zelmund Ahhh, no, using Unity 5. No idea about 4.x compatibility with either asset. Apologies.

 

by the way. 1.3 not working at all now. was working at 1.2

 

Hi! Just wanted to say, this is the best SESSAO solution out there The colour bleeding is one of the best.

We just have one issue with it - it seems to sometimes leak materials. We have multiple cameras in a unity scene, with the SESSAO script on all of them (between 3 to 4 cameras). When saving the scene, we sometimes get this notification/error from Unity:

"Cleaning up leaked objects in scene since no game object, component or manager is referencing them.
Material Hidden/SESSAO has been leaked 4 times."

It happens in 2D and 3D scenes, we're using Unity Pro, 5.1.3. I attached a screenshot of the SESSAO script on one of the cameras. Any ideas on how we can fix the leak?

 

I just recently bought SESSAO and I'm really pleased at the results I can get with it.
However I have a problem, I'm using UFPS for my game and UFPS uses two cameras, and it seems that it's random which one should actually have the SESSAO effect script on it, like if I put it on one and click play, half of the time I'll have SESSAO. For now I've opted to adding the script to both cameras and hoping that doesn't get me into any problems xD

But just thought I'd let you know.

 

Oh, derp, the reason it was working was that I'd somehow in frustration managed to deactivate the weapons camera, so not even adding the script to both cameras actually works.
The problem seems to lay in the fact that the camera that goes "on top" as it were, (the weapons camera) is set to only render one layer (the weapons layer)