Horizon Based Ambient Occlusion - HBAO image effect

@jimmikaelkael Did you had a chance to look at the repro project?

 

Yes, It can't see any fault in HBAO but I found the offending setting in HDRP quality settings.
You can change buffer format of PostProcessing to R11G11B10 and it will fix the issue:


The issue seems to happen with custom post process only, HBAO is never allocating source or destination texture so this lead me to think it's a problem in HDRP.

 

thanks, this seems to fix the issue! I'll see if I can file a bug.

 

So now I am able to full use it in HDRP / VR.
Effect looks really good, but I am much concerned about the performance impact. It seems to cost like 1-2 ms even on very low settings, compared to the HDRP SSAO which basically has no measurable impact on performance on low settings (but looks also way worse). Is this performance impact to be expected?

 

Good, well the effect is scalable: HDRP's SSAO run half res and with temporal filtering, half res means 4 times less pixels to treat.
So in HBAO enable half resolution with interleaved gradient noise, lowest quality then enable temporal filtering and medium blur.

 

these settings brings it down to around 0.8ms in Editor (on RTX 3080), while still looking better then SSAO (albeit still more expensive, but workable).
I guess the issues with Dynamic Resolution are known to you? I know that there are still issues with Dynamic Resolution and Custom Post Process, so this is very likely Unity / HDRP bugs, which are already reported and being worked on afaik.

 

yep DLSS/Dynamic resolution is currently broken by HDRP, another known limitation is that AO is drawn on top of volumetric fog because of the lack of proper injection point in the pipeline.

 

Hey there!
I have a suggestion. In URP, I noticed a large amount of shader variants coming from HBAO. From looking around, I noticed that GetDirectionsKeyword() and GetStepsKeyword() both feed from the same HBAO.Quality argument quite predictably. You could probably refactor the combinaison of multi_compile_local DIRECTIONS_X and STEPS_X into a single multi_compile_local QUALITY_X in order to reduce shader variants, from 768 to 240!

Something like this:

Code (CSharp):

1.             #pragma multi_compile_local QUALITY_LOWEST QUALITY_LOW QUALITY_MEDIUM QUALITY_HIGH QUALITY_HIGHEST
2.  
3.             #if QUALITY_LOWEST
4.                 #define DIRECTIONS  3
5.                 #define STEPS       2
6.             #elif QUALITY_LOW
7.                 #define DIRECTIONS  4
8.                 #define STEPS       3
9.             #elif QUALITY_MEDIUM
10.                 #define DIRECTIONS  6
11.                 #define STEPS       4
12.             #elif QUALITY_HIGH
13.                 #define DIRECTIONS  8
14.                 #define STEPS       4
15.             #elif QUALITY_HIGHEST
16.                 #define DIRECTIONS  8
17.                 #define STEPS       6
18.             #else
19.                 #define DIRECTIONS  1
20.                 #define STEPS       1
21.             #endif
22.  

I could also suggest that you check about adding shader stripping during build time. They strip a lot of PostProcess variants in URP's ShaderPreprocessor.cs by looping through all VolumeProfiles in project.

I'm using HBAO 3.3.1 at the moment.

Cheers!

 

Thanks for feedback, what a constructive comment!
I will put your suggestion into next release, and not only this applies to URP but also HDRP and Standard pipeline too.

 

It doesn't work with suimono water system when I have suimono water and HBAO enabled it looks wired and wrong can you please check why this happening?

 

HBAO does not do any change to depth/normals buffer. Please get in touch with SUIMONO author for support. Seems Unity's ssao has issues too: https://forum.unity.com/threads/suimono-2-0-interactive-water-system.289311/page-13#post-2717334

Not sure the fix is still valid nowadays but found this on their forums:
https://forum.unity.com/threads/suimono-2-0-interactive-water-system.289311/page-13#post-2717411

 

Hello! I have recently used this Post effect and of all the ones I tried this has proven to be the best for my needs, not to mention that it works as promised. The bleeding colors and multi bounce options are top notch (for a top down 3/4 view shooter style, so everything is far away and quite “controllable”)
——
TLDR; I’m using the built in RP and wanted to ask: does it make sense or would it be possible to do that normal reconstruction before hand?
——

• In my project (and my experience in general) the DepthNormals hidden pass mode won’t work (or maybe I never understood that one properly to begin with since a lot of custom per object vertex and pixel shaders get lost or needs gymnastics to make it happen during the replacement shader).
• The normals reconstruct option you implemented works and saves the day. It works but guess it has a perceivable extra costs for every time it samples in the shader loops. However, on my limited tests on modern hardware it’s not a problem yet.

So, was thinking a couple of ideas:

1. Get the current Depth texture and add an extra pass after it (or via post stack “BeforeTransparent” maybe) that creates a _CameraNormals texture. HBAO is rendered afterwards, the texture is passed to the HBAO shader as a global, maybe minor changes would need to be done on the cginc files.
   
   
2. OR: similar approach, but recreate by hand a _CameraDepthNormalsTexture right after the depth pass via a pixel shader. Could leave it linearized and all if it would help performance even further.

Can live without normal maps, non smooth normals, etc…

Also exploring solutions, our game started quite simple and very artistically driven, ended up stripping all lights and only using directional shadows. Currently we would like a light here or there at very rare instances and would rather try to just do it as a transparent sphere that does the lighting in a decal/deferred-lighting style (using the depthNormals maybe) instead of having all the shaders support actual lighting (nothing is actually lit in our game in the traditional sense). Or maybe we should convert to URP by now.

Bonus question: does it make sense or would it be beneficial to try to port the HBAO pipeline to the Post Processing stack of Unity or should just leave it on the Camera component?

Thanks a lot in advance and great easy to use plug and play asset you made.

 

Hi Alejandro!
Well, there's absolutely no benefit doing the normals reconstruction before HBAO. The reconstruct normals feature already makes good use of GPU cache, samples are locally very close to each other.
Also when using reconstruct mode you don't have to pay the cost of objects being redrawn to generate the DepthNormals texture if you don't use it for other effect so this is clearly a winner regarding performances.
HBAO never uses depth from DepthNormals because its quality is too low for doing ao.

For integration into the post processing stack there's no benefit at all regarding perfs, the only thing I can see is convenience.

If you are trying to improve HBAO cost, I can suggest to use temporal filtering with half resolution, lowest quality and interleaved gradient noise.

 

Hi! Thanks a lot for the prompt reply, I was wrongly assuming that the normals are sampled (or reconstructed) at every step of the ray/search/etc radius.
And true that, I always forget the that the depth samples are basically one pixel next to each other. I could probably just do the same for the rare instances where I would need to do something similar in a localized screen section or even just go DDX/DDY if quality would suffice.

One of the ideas of the DepthNormals was that it would be generated from the same DepthTexture after the depth pass happens on all the objects (as a post effect). But I'll be scraping this idea currently for the time being.

Temporal Anti-Aliasing doesn't seem to work for me on the BiRP (also not at the latest unity version), does the Deinterleave 4X (I'm rendering to a 1080p render target) is advised?

In any case I'm already getting ahead of myself, it is working for what I need and as expected with mind-blowing quality.

Thanks once again.

 

For temporal filter, you need to have all your mesh renderers set with "per object motion" as motion vectors setting. Here it works with lowest Unity version that HBAO is available for and also latest so that's quite strange. Might be related to the use of custom shaders if you are using it...

For 1080p, no I don't recommend using deinterleaving.

 

Finally solved our issue (with HBAO enabled, alpha pass was ignoring Zbuffer).
It was because our main game camera had MSAA set to Off. With MSAA set to use pipeline settings, the alpha is z-masked correctly with or without HBAO.

 

Hi, Great asset!
A small bug:
It appears there's something wrong with the normals in the OrthographicView + ReconstructNormals combination.
This problem is not there if using Camera normals or GBuffer normals.
This naturally results in incorrect ao calculation down the line.

HBAO package version 3.4.9, Unity 2019.4.0f1, Forward rendering, Built-In RP

 

This does not seem to be related to normals but rather depth, it never happens in game view but only in scene view and also happens for camera and gbuffer normals where the ao still incorrect.

I'll see if I can do something but nothing sure, there's the issue too with PP occlusion.

 

Well after investigating a bit more, the issue is just that putting the scene view in isometric just doesn't make the code to choose orthographic path for the scene view camera. If I enforce it in HBAO.cs code in solves the problem:



So, does anyone know how to detect if scene view camera is in isometric mode?

 

I just tried in orthographic camera in scene view in Built-in RP and hbaoCamera.orthographic seemed to have the correct value, at least in 2021.2.15f.

You can detect orthographic projection from the projection matrix with this code :

Code (CSharp):

1. bool isOrthographic = camera.projectionMatrix.m33 == 1.0f;

 

Regarding @JollyTheory's issue, I myself had to deal with some orthographic differences with perspective and I addressed them best I could in my project. My basis is in URP. Sorry that I didn't think to share it with you before.

With an orthographic camera, you can see that the AO effect is incorrect on a large 3D plane. That is because the Z is reconstructed from the distance to camera origin, rather than the distance to camera near plane. Here's a fix in HBAO_Common.hlsl. (This is based on URP's own orthographic support for SSAO effect, in SSAO.hlsl) :

Code (CSharp):

1. float3x3 GetCoordinateConversionParameters(out float2 p11_22, out float2 p13_31)
2. {
3.     float3x3 camProj = (float3x3)unity_CameraProjection;
4.  
5.     p11_22 = rcp(float2(camProj._11, camProj._22));
6.     p13_31 = float2(camProj._13, camProj._23);
7.  
8.     return camProj;
9. }
10. float3 ReconstructViewPos(float2 uv, float depth, float2 p11_22, float2 p13_31)
11. {
12.     #if defined(ORTHOGRAPHIC_PROJECTION)
13.     float3 viewPos = float3(((uv.xy * 2.0 - 1.0 - p13_31) * p11_22), depth);
14.     #else
15.     float3 viewPos = float3(depth * ((uv.xy * 2.0 - 1.0 - p13_31) * p11_22), depth);
16.     #endif
17.     return viewPos;
18. }
19.  
20. inline float3 FetchViewPos(float2 uv) {
21.     float depth = LinearizeDepth(FetchRawDepth(uv));
22.  
23.     float2 p11_22, p13_31;
24.     GetCoordinateConversionParameters(p11_22, p13_31);
25.     float3 viewPos = ReconstructViewPos(uv, depth, p11_22, p13_31);
26.     viewPos.y *= -1;
27.     return viewPos;
28.     //return float3((uv * _UVToView.xy + _UVToView.zw) * depth, depth);
29. }

Similarly, the stepSize below is affected by distance to camera origin, and you can see the AO effect changes quite a lot when moving an orthographic camera along its local Z axis. Instead of scaling the stepSize based on Z distance, I changed it to be based on the camera's orthographic size. I'm not sure this is the proper fix tho! When zooming out of the scene view with the mouse wheel, its changes the orthographicSize, so it scales the stepSize, and it looks like the AO effect slowly disappears. But it is better in my opinion. In HBAO_AO.hlsl :

Code (CSharp):

1.  
2.     #if ORTHOGRAPHIC_PROJECTION
3.     // In orthographic, we want to have a constant radius across all depth distances from the camera near plane.
4.     float stepSize = min((_Radius / (unity_OrthoParams.y * 2)), _MaxRadiusPixels) / (STEPS + 1.0);
5.     #else
6.     float stepSize = min((_Radius / P.z), _MaxRadiusPixels) / (STEPS + 1.0);
7.     #endif // ORTHOGRAPHIC_PROJECTION
8.  
9.     //float stepSize = min((_Radius / P.z), _MaxRadiusPixels) / (STEPS + 1.0);
10.  

Fantastic plugin by the way Just some little gotchas for orthographic pureties.
Cheers!

 

Can this asset bake shadows like how Unity's ambient occlusion can bake shadows into static mesh's lightmaps?

 

No this asset does not bake AO.

 

Thank you very much for feedback!
Well on my side I fixed both issues in a different way, avoiding unnecessary computations in shader.

Most of the fixes on script side:


And a slight change in shader:


Could you please test and give feedback?

EDIT: forgot to mention you'll need to remove your change on stepSize code.

 

Sure thing! I like your FetchViewPos fix. Much cleaner.

However I disagree with the _Radius/stepSize fix (CPU and shader). I still think it should not be scaled by P.z for orthographic.
I would rather propose this which makes the radius really consistent between Perspective and Orthographic, like the radius is based in world units! :

Code (CSharp):

1.                 material.SetFloat(ShaderProperties.radius, hbao.radius.value * 0.5f * ((sourceHeight / (hbao.deinterleaving.value == HBAO.Deinterleaving.x4 ? 4 : 1)) / (invFocalLenY * 2.0f)));
2.  

Code (CSharp):

1. #if ORTHOGRAPHIC_PROJECTION
2.     float stepSize = min((_Radius), _MaxRadiusPixels) / (STEPS + 1.0);
3. #else
4.     float stepSize = min((_Radius / P.z), _MaxRadiusPixels) / (STEPS + 1.0);
5. #endif // ORTHOGRAPHIC_PROJECTION
6.  

Here are some shots from using Highest Quality + Radius=5 (very noticeable change in high Radius values)

Perspective:


Orthographic -> float stepSize = min((_Radius / P.z), _MaxRadiusPixels) / (STEPS + 1.0) :



Orthographic -> float stepSize = min((_Radius), _MaxRadiusPixels) / (STEPS + 1.0) :


The solution I'm proposing is giving much more consistent than what I had before

 

Forgot to check consistency between both projection types. Your fix is definitely the way to go, thank you very much for feedback!

 

So, with the help of @sabojako we now have the proper fix. It turns out it was not normals related but rather an unprojection bug in orthographic mode, fix will be available in next release for all pipelines.

 

Hi, thank you so much for your prompt fixes.
Found another bug:
URP around v10.5.0 (Unity 2020) has it's normals in view space, HBAO assumes they're in worldspace and converts them (as they truly are in later URP versions), this results in incorrect AO.
Left: URP 10.5.0 (Unity 2020.3.12f1 URP Sample project), Right: URP 12.1.6 (Unity 2021.2.17f1 URP Sample project)


It seems the cutoff for when they switched to world space normals is v12.0. Which is also unity 2021.1+ exclusive. So you can check for UNITY_2021_1_OR_NEWER

 

Thank you so much for feedback, the fix is available in latest release (3.4.10) as well as orthographic projection fix. Also I reduced the number of shader variants (@sabojako).

 

Is there any way of getting this to work with transparent objects? I know it's not physically correct but it's needed for a project. I'm using URP version 12.1.6, forward rendering.

 

My solution to this was to set the Per Pixel Normals from Camera to Reconstruct 4 Samples, in case anyone ever comes across this!

 

I have another issue, this time regarding the Offscreen Samples Contribution. See attached image. Is there any way of removing this offscreen contribution? The slider is already set to 0.

 

This is a general limitation of every SSAO technique, every screen space image effect (like SSAO, SSR) can exhibit artifacts on the edges of the screen. It can be obvious if you look at this debug mode but with composited image this is generally quite acceptable.
Offscreen sample contribution is to provide a constant contribution of samples taken on the edges to reproduce SSAO look on Unreal.

 

Do you think there is maybe a way (hack) to get around this? Perhaps there is a way to set a negative Offscreen Samples Contribution?

 

Keep in mind that getting ao contribution of a sample taken offscreen is like getting contribution of the edgemost pixel (because of depth/normals textures wrap mode and/or uv guard). Knowing that, we can easily realize that giving these samples an arbitrary contribution will lead to even more artifacts.

 

Does this have VR URP support and if so which "pass" modes does it support?

 

Heya! Is there a way to exclude a mesh from being affected by the HBAO?
I'd like for only the environment to be affected by ambient occlusion, not the characters.

 

On URP and HDRP both multipass and single pass instanced are supported. On builtin pipeline HBAO only supports multi pass and single pass stereo (double wide), single pass instanced is not supported there.

It's only possible on URP >= 10, when using LitAO mode you can set ao strength on your materials. On other pipelines this is not possible, HDRP might change to do like URP in the future but on builtin this is not going to change.

 

Thank you very much! That sounds like exactly what we need since we are using URP. Where do I find the LitAO mode you mentioned? I tried to google, but it didn't yield anything. Is it a parameter keyword for a shadergraph?

 

Sorry for the confusion, it's an HBAO setting. On URP it's topmost setting.

EDIT: to proceed excluding ao from your material, you create a lit shadergraph, adjust to your needs then you copy shader from shadergraph inspector, you create a shader with this code and you comment the lines containing _SCREEN_SPACE_OCCLUSION keyword.

 

I see! Thanks so much for the clarification! I found the keyword in the generated shader code. Is there no way to disable the keyword in the graph editor?

 

Apparently no, I tried overriding it but no luck. Maybe with a custom editor, not sure...

 

Is there any way to exclude a material from receiving HBAO? My character teeth looks really bad when I enable HBAO

 

It's only possible on URP >= 10, when using LitAO mode. On other pipelines this is not possible, HDRP might change to do like URP in the future but on builtin this is not going to change.

Also check this post on how to proceed for URP:
https://forum.unity.com/threads/hor...hbao-image-effect.387374/page-21#post-8078504

 

Does HBAO utilize URP motion vectors (in 2021.2)?
Also does it fully support 2021.2 for URP? (+deferred mode)

 

HBAO uses motion vectors in 2021.2 if temporal filtering is enabled.
HBAO suppors URP in 2021.2, deferred mode too but you need to select rendering path properly in HBAO options.

 

Unfortunately on the top of the screen it'll show some 'leaking' (?) ambient occlusion. The camera is set to orthographic, HBAO settings default (no offscreen samples contribution). Any fix for this?

 

I'm sorry for the inconvenience, this has been fixed in 3.4.11.
Please note that Reconstruct normal mode can still exhibit such bleeding (less pronounced however), because of unknown pixel depth outside screen for calculating normals.

 

Hey, there.

I am using HBAO(3.4.10) with a 3D model viewer that creates a mesh and displays the model in a runtime created with HDRP(12.1.6) in Unity(2021.3.1f1).
When viewing a semi-transparent model, ghosting like in the screenshot is now displayed.
This only occurs when HBAO is enabled.
We have confirmed that the initial settings for HBAO are correct and that AO is correctly applied to opaque objects.

Is there anything to fix this issue?

Also, a similar problem seems to have occurred in the past with UnitySSAO.
Now the SSAO has been corrected and the problem has been resolved.
https://forum.unity.com/threads/screen-space-ambient-occlusion-and-transparency.1081907/
https://github.com/Unity-Technologies/Graphics/pull/4025

 

Hi,
This is not the same issue as Unity's ssao.
Did it happened with previous Unity/HDRP versions?

Could you please send repro project?