[rlgl] Proposed fix for default near/far clipping range

[Bigfoot71]

I've noticed the default near and far clipping planes were recently changed, and I'd like to suggest a fix

The current range [0.001, 10000.0] feels excessive and hard to justify

The near plane is too close, which can cause depth buffer precision issues and visual artifacts, while a far value of 10000.0 seems unnecessarily high for a default here

If the intent was to increase the far plane, a more reasonable default would be [0.05, 4000.0], offering a better balance between depth precision and visible range

For special cases, rlSetClipPlanes already exists to override these defaults anyway

---

Here is a visual example using shadow mapping, where the scene depth (from the camera's point of view) was projected with a near/far range of [0.001, 10000.0]:

simplescreenrecorder-2025-04-22_15.10.23.mp4

And here is an example with [0.05, 4000.0]:

simplescreenrecorder-2025-04-22_15.10.48.mp4

[raysan5]

@Bigfoot71 note that near/far values were reviewed recently to work on Orange Pi with PLATFORM_DRM, when I tried with lower ranges I got a lot of clipping in the platform due to the depth buffer bit-limitations. Also increases depth buffer requested to be at least 24 bit. Have you tried this fix in some low-end OpenGL ES device?

[Bigfoot71]

@raysan5 Ah, was it a fix for 16-bit buffers?

Why not apply this range of 0.001/10000.0 based on the default depth buffer precision?
Because it might also become problematic in the long run for even more cases

I don't have a device that doesn't support 24-bit depth buffers, but I can try forcing the creation of a 16-bit buffer and see.

[Bigfoot71]

@raysan5 I just ran some tests with a 16-bit depth buffer set via glfwWindowHint(GLFW_DEPTH_BITS, 16); using GLFW

Here is an example with the current planes 0.001 / 10000.0:

simplescreenrecorder-2025-05-04_13.41.46.mp4

And here is an example with 0.05 / 4000.0 as suggested:

simplescreenrecorder-2025-05-04_13.42.22.mp4

The scene consists of a 1000x1000 plane and a 1x1x1 cube

[raysan5]

@Bigfoot71 thanks for the further review, I'm merging those new values, let's hope it works on most devices. Now raylib defaults to 24 bits depth buffers so it should be good on most devices...

This improvement maybe also addresses #4917

[Bigfoot71]

@raysan5 What I proposed will definitely work on a 24-bit depth buffer as well, and even offers better stability than the old old 0.01 / 1000.0, with the added benefit of a much farther far plane.

If any other issues are reported regarding this, it should be possible to handle it adaptively during rlgl initialization with something like:

GLint depthBits;
glGetIntegerv(GL_DEPTH_BITS, &depthBits);

switch (depthBits) {
case 16:
    rlSetClipPlanes(0.5, 400.0);
    break;
case 24:
case 32:
    rlSetClipPlanes(0.05, 4000.0);
    break;
}

---

Edit

Note that 0.05 / 4000.0 is also the default used by Godot. If strange issues still occur on certain hardware that may be less standard in some operations, the most reliable approach in my opinion is to align with other engines.

Unity has a default range that’s tighter, 0.3 / 1000.0 if I remember correctly, adopting these values could be a prudent fallback if any inconsistencies arise.