[Half-SOLVED] Can I modify the current SSAO shader ?

Hi guys, can I modify the current SSAO shader ?
Currently using not specific render-pipeline, just 3d-extra.
May I need to create a custom Render Pipeline project ? will some cgincludes file will be available to play with ?

Thx

 

ok, found this. Included a HLSL.



Finally I'm looking for where/when it's been applied... When it does it's "multiply"...

 

"cache" packages are pushed each time you open a Unity.exe
But they are like backup, no fetch realtime are apparently done to them, changing them have no effect. I'll try to import PostProcess Stack V2 manually but it cost 15$ on store, and free on GitHub. But since now Unity implemented it as a builtins, think the sources are hidden somewhere...

 

progress: I've followed the GitHub stack V2 install instructions.
1. Uninstall the PostProcess pack from the pack Manager
2. download the GitHub one and place it inside your project Asset: how to install it
than Unity will recognize the scripts, as the default one when it's time to create 3d volume, postprocess layer, and so on...

For the moment I found that running SSAO is not the Scalable.hlsl, but more the MultiScaleVO.shader that is effective.

I'll digg more, find the way of tweaking what I want and I'll share back.

 

PARTIALLY SOLVED:
I mean partially because yes it's easy to find the ScalableAO and MultiScaleVO shaders (the 2 SSAO options of Unity). You have access to the calculations, the passes blending modes, etc... But I can't find where I can get the image source (final render without post-process) that is getting stamped of the AO, like

col.rgb * ao

. Think the shader got just blended from C# ... Anyone knows ?

So, because my limited knowledge I decided to find and use another SSAO solution simply. On GitHub there's a bunch available. I started back with the Kino Obscurance :https://github.com/keijiro/KinoObscurance. That one ends with some

color.rgb * ao;

.

Finally sharing my goal related to the desire of modifying: SSAO is so wrong, I mean, yes is the best and cheap solution so far to get real-time occlusion "contact" with the these-days rasterizer. And we can't count how many game maker and even in pre-render are using a such solution. Already did that in the past; coloring the SSAO helps a little bit more toward reaching realism I think. But we're still far, far to get some screenspace diffuse lighting (screeenspace gi), or even ray-tracing the whole thing, lol. At least, coloring slightly the SSAO helps a lot, in my honest opinion. But it's dangerous... Any hack are dangerous...

I'm not coloring the SSAO, but more increasing the saturation of the current pixel simply. There's no relation or exchange in-between neighbor pixels or other material: I'm just saturating more where the SSAO is.

You see, adding gray or black everywhere is really wrong. No offense to the many good brains that came with this solution. But before jumping all to the ray-tracing era, I think there's room to improve some old techniques that we're comfortable with so far. Adding black for occlusion is not enough these days. Often, on corners, bounces will lose energy but also the end result will be more saturated. Of course I'm not taking into consideration the material type and its roughness. There's nice papers out-there that we're all integrating generally to get up-to-date about proper roughness impacting the diffuse rendering. But it's sort of the same situation at more large scale, in some cases... Yes often on my real-life examples, there's this overexposed lighting onto the front-face, or blueish environment that dimmed the saturation of the front-face, revealing maybe the real saturation of the material. But my idea, roughly holds it still; standard black SSAO will darker regardless the lighting type, keeping this unsaturated result. And those specific cases "where lighting is diminishing saturation"; you want back anyway some saturation in the corners and occluded parts.






Some lines added (sorry, it's not PBR and could be better writing I guess. But it's work as I want for the moment). In the "// Final composition shader "
Before returning color, I'm doing this:

Code (CSharp):

1. float AO = EncodeAO(ao);
2.  
3.     float colorAverage = (color.r + color.g + color.r) / 5;            // real average should be 3, but by playing with the divider it can create more gap in between the channels rgb
4.     float3 colDiff = (color - colorAverage);                        // storing each channels self-difference against the average
5.     float3 colSat = (color + colDiff)*0.9;                            // adding back their each differences from the average. Last multiplication *0.9 is to darken it more (1 nothing, 0.1 really dark), maybe the saturation will increase brightness...
6.  
7.     color.rgb = lerp(
8.         lerp(color, colSat, AO*1.5)*(1- AO *2.5),                    // AO define mask in-between the normal picture against the picture saturated+darkened. I intentionaly control its curve by contrasting it, frankly it's trial-errors here getting the desire result...
9.         color.rgb = color * (1 - AO),                                // Normal AO in Multiply
10.         0);                                                            // Saturation mode (0 not, 1 with saturation)
11.  

The results:
before/after


final saturated SSAO, not really before/after because it's hard to notice in still image. I don't want to go too cartoonish.


Next step could be to use the color.rgb and blur some version of it or try some screen-space diffuse-lighting.

Or I tought about exporting an ID buffer where it could be a scale of the saturation. On some plastic you want this effect more than for gray concrete.