Use distance to camera in light and decal distance fade calculations

[Calinou]

This also uses a smoother fading formula for Decal distance fade (same as OmniLight and SpotLight), superseding #58298 in the process.

I found this fix while working on a 3.x backport of #58512.

This closes #58513.

Testing project: test_light_decal_distance_fade.zip

[clayjohn]

Is there a compelling reason to use camera depth here instead of just using distance everywhere?

[Calinou]

I don't know if the clustering code expects the distance to be "flat" (relative to the camera frustum). I kept it this way to avoid regressions.

[clayjohn]

One problem we are going to face here is that we don't propogate camera information all the way through the rendering pipeline. We don't even know if the camera is perspective or orthogonal. We may have to pass more information down to the functions to make sure that we properly compute distance in both cases

Edit: actually it wont be too bad, we can just propogate more information, everything we need is in the RenderData struct

[Calinou]

Rebased and tested again, it works as expected. I added a testing project to OP as well for testing all kinds of distance fade (including GeometryInstance3D visibility range).

We don't even know if the camera is perspective or orthogonal.

Distance fade currently appears broken when the camera is orthogonal, but this is also an issue with GeometryInstance3D visibility range in master. We could try fixing all three in this PR, or do it in a separate PR.

[clayjohn]

As discussed here and in my comment above, we need to maintain the old behaviour for orthogonal cameras. The old depth calculation is correct for orthogonal cameras. My guess is that even the clustering code should use distance to camera instead of plane, even when using a perspective camera, but that theory will need to be tested

In 3.x the code is:

if (p_cam_orthogonal) {
	ins->depth = near_plane.distance_to(aabb_center);
} else {
	ins->depth = p_cam_transform.origin.distance_to(aabb_center);
}

[clayjohn]

Its probably better to do a multiply instead of a pow() call. Looking around online it sounds like GCC with -O3 optimizes pow(x, 2) to about the same as x*x but many other combinations of compiler/settings don't

[clayjohn]

I really want to get this in before release, so are you okay if I make a PR to your branch to fix up my comments and make a few other little changes?

[Calinou]

I really want to get this in before release, so are you okay if I make a PR to your branch to fix up my comments and make a few other little changes?

Sure 🙂

[clayjohn]

Superseded by #71709