WebGLRenderer: add reverse-z via EXT_clip_control #29445
+104
−1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Related issue: #22017 (comment)
Description
Implements a reversed depth buffer with a [0, 1] projection matrix via
EXT_clip_control
, which is a strict improvement over logarithmic depth where supported. A reverse depth buffer exploits the high precision range of [0, ~0.8] and inverts depth to better the distribution at distance. This is not only significantly faster than logarithmic depth (where use ofgl_FragDepth
disables early-z optimizations and MSAA coverage) but more accurate. See the below articles, which visualize this effect.https://tomhultonharrop.com/mathematics/graphics/2023/08/06/reverse-z.html
https://developer.nvidia.com/blog/visualizing-depth-precision
As both a [0, 1] and reversed projection matrix would require drastic changes to sensitive code like frustum planes or raycasting, I've hidden both conversions when setting the
projectionMatrix
uniform inWebGLRenderer
. It's possible this can be moved to a shader chunk, but any inline clip-space math must account for this mode, and we'll need to add a shader define accordingly.The same is true for logarithmic depth, e.g., pmndrs/drei#1737. I've debated adding methods to packing chunks for these.