Apply reprojection in multiview for our cluster lookup

[BastiaanOlij]

When rendering in stereoscopic we're seeing decals being cutoff in our Forward+ renderer:

This is caused by the way we filter which decals are processed when processing fragments. This is the bit that makes a forward+ renderer a forward+ renderer. In a pre-process we divide the screen into "tiles" and for each tile we determine which lights and decals effect fragments within that tile. It's a very efficient way of doing this however for multiview the current solution does this only in "combined frustum" space. As we lookup our tiles when rendering one of our eyes, we're lookup the wrong tile causing us to only partially see our decals.

Note that this issue also effects lights but it is often harder to spot.

This PR fixes this issue by performing an extra projection of our vertex in combined frustum space and using that to look up the correct tile.

Note: this "reprojection" only works because we do not take the depth buffer into account while building our light cluster data. Using the depth buffer is an often used optimisation which would be possible if we move the cluster logic after our depth pre-pass. This would allow us to filter out lights/decals that are obscured and give a tiny potential performance boost.
IF we ever decide to implement this we need to make this optional as it will break the reprojection trick as lights/decals may be obscured in our combined frustum but not in one of the eyes.

Sample project:
TestStereoDecal.zip

Fixes #60680

[Stellanora64]

Will this also fix #60680 ?

[BastiaanOlij]

Will this also fix #60680 ?

No, but thanks for reminding me of that one, I'll have a look on why thats going wrong next.

[BastiaanOlij]

@Crusher50 Actually I'm going to restate my answer, this may fix it, or at least some of it. Re-reading the discussion on that issue that does look like a clustering issue. I thought there as a problem with the quality of the spotlight itself but that may have been a different issue (where a low resolution shadowmap is being used).

This indeed looks like an issue where the tile being used isn't correct, at least for the OP problem. The screenshot later on where attenuation is set to a low value will probably still be broken, that is simply that the light volume used to populate the tiles isn't large enough to encompass the light.

[BastiaanOlij]

Yup, fixes #60680

[clayjohn]

Looks great!

[akien-mga]

Thanks!