Bug Using NormalBuffer in a custom pass results in broken TAA

If I create a custom pass that relies on the normal buffer, say, like this:

Code (CSharp):

1. float4 FullScreenPass(Varyings varyings) : SV_Target
2.     {
3.         NormalData normalData;
4.         DecodeFromNormalBuffer(varyings.positionCS.xy, normalData);
5.         float3 normals = normalData.normalWS;
6.  
7.         return float4(normals.rgb, 1);
8.     }
9.  

Then I get this, when the custom pass writes directly to the camera and the camera moves:

Some artifacts like the black outline start to appear. There's also a little ghosting (watch the full video I'll link below).

Then I enable TAA on the camera:

We get heavy TAA artifacts during any movement.

Then I disable TAA and write the full-screen pass not to the camera but to the custom buffer, read it in shader graph and assign as the base color:

It's getting even worse

And then the worst scenario: custom buffer + TAA enabled:


So, any custom pass effect that is based on the normal buffer looks terrible in the movement. How do I fix it?

Full video:

 

Surprisingly, if I add this empty custom pass after mine, the artifacts disappear. The issue might be related to the depth buffer.

 

Thanks! Will try that.
What about the fact that there are artifacts even with TAA disabled? They are especially noticable when the custom pass outputs to the custom color buffer which is then sampled in SG.These are not typical ghosting/trailing artifacts. They look like "double-vision" effect, almost like the custom buffer lags behind or something, which results in what can be observed on the third screen from my original post.

 

Well, no. I have a single full screen custom pass with a single pass shader that writes to the custom color buffer which is sampled via the "Custom Color Buffer" node that is fed directly to the albedo input of the Lit SG which is applied to some objects in the scene. Which results in this:

Spoiler: Example 1

Spoiler: Example 2

In movement. The same effect is absent when this pass is applied directly to the camera. So the problem lies in the custom color buffer, I guess. I've tried all three possible formats of this buffer, with no luck.

I've also tried transparent lit SG, but it just can't correctly handle the custom color buffer at all. I've noticed that the problem is mostly present when two objects with the Lit SG where the sampling of the color buffer is performed overlap each other. Its' less visible when such objects overlap another with a different material and the issue goes away completely in the regions where such objects overlap the skybox:

Spoiler: Example 3

 

Btw, they have the same issues.
I created an empty scene with a pair of cubes, added your "scrolling formulas" custom pass, changed the picture of formulas to another texture. When it outputs to the camera - everything fine (just as with my custom pass):

Then I change the output to the custom buffer and plug this custom buffer straight to the albedo of the Lit graph which I apply to these cubes. And here we go:

This happens when I move my camera. This is exactly the same issue that I experience with my custom pass.

 

@antoinel_unity Can you take a look at this please, and maybe recommend something?
Thanks!

 

Bump.

 

I'm encountering some weirdness here too. Why doesn't the extracted normal buffer look the same as the "normals" extracted by AOV?

 

I found that this is not related to the normal buffer specifically. It seems like that when you sample the custom buffers in SG you get the previous frame data instead of the current one. Therefore it lags. Maybe there's something else, but even when I reconstruct normals from depth (so, no sampling of normal buffer) this bug steel occurs.

And there's literally no official example of a full screen custom pass writing to the custom color buffer and then SG successfully sampling from it. The documentation states that it's possible, but I don't see how it's possible without these artifacts.

 

Hi! It doesn't matter which injection point is used. Just for the sanity check I just went and checked again what happens if I use "After Opaque Depth And Normal". Nothing changes. The bug still there. Just as with any other injection point.
Please, take a look at this forum thread: https://forum.unity.com/threads/sampling-custom-pass-in-sg-is-broken.1277297/
It contains more info on the issue. For example, I've written there, that it doesn't matter which injection point is used.
Btw, have you tried it yourself? I understand that it should work with "After Opaque Depth And Normal" in theory, but in practice it doesn't work this way.

 

Thank you for the investigation!

Does it mean that this limitation makes custom passes virtually unusable for any more or less complex effects based on Normal / Roughness buffer when not in fully Forward mode then? If yes, you need to at least mention this in a number of places inside the docs very clearly.

 

Anything that needs normal data. You have such examples in your github repo. For example "Scrolling Formulas" effect. It won't work correctly when outputted through SG.

I guess using CustomPassUtils.RenderNormalFromCamera will do?