Enable rendering with unbounded far distance

[Flarkk]

This PR allows rendering with unlimited camera zfar - or rather limited by the sole floating point range i.e. ~3.4e+38 in single precision.

This effectively untaps the potential of reverse-z depth buffer with single precision build, in all 3 renderers Forward+, Mobile and Compatibility. XR is not covered though (see notes below).

Outline

Currently zfar cannot be pushed further than barely ~1e6 times znear because of numerical precision limitations with some methods of struct Projection.
With the default znear = 0.05 this sets the maximum view distance to ~50 km.
While it's enough in most cases, it can be a hard limitation for open worlds, space games, and any very large scene.
Beyond this limit, scene rendering currently breaks and Godot starts spaming errors.

This PR removes this limitation with 3 key changes :

• Stores the 6 frustum planes alongside the projection matrix in the rendering server's internals. Both are equivalent representations except that the former allows retrieving near/far distances and boundary points with much more accurate numerical precision
• Restricts the use of the matrix representation to the sole cases where projections / un-projections are performed. Use the 6 planes in any other situation (typically to retrieve znear / zfar, get boundary points, etc...)
• Bundles the 6 planes representation into a new struct Frustum with a few helper methods for convenience. This avoids relying of Vector<Plane> everywhere and improves readability

This PR is in a good enough state to get first reviews. There are still a few details to be ironed out though :

• The sky seems to mask some (but not all) far away objects - only in Compatibility and Mobile
• Objects farther than 1e20 disappear when Occlusion culling is on : fixed by Store view depth instead of ray length in occlusion buffer #100907

Demo : full-scale scene

large_zfar.zip

Vegetation is ~1m tall and ~10m from the observer
The terrain is 10 km large
The moon's radius is 1,700 km and is 400,000 km from the observer
The Andromeda galaxy is 152,000 light-years wide and is 2.5 million light years from the observer

Performance

This PR improves very slightly the frame process time of an empty scene by ~ 0.5%.
This is likely due to the significant number of planes retrieval operations avoided by the fact the 6 planes are already made available.

Before	After

Notes

• XR is left unchanged for now because this would require the XR APIs to return frustum planes in addition to the projection matrix. This may be the subject of another PR
• I spent a considerable amount of time making sure all effects work with large zfar. Some require additional PRs to be merged.
  Test project for effects : effects.zip (make sure to preview the large znear camera in each scene)

Effects	Works with large zfar	Issue
Bokeh DOF	✔️ with #99755
SSR	✔️ with #99693
SSIL	✔️
SSAO	✔️
Sky	✔️	Sometimes hides far away objects in Compatibility and Mobile ?
Shadows	✔️
SDFGI	❌	Crash with zfar or znear > ~1e+20 : #99967
SSS	✔️ with #99755
Fog	✔️

• Add tests for Camera3D frustum functions #99961 and Add tests for Viewport's camera override functions #99962 help ensuring non-regression on Viewport and Camera3D

Closes godotengine/godot-proposals#10515
Closes #55070
Supersedes #95944

[Flarkk]

Rebased and fixed style issues to allow CI to run.

[Flarkk]

Rebased on top of #99974

[Calinou]

Objects farther than 1e20 disappear when Occlusion culling is on

This can probably be worked around by assuming the object is visible when it's further away from the camera than this distance (and skipping any occlusion culling checks).

Embree doesn't support double precision, so precision=double builds can't do any better here.

[Flarkk]

Haven't got back to this PR yet, but I think it's likely caused by an overflow with normalize() or length() somewhere.

1e19 ~ 1e20 is the threshold value that exceeds the maximum representable float value when squared (~1e38).

If this overflow happens in Embree then yes, we don't have any other choice but trying to work around it. Will take a look at your suggestion once I complete the work on another incoming related PR : uncapping zfar in the editor itself.

[Flarkk]

I got the culprit : indeed a call to length() that overflows on very far away geometry :

godot/servers/rendering/renderer_scene_occlusion_cull.h

Line 75 in efa1443

float min_depth = (closest_point - p_cam_position).length();

Just issued #100907 that solves the problem, and enables proper occlusion culling even on very far away objects.

---

Edit : turns out that this fix inadvertently reverts another fix. I'm figuring out alternatives