From 865f8c11915d275bc903b804633ce00adc57d783 Mon Sep 17 00:00:00 2001 From: Krishna Ayyalasomayajula Date: Sat, 30 May 2026 20:49:18 -0500 Subject: [PATCH] docs: add depth buffer acknowledgment to coordinate systems --- docs/concepts/coordinate-systems.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/docs/concepts/coordinate-systems.md b/docs/concepts/coordinate-systems.md index 5b1f037..706a55c 100644 --- a/docs/concepts/coordinate-systems.md +++ b/docs/concepts/coordinate-systems.md @@ -81,6 +81,14 @@ This step is automatic. You never write it in code. It is configured by the [vie You do write code to update the viewport transform — but only when the window size changes. At that point, you create a new `SurfaceConfiguration` with the new dimensions and configure the surface. The GPU then uses the updated mapping on subsequent frames. +## Depth and the Z Coordinate + +All three vertices of our triangle sit at Z=0 — exactly on the near plane. This is a simplification that works fine for a flat 2D triangle, but it means we carry no depth information. In a 3D scene with overlapping geometry, you need varying Z values so the GPU can decide which surfaces are in front of others. + +The mechanism that resolves this is the [depth buffer](GLOSSARY.md#depth-buffer). When enabled, the GPU allocates a per-pixel buffer storing the Z value of the closest surface rendered to that pixel. Each new fragment is compared against the stored depth: if the fragment is closer, it overwrites the pixel and updates the depth value; if it is farther away, it is silently discarded. This is how 3D scenes achieve correct occlusion. + +Our current pipeline does not use a depth buffer. For flat 2D rendering, draw order alone determines which geometry appears on top. Depth buffering will be covered in a future tutorial when we render 3D geometry. + ## Summary: The Coordinate Journey For our triangle, every vertex follows this path: