godot: 3D geometry cull failure and light flickering at particular camera far / near values

Godot version

3.4 stable

System information

Xubuntu 20.10 AMD 3020e, Vega3, GLES3

Issue description

In 3D at extremely low camera near and extremely high camera far values, geometry fails to be culled partially or completely when moving beyond camera far distance from the object. It also makes lights misbehave and flicker depending on the view angle.

Not critical but may be worth squashing. Can be avoided by using reasonable camera clipping planes distances.

Video demonstration of both effects

Steps to reproduce

Set camera_near >0.05, set camera_far 1000000 (maximum). Place large visible object at camera_far distance from camera, move camera away. If bug reproduces - the object won’t disappear or will flicker.

Place point light source at object location, make light distance >= camera_far, move camera away, while also looking at the source or away from it, observe the flickering.

Minimal reproduction project

My project release version that illustrates the bug

Suspected culprit for this bug may be a condition check at which fragments should be discarded (shader) or a piece of code the governs camera culling. Also it may be an issue related to floating point precision, or the code check that doesn’t take into account camera_near that small.

The workaround for light-related part of the issue seems to be in using larger light source range range and/or size with steeper curves on small lights.

About this issue

Original URL
State: open
Created 3 years ago
Comments: 36 (11 by maintainers)

Most upvoted comments

Here is a modified version of my project that illustrates the bug: https://github.com/roalyr/GDTLancer/releases/tag/v0.3-pre-alpha-bug-test

roalyr on Nov 19, 2021

This should solve it altogether, but z-far is not adjustable in my commit because I don’t know how to link editor settings (or camera settings): https://github.com/roalyr/godot-for-3d-open-worlds/commit/ddf5b01c04cc99236f1c76af83c96465ff12a69f

P.S.: the same should be applicable to z-near clipping plane since it is parallel to camera, so there is no need to recalculate plane.normal component every time from the camera matrix (as far as i understood), so it should be precision-error safe?

This also should eliminate the workaround related to light, since I have not noticed any flickering or light culling so far.

roalyr on Aug 4, 2023

@roalyr: Floating point accuracy, I imagine.

Zireael07 on Nov 22, 2021

I made a minimal reproduction project for 3.x: test_far_distance.zip

Some observations:

High Camera far distance seems to be doing its job fine. I don’t see anything particularly unexpected here, given the limits of 32-bit floating-point coordinates.
When the Camera far distance is 1,000,000, the near distance must not be set below 0.3126, or nothing will be drawn (I only see the background color instead). This may be worth investigating and fixing, since we can detect and clamp the near value according to the far value.

The video below demonstrates behavior with camera far distance 1,000,000 and near distance 0.3126. The “ship” moves at a speed that increases in an exponential-like fashion.

Epilepsy warning: Video contains rapid light flashes near the end.

https://user-images.githubusercontent.com/180032/142650516-dee65cad-ec7a-4aab-937a-e3b97125b252.mp4

Calinou on Nov 19, 2021