Private
Public Access
59 lines
3.3 KiB
Markdown
59 lines
3.3 KiB
Markdown
← [Back to Twitter thread index](../README.md)
|
||
|
||
---
|
||
title: "I wish everyone would just adopt "reversed with infinite far" projection matrixe"
|
||
author: "NOTimothyLottes"
|
||
handle: "@NOTimothyLottes"
|
||
post_url: "https://x.com/NOTimothyLottes/status/1990260050485797063"
|
||
post_id: "1990260050485797063"
|
||
timestamp: "2025-11-17 03:25:47"
|
||
post_count: 9
|
||
reply_count: 5
|
||
repost_count: 2
|
||
like_count: 85
|
||
view_count: 6057
|
||
---
|
||
|
||
# @NOTimothyLottes — I wish everyone would just adopt "reversed with infinite far" projection matrixe
|
||
|
||
## Post 1 (2025-11-17 03:25:47)
|
||
|
||
I wish everyone would just adopt "reversed with infinite far" projection matrixes so I could only optimize for the fastest and highest precision option, but I'm guessing people haven't all migrated over :(
|
||
|
||
|
||
|
||
## Post 2 (2025-11-17 03:28:35) — reply to Post 1
|
||
|
||
Reversed is a significant improvement but it still has its limitations when doing planetary-scale rendering that needs good precision up both close and far away. Your options there are either a logarithmic depth buffer to linearize things (albeit losing early z), your own integer-based depth test system in compute shaders, or a stack of multiple frustums layered on top of one another.
|
||
|
||
## Post 3 (2025-11-17 03:31:41) — reply to Post 2
|
||
|
||
@AgileJebrim Yes for my non-tri stuff I'm log depth already. This is just for games, not simulation.
|
||
|
||
## Post 4 (2025-11-17 03:41:27) — reply to Post 3
|
||
|
||
Simulation can usually localize enough that reverse Z is good enough. Google Earth style geospatial visualization is where things get trickier.
|
||
|
||
Another option is to dynamically change the far plane, moving it closer as you get closer to the terrain and further back as you move further back. I don’t think I tried this one but I imagine it requires a lot of tuning.
|
||
|
||
## Post 5 (2025-11-17 05:03:02) — reply to Post 1
|
||
|
||
@NOTimothyLottes I've never had real depth precision issues in our game ports but I guess I'd better just adopt and get used to reversed infinite projection cause it's objectively better. Promise to try it for our next project :)
|
||
|
||
## Post 6 (2025-11-17 05:06:11) — reply to Post 1
|
||
|
||
@NOTimothyLottes Many are still on OpenGLES and WebGL, which don’t properly support inverse depth due to still using a -1 to 1 clip space. Not really a problem for inverse depth in its own, but does cause problems for infinite far depth.
|
||
|
||
## Post 7 (2025-11-18 16:26:49) — reply to Post 1
|
||
|
||
@NOTimothyLottes Infinite far doesn’t apply to ortho, and many of editors/engines need to switch camera viewports. But it’s great for persp. Also too much code handing modeInv for normals, which is wrong and unneeded.
|
||
|
||
## Post 8 (2025-11-19 18:56:58) — reply to Post 1
|
||
|
||
@NOTimothyLottes I haven't really done graphics in a while, but I've never heard about infinite far nor reversed z, where can I read up on it more?
|
||
Some cursory googling didn't return anything useful on this topic.
|
||
|
||
## Post 9 (2025-11-20 03:47:56) — reply to Post 8
|
||
|
||
@stainless_code I put some docs (based on an old blog post) on projection matrix stuff inside STP source: https://github.com/Unity-Technologies/Graphics/blob/master/Packages/com.unity.render-pipelines.core/Runtime/STP/Stp.hlsl - Documents the maths to take depth and 2 projections and get a static reprojection vector for example.
|