Tune TAA disocclusion scale to avoid rejecting all samples during motion.

[clayjohn]

Noticed while reviewing #61834

The values we use for the disocclusion scale were a bit problematic. Basically they mean the following:
disocclusion_threshold: If the difference in velocity of this pixel between this frame and last frame is less than this amount, we can happily use the reprojected color. If the difference is greater we weight this frame more heavily (basically we assume there is a good chance that this pixel is the result of disocclusion)
disocclusion_scale: This scales the disocclusion amount (which is measured in pixels (difference_in_velocity - disocclusion_threshold)) to arrive at a final "disocclusion" value.

The final disocclusion value is used to weight towards the current sample. A disocclusion value of 1 means "throw away all previous samples". 0 means, this isn't a disoccluded pixel, blend it as normal.

As a result of having such high values, we pretty much always had a disocclusion value clamped to 1 if there was any movement at all.

https://www.elopezr.com/temporal-aa-and-the-quest-for-the-holy-trail/ has a nice breakdown of this type of disocclusion factor. The author uses 0.001 for threshold and 10 for scale. But they measure disocclusion in uv-space and we measure in texel-space. Accordingly, I increased/decreased the values by a factor of 1,000 and the results look a lot better.

They are most noticable in shadows with #61834 applied.

In this screenshot the camera is moving slowly. On the left is master, on the right is this PR

I tested this PR in a couple of scenes, both with and without #61834 and cannot see any signs of new ghosting or other artifacts that can come from improper disocclusion handling.

[mrjustaguy]

I think 2.5 pixels is a bit too much, as that'll allow pixels to bleed into neighbors up to 3 pixels away.

The optimal value is likely sqrt(2)/2 pixels as that is the distance between center of the pixel and corner of the pixel, and there's no point in going outside of the pixel's grid for reprojected samples, as they should be relevant for different pixels, but not the current one.

[clayjohn]

I think 2.5 pixels is a bit too much, as that'll allow pixels to bleed into neighbors up to 3 pixels away.

The optimal value is likely sqrt(2)/2 pixels as that is the distance between center of the pixel and corner of the pixel, and there's no point in going outside of the pixel's grid for reprojected samples, as they should be relevant for different pixels, but not the current one.

This isn't a pixel distance. Its a texel difference in velocities. Basically it says, if the velocity from last frame changes by less than this amount, treat it as if its the same pixel. IMO 2.5 is a really small amount and it would be safe to go up even higher

[mrjustaguy]

ah, I misunderstood the above in that case.

[Calinou]

Tested locally in https://github.com/Calinou/godot-reflection (CLI arguments: --write-movie output.avi --quit-after 600 -- --benchmark).

Video showcasing master 3524346 (left), PR rebased against master (right):

taa_comparison.mp4

TAA coverage seems a lot better with this PR, but it's blurrier and ghosting is a lot more common. Some stills showing ghosting:

On top of the staircase in the middle

Behind the ladder in the top-right corner

After fast camera movement, the PR has much better TAA coverage but it's also blurrier if you look at the sign or grass pot in the distance:

[mrjustaguy]

IIRC the adaptive box size is quite problematic, too high values and it'll ghost like crazy, too low values and it's a jittery mess.. Figuring out the proper function for calculating it would improve the ghosting seen in the stairs example, but figuring that out is a very big ask IMO

[clayjohn]

TAA coverage seems a lot better with this PR, but it's blurrier and ghosting is a lot more common. Some stills showing ghosting:

As mrjustaguy says solving this problem will be pretty challenging. The reason we didn't have any ghosting before is because we had no reprojection at all. Same thing with the perceived blurriness in motion, there was no blurriness before because there was no TAA

[Ansraer]

Hmm, looking at the blurrier textures seen in Calinou's last screenshot, I am wondering if this is caused by the camera jitter (which we need for TAA to work).

If so, we might be able to alleviate the problem by adjusting the texture coordinates in the fragment shader. The idea would be to move it in the opposite direction of the camera jitter to ensure that an object's textures are stable across several frames, which would reduce the blurring when TAA looks at past frames. I think I read about this technique somewhere a while ago, but can't remember where it was right now.

EDIT: I spent some more time staring at the screenshots, and I am getting more and more convinced that this could be needed. When you compare the yellow sign or the side of the stairs facing the camera, you can see that the textures suddenly look lower res than before.
If someone is working on TAA and wants to give this a shot, you can find the technique described in more detail here under "Texture Blurring"

[BastiaanOlij]

LGTM, seeing these values are sourced from the original implementation. From reading the reactions, it feels like we're just seeing TAA in action.

I suggest we merge this and see how people react to the visual change.

[akien-mga]

Thanks!