← [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 :(

![Media 1](./media/1990260050485797063_1.png)

## 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.