Logarithmic Depth Buffer for Astronomical glTF

Astronomical glTF models frequently suffer from severe z-fighting because standard perspective projection places almost all depth precision near the near clipping plane, leaving distant celestial bodies spanning millions of kilometers competing for the same few depth values. Implementing a logarithmic depth buffer redistributes this precision exponentially across the entire view frustum, allowing render engines to accurately sort geometry from planetary surfaces up to interstellar scales within a single rendering pass without flickering or visual artifacts.

The Scale Challenge in Astronomical Scenes

A standard glTF model rendering in WebGL or WebGPU uses a 24-bit or 32-bit depth buffer tied to a standard perspective projection matrix. In this setup, depth precision falls off with the reciprocal of distance (\(1/z\)). In astronomical visualizations, the ratio between the far clipping plane (\(10^{12}\text{ m}\)) and the near clipping plane (\(1\text{ m}\)) is astronomically high. Consequently, two planetary bodies, rings, or satellite orbits separated by thousands of kilometers at a distance can map to identical floating-point depth integers, triggering aggressive z-fighting.

Fragment-Based Logarithmic Depth

The most accurate method to solve this in glTF engines is computing depth directly in the fragment shader and writing to the depth buffer via gl_FragDepth.

The standard logarithmic mapping function is expressed as:

\[z_{\text{log}} = \frac{\log(C \cdot w + 1.0)}{\log(C \cdot \text{far} + 1.0)} \cdot w\]

Where:

  • \(w\) is the clip-space view distance (often the interpolated view-space \(z\)).
  • \(C\) is a constant factor determining resolution near the near clipping plane.
  • \(\text{far}\) is the distance to the far clipping plane.

By executing this calculation inside the fragment shader, modern glTF renderers ensure that depth values are calculated per-pixel rather than linearly interpolated across large polygons. This prevents curvature artifacts and clipping errors on massive celestial spheres composed of low-to-medium triangle densities.

Vertex-Based Logarithmic Depth

For hardware setups where writing to gl_FragDepth disables early-z optimizations and lowers fill rates, a vertex-stage logarithmic depth calculation can be used. The vertex shader maps the clip-space \(z\) coordinates logarithmically before passing them to rasterization:

\[z_{\text{clip}} = \left( \frac{2.0}{\log(C \cdot \text{far} + 1.0)} \cdot \log(C \cdot z_{\text{eye}} + 1.0) - 1.0 \right) \cdot w_{\text{clip}}\]

While this preserves early depth testing, it introduces non-linear interpolation across polygon faces. To prevent distorted clipping boundaries when using glTF models under this approach, meshes must be sufficiently tessellated so that vertices are closely spaced relative to the camera view.

Reversed-Z Floating Point Alternative

When native floating-point depth buffers are available (such as in WebGPU or desktop OpenGL/Vulkan contexts running glTF pipelines), an inverted floating-point depth approach (Reversed-Z) is often preferred over logarithmic depth.

Reversed-Z maps the near plane to \(1.0\) and the far plane to \(0.0\) using a 32-bit floating-point depth buffer (DEPTH_COMPONENT32F). Because IEEE 754 floating-point numbers have greater precision near zero, reversing the range aligns natural float precision with far-plane requirements. This eliminates the need for expensive logarithmic math in fragment shaders while resolving z-fighting across dynamic ranges exceeding \(1:10^9\).

Engine Configurations for glTF

Astronomical engines implement these logarithmic techniques natively for glTF pipelines through specific configuration steps:

  • Three.js: Enabling logarithmicDepthBuffer: true on the WebGLRenderer. This injects logarithmic depth calculations directly into standard glTF material shaders (MeshStandardMaterial, MeshPhysicalMaterial).
  • CesiumJS: Employs a multi-frustum logarithmic rendering technique combined with custom shaders that dynamically segment astronomical space into near, mid, and deep-space rendering bands to preserve sub-millimeter precision on planetary terrain while drawing distant celestial objects.
  • Babylon.js: Supports logarithmic depth through the engine's material flags (useLogarithmicDepth = true), modifying shader chunks during glTF asset compilation.

Mitigating Floating-Point Vertex Jitter

A logarithmic depth buffer resolves depth-buffer precision, but astronomical glTF assets can still exhibit vertex jitter due to 32-bit single-precision float limitations in standard GPU vertex transformations. For complete rendering stability, logarithmic depth must be paired with Relative-to-Center (RTC) rendering or floating-point camera offsets, where the camera's coordinates are subtracted from the glTF model's world coordinates on the CPU using 64-bit precision before passing the transformation matrix to the GPU.