[TRACKER] Rendering issues at very long distances (numerical precision)

[Flarkk]

This is a tracker dedicated to issues experienced when rendering at very long distances, i.e. involving very large camera far distance, very large and very far away geometry, lights with very long range, and all kinds of very large numbers in general.

Such scenes are very common in space settled games, open words, at-scale planets, and similar applications.
Godot currently offers a rather low level of support for such applications due to the many places numerical precision and overflow issues arise.

Sometimes these issues can be worked around with the double precision build, but many also involve numerical issues in the shaders as well, which makes having double precision in the core engine of little help.

Note : deep scenes rendering usually comes along with other related requirements like floating origin management, quadtree / octree scene partitioning or resource streaming. These are broader concerns that go beyond rendering and should not be tracked here.

Feel free to comment on this thread if you've identified or resolved issues not yet mentioned below !

Issues classification

🌌 : happens at galactic scale (numbers > ~1e+19m). Most often related to overflows in length calculations and normalizations of 32 bit vectors.

🪐 : happens at planetary scale (numbers > ~1e+6m). Most often related to numerical precision issues with near and far planes of 32 bit projection matrices

🏞️ : happens at walkable distances (numbers > ~1e+2m). Not deep scene issues strictly speaking, still mentioned because likely related

Issues list

Scene

• 🪐 Rendering fails when zfar > ~1e+6 times znear (Enable rendering with unbounded far distance #99986)
• 🪐 3D geometry cull failure and light flickering at particular camera far / near values #55070 (Enable rendering with unbounded far distance #99986)
• 🪐 Camera far distance is limited to 1,000,000 in editor (Support editing scenes of any large physical size #100896)

Lighting

• 🌌 Very far away point lights get culled (Prevent very far away point lights from being culled #98641)

Shadows

• 🪐 directional light shadows not working in large world #81877
• 🪐 Dual paraboloid texture may have NaN values for lights with very long range when blit from cubemap.
• 🪐 [glTF] Very high light range values of imported lights are causing shadows not to render #92551 (Fix shadows of long range OmniLight3D and SpotLight3D #100319)
• 🏞️ OmniLight3D Won't Cast Shadows Past a Distance of ~171 Units #96361 (Fix shadows of long range OmniLight3D and SpotLight3D #100319)

Shading

• 🌌 VIEW is NaN on very far away fragments
• 🪐 Precision-induced lighting failure on large objects on Android devices with Vulkan mobile renderer (solution provided) #86275

Geometry

• 🌌 Very large built-in sphere primitives have wrong normals (Fix normals of very large SphereMesh and CapsuleMesh #98610)

Effects

• 🌌 Crash with SDFGI and very large znear or zfar #99967 (Fix crash with SDFGI when zfar is very large #104120)
• 🪐 View Z-Far distance above 5000 causes SSAO banding in GLES3 #42390
• 🪐 Bokeh DOF blurs the whole screen when zfar > ~1e+6 times znear (Simplify depth reprojection code #99755)
• 🪐 No SSS when zfar > ~1e+6 times znear (Simplify depth reprojection code #99755)
• 🪐 No SSR when zfar > ~1e+6 times znear (Improve SSR raymarching performance #99693)

[roalyr]

I've gathered all my tweaks in a single commit for 4.x : master...roalyr:godot-for-3d-open-worlds:master and for 3.x: 3.x...roalyr:godot-for-3d-open-worlds:3.x
Just in case. I also think it is worth adding editor tweaks to the list (scene camera and in-game camera limits, editor zooming speed, grid and gizmos rendering precision, and so on).

[Zireael07]

Nit: I'd change the title to be "very large", as "deep" usually refers to the scene tree's complexity

[CodeSmith32]

Around 1 million units from the origin, large amounts of snapping and popping occur in the standard Godot build.

godot-precision-issue.mp4

Short of using the double-precision build of Godot and the two-float breakdown trick described here, there is only one workaround I know, but it does significantly increase the complexity of most projects (it also doesn't work in the editor, though that's slightly less important):

1. Move the world, not the camera.
2. Use multiple layers of coordinates for computing the player's 'virtual' position (really, the world's negative position).

• e.g., Use one Vector3 for coordinates within a 4,096^3 unit region, and a Vector3i which indicates which region the player is in.

Unfortunately, this is much easier said than done:

• Placing everything under a node and simply setting the node's position to the camera's negative position will probably have a similar effect on movement (and naturally so, since the float-based transform hits the same limits).
• Worse (please correct me if I'm wrong), in my experience, moving the world seriously screws with Godot's physics engine. Since physics run in a separate thread, I believe, when moving the world, sometimes only half the objects' physical bodies move within a physics frame. Thus, using any kind of snapping or jumping - like wrapping the player camera in a cell indexed by a Vector3i, and jumping the world when wrap occurs - would cause bodies to collide when they shouldn't, and at times that are unpredictable and very difficult to track.

[Flarkk]

@CodeSmith32 you're indeed pointing out the right two options :

• use the double-precision build
• or implement a "floating origin" system, i.e. leave the camera near the origin and move the rest of the world instead

The latter cannot be implemented by putting everything under a node and moving it to the camera's negative location. As you pointed out it would lead to the same numerical precision issues.

The simplest valid implementation I can think of is to derive a custom node type from Node3D that stores its real-world position as 3 float member variables (note that the float type is always 64 bits even in the single-precision build). Each frame, this node uses these 3 float to compute its relative real-world vector to the camera (another instance of this custom node also using 3 floats for positioning) and moves all its children accordingly using their built-in position. Create as much of these custom nodes as needed and parent your scene's objects to them with respect to their desired real-world position (assign objects that are too far apart to distinct parents).

If you're using physics, you'll have to provide a mechanism that ensures that this custom node type updates its physics children through their _integrate_forces() method. This is where you can access their PhysicsDirectBodyState3D and safely change their transform to arbitrary values without side effect.

[ARez2]

My issue ( #111521 ) might be related, but not sure

[CodeSmith32]

or implement a "floating origin" system, i.e. leave the camera near the origin and move the rest of the world instead

@Flarkk, I have yet to try this solution, but it sounds promising!