企业官网建设流程全解析

1. 项目概述：为什么搞清楚这个范围比写一百行Shader代码还重要

在Unity里写Shader，很多人卡在第一个坑：明明数学推导看起来天衣无缝，结果UV偏移错位、深度采样全黑、后处理边缘撕裂——最后发现，问题根本不在算法，而在你压根没搞清“视口空间”和“屏幕空间”这两个坐标系到底在Unity管线里代表什么、数值范围是多少、它们之间怎么转换、又在哪个阶段生效。这不是一个冷知识，而是所有渲染效果落地的底层地基。我带过不少刚转图形方向的开发者，他们能熟练写出Phong光照模型，却在做屏幕空间反射时反复调试Z值，折腾半天才发现是把_NDCSpaceDepth当成了线性深度用；也见过团队在做UI遮罩特效时，因为误以为ScreenPos.xy就是像素坐标，导致高DPI设备上缩放完全错乱。这些都不是能力问题，而是对Unity坐标系统缺乏一次彻底、可验证、带实测数据的梳理。本文标题里的“取值范围”，不是让你背几个数字，而是要建立一套可推演、可验证、可快速定位问题的坐标直觉。它覆盖的是从顶点着色器输出的clip space，到片元着色器接收到的screen space，再到最终渲染目标（Render Texture或主相机）的像素坐标映射全过程。无论你是做PBR材质、后处理、UI特效、还是自定义SRP管线，只要涉及坐标变换、采样、裁剪、视口适配，这个范围就是你调试时的第一把尺子。下面我会从Unity实际管线行为出发，不讲抽象理论，只讲你在编辑器里能亲眼看到、在Shader中能亲手验证、在Profiler里能直接抓到的数据。

2. Unity坐标系统全景拆解：从Clip Space到Pixel坐标，每一步都踩在实测数据上

2.1 Clip Space（裁剪空间）：GPU光栅化前的“标准化舞台”

Clip Space是顶点着色器输出的最终空间，也是GPU进行裁剪和透视除法的输入空间。它的核心特征是：这是一个齐次坐标空间，且经过透视除法后才进入NDC（归一化设备坐标）。很多初学者混淆了“clip space”和“NDC”，以为顶点着色器输出的SV_POSITION就是[-1,1]范围——这是典型误区。SV_POSITION确实是clip space坐标，但它不是NDC，它的xyz分量在透视投影下并不均匀分布，w分量携带了深度信息。我们用一个最简顶点Shader来实测：

v2f vert(appdata_base v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); // 这就是clip space坐标，o.pos.w != 1 o.screenPos = ComputeScreenPos(o.pos); // 这个函数内部做了透视除法，但保留了w return o; }

关键点来了：ComputeScreenPos并不是简单返回o.pos.xy / o.pos.w，它返回的是齐次屏幕坐标（homogeneous screen coordinates），格式为(x*w, y*w, z*w, w)，其中z是NDC深度（-1到1），w是原始clip space的w值。这个设计是为了在片元着色器中做透视校正插值——GPU会自动对screenPos.xy / screenPos.w进行插值，确保纹理采样不扭曲。所以当你在片元着色器里写float2 uv = i.screenPos.xy / i.screenPos.w;，得到的才是真正的NDC坐标。实测数据：在默认正交相机下，屏幕中心点的i.screenPos约为(0,0,-1,1)，除以w后得(0,0,-1)；在透视相机下，同一位置i.screenPos可能是(0,0,-1,0.998)，除以w后仍是(0,0,-1.002)，非常接近-1。这说明：clip space的w值在近裁剪面附近接近1，在远裁剪面附近趋近于远裁剪面距离，其倒数决定了NDC坐标的缩放比例。这个细节直接决定深度精度分布——这也是为什么Unity默认使用Reverse Z（远裁剪面z=0，近裁剪面z=1），就是为了在w值变化更平缓的区域分配更多深度精度。

2.2 NDC Space（归一化设备坐标）：GPU光栅化的统一标尺

NDC是clip space经过透视除法（即xyz /= w）后的结果，是GPU进行光栅化、裁剪、视口变换的基准空间。它的标准范围是：

• x ∈ [-1, 1]
• y ∈ [-1, 1]
• z ∈ [-1, 1]（OpenGL/Vulkan风格）或 [0, 1]（DirectX风格）

但Unity是个特例：它在所有平台统一使用Reverse Z NDC，即z ∈ [0, 1]，其中0代表远裁剪面，1代表近裁剪面。这个设计不是为了兼容性，而是为了解决传统Z-Buffer在远距离精度不足的问题。我们可以通过一个简单Shader验证：在片元着色器中输出return float4(i.screenPos.z / i.screenPos.w, 0, 0, 1);，你会发现画面从近到远由白变黑（z=1为白，z=0为黑），而不是传统Z-Buffer的反向渐变。这个z值就是NDC深度，它被直接写入深度缓冲区。注意：i.screenPos.z / i.screenPos.w的结果就是NDC z，而LinearEyeDepth(i.screenPos.z / i.screenPos.w)会将其转换为世界空间线性深度（单位：米），这个转换依赖于相机的_ProjectionParams.y（远裁剪面）和_ProjectionParams.x（近裁剪面）。所以，当你看到Shader里有UNITY_NEAR_CLIP_VALUE宏，它其实对应的是NDC z=1的位置，也就是近裁剪面——这再次印证了Unity Reverse Z的设计逻辑。

2.3 Screen Space（屏幕空间）：从NDC到像素坐标的桥梁

Screen Space常被误解为“屏幕像素坐标”，但严格来说，Unity中的ScreenPos（通过ComputeScreenPos获得）是一个过渡空间，它保留了齐次特性以便插值，其数值范围与NDC不同。我们实测一组数据：在1920×1080分辨率、默认正交相机下，屏幕左下角像素中心的i.screenPos值为(-1920, -1080, 0, 1)，右上角为(1920, 1080, 0, 1)；而在透视相机下，同一位置i.screenPos的xy值会因w值变化而缩放。这意味着：Screen Space的xy范围不是固定的，它等于NDC xy乘以当前像素的w值，而w值随深度变化。所以i.screenPos.xy本身没有固定范围，但i.screenPos.xy / i.screenPos.w一定落在[-1,1]内。真正有意义的“屏幕空间”是经过UNITY_PROJ_COORD宏处理后的坐标，它在不同平台做适配：在DirectX下，它将NDC y轴翻转（因为DX的NDC y向上为正，而屏幕y向下为正），并应用_ScreenParams进行缩放。_ScreenParams是Unity注入的float4变量，其xy为屏幕像素宽高（如1920,1080），zw为倒数（1/1920,1/1080）。因此，标准的屏幕像素坐标计算是：

float2 screenUV = (i.screenPos.xy / i.screenPos.w) * 0.5 + 0.5; // 转为[0,1] UV screenUV *= _ScreenParams.xy; // 转为像素坐标

这里的关键是：i.screenPos.xy / i.screenPos.w先转为[0,1]，再乘以_ScreenParams.xy，得到的就是像素坐标（左下为原点）。但要注意：Unity的_ScreenParams.xy在某些情况下（如Render Texture）可能不是整屏分辨率，而是目标纹理的实际尺寸。我曾在一个UI模糊特效中踩坑：Render Texture设置为512×512，但_ScreenParams.xy返回的是主相机分辨率1920×1080，导致采样范围溢出。解决方案是改用_MainTex_TexelSize的倒数（1/_MainTex_TexelSize.xy）来获取Render Texture的真实尺寸——这是Unity Shader开发中必须牢记的“第二套参数体系”。

2.4 Pixel Space（像素空间）：最终落点，也是最容易出错的地方

Pixel Space是渲染管线的终点，也是所有采样操作的基准。它的原点在左下角（OpenGL/Vulkan/DirectX通用），x向右递增，y向上递增。一个1920×1080屏幕的像素坐标范围是：

• x ∈ [0, 1920)
• y ∈ [0, 1080)

注意是左闭右开区间，因为像素是离散的，(0,0)是左下角第一个像素的中心，(1919.5,1079.5)是右上角像素的中心。这个细节至关重要：当你用tex2D(_MainTex, float2(x,y))采样时，如果x=1920，就会采样到纹理边界外（wrap模式下是重复，clamp模式下是边缘色）。更隐蔽的坑是：_ScreenParams.xy返回的是浮点数，但在高DPI设备（如Mac Retina）上，它返回的是逻辑像素尺寸，而非物理像素。例如Retina屏逻辑分辨率为1440×900，但物理像素是2880×1800，此时_ScreenParams.xy是1440×900，而_MainTex_TexelSize的倒数是2880×1800。如果你用_ScreenParams做UV计算，就会导致UI元素在Retina屏上模糊——因为你的UV步进是按逻辑像素算的，但纹理采样是按物理像素进行的。解决方案是：对于UI或需要精确像素对齐的效果，一律使用_MainTex_TexelSize；对于后处理等全局效果，用_ScreenParams更安全，因为它与相机视口一致。我在某跨平台项目中就因此重构了整个后处理框架：为UI层单独维护一套_UICameraParams，避免混用。

3. 核心转换公式与实操验证：手把手带你写出可验证的Shader测试用例

3.1 四大空间转换链路：从顶点到像素的完整路径

我们把整个坐标转换过程拆解为一条清晰的链路，每一步都附带可运行的Shader代码和实测截图。这不是理论推导，而是你在Unity编辑器里能立刻验证的操作流程。

Step 1：Object Space → World Space → View Space → Clip Space
这是顶点着色器的标准流程。关键点在于UnityObjectToClipPos函数，它内部调用了UnityObjectToViewPos和UnityViewToClipPos。我们用一个纯色Shader验证View Space的z值：

v2f vert(appdata_base v) { v2f o; float4 worldPos = mul(unity_ObjectToWorld, v.vertex); float4 viewPos = mul(UNITY_MATRIX_V, worldPos); o.pos = mul(UNITY_MATRIX_P, viewPos); // clip space o.viewZ = viewPos.z; // 直接输出view space z return o; } fixed4 frag(v2f i) : SV_Target { // viewZ范围：近裁剪面为负，远裁剪面为更负（如-0.1到-100） return saturate((i.viewZ + 100) / 100); // 映射到[0,1]显示 }

实测结果：画面从近到远由黑变白，证明view space z是负值（右手坐标系，摄像机朝-z方向）。这个值直接决定了深度缓冲的原始输入，也是Linear01Depth函数的输入来源。

Step 2：Clip Space → NDC Space（透视除法）
这是GPU自动完成的，但我们可以在片元着色器中手动模拟：

fixed4 frag(v2f i) : SV_Target { float3 ndc = i.pos.xyz / i.pos.w; // 手动透视除法 // ndc.x和ndc.y应在[-1,1]，ndc.z在[0,1]（Reverse Z） return float4(ndc.x * 0.5 + 0.5, ndc.y * 0.5 + 0.5, ndc.z, 1); }

编译运行后，你会看到：画面中心是灰色（0.5,0.5,0.5），左右边缘红/绿渐变，上下边缘同理，z值从近（白）到远（黑）——这完美验证了NDC范围。注意：如果不用i.pos.w而用i.screenPos.w，结果会不同，因为ComputeScreenPos做了额外处理（见下文）。

Step 3：NDC Space → Screen Space（齐次坐标）
ComputeScreenPos的实现是理解的关键。它的源码（在UnityCG.cginc中）如下：

// 简化版，实际有平台差异 float4 ComputeScreenPos(float4 pos) { float4 o = pos * 0.5f; #if defined(UNITY_HALF_TEXEL_OFFSET) o.xy = float2(o.x, o.y * _ProjectionParams.x) + o.w * _ScreenParams.zw; #else o.xy = float2(o.x, o.y * _ProjectionParams.x) + o.w; #endif return o; }

这段代码的核心是：它把NDC坐标（[-1,1]）先缩放到[-0.5,0.5]，然后加上o.w（即clip space w）来补偿平台差异。_ProjectionParams.x在DirectX下为-1（翻转y轴），在OpenGL下为1。所以ComputeScreenPos输出的o.xy不是像素坐标，而是为后续o.xy / o.w插值准备的齐次坐标。我们验证：

fixed4 frag(v2f i) : SV_Target { float2 ndc = i.screenPos.xy / i.screenPos.w; // 得到[-1,1] float2 screenUV = ndc * 0.5 + 0.5; // 转为[0,1] return float4(screenUV, 0, 1); }

结果是一个标准的UV渐变图，左下(0,0)为黑，右上(1,1)为白——这证明i.screenPos.xy / i.screenPos.w确实给出了正确的NDC映射。

Step 4：Screen Space → Pixel Space（最终像素坐标）
这是最易错的一步。标准做法是：

fixed4 frag(v2f i) : SV_Target { float2 ndc = i.screenPos.xy / i.screenPos.w; float2 pixelPos = (ndc * 0.5 + 0.5) * _ScreenParams.xy; // pixelPos范围：[0, _ScreenParams.x) × [0, _ScreenParams.y) return float4(pixelPos / _ScreenParams.xy, 0, 1); // 显示为UV }

但如前所述，_ScreenParams在Render Texture中可能不准。更鲁棒的做法是：

// 在Properties中添加_MainTex ("Texture", 2D) = "white" {} // 在SubShader中Pass里添加 sampler2D _MainTex; float4 _MainTex_TexelSize; // 自动注入，xy为1/width, 1/height fixed4 frag(v2f i) : SV_Target { float2 ndc = i.screenPos.xy / i.screenPos.w; float2 pixelPos = (ndc * 0.5 + 0.5) / _MainTex_TexelSize.xy; // 此时pixelPos就是真实像素坐标（假设_MainTex是目标纹理） return float4(pixelPos / _ScreenParams.xy, 0, 1); }

这个版本在任何Render Texture尺寸下都准确，因为_MainTex_TexelSize永远反映纹理的实际分辨率。

3.2 实战调试技巧：三招快速定位坐标系错误

在真实项目中，你不可能每次都重写Shader来验证。以下是我在多个项目中沉淀下来的快速诊断法：

技巧一：NDC坐标可视化热键
在Shader中加入条件编译，按一个键（如F1）切换显示模式：

#ifdef DEBUG_NDC return float4(ndc.x * 0.5 + 0.5, ndc.y * 0.5 + 0.5, ndc.z, 1); #endif

在C#脚本中监听Input.GetKeyDown(KeyCode.F1)，动态修改Shader的_DebugMode属性。这样不用改Shader就能实时看NDC分布，比打开Frame Debugger快十倍。

技巧二：像素坐标网格叠加
在后处理Shader中，用fmod(pixelPos, 10)生成10像素网格：

float2 grid = fmod(pixelPos, 10); float gridLine = step(9.5, grid.x) * step(9.5, grid.y); return lerp(col, float4(1,0,0,1), gridLine);

编译后，屏幕上会出现红色10×10像素网格。如果网格歪斜或错位，说明你的pixelPos计算有误——这是检测UV拉伸、缩放失真的最快方法。

技巧三：深度精度压力测试
创建一个超大场景（如1km×1km平面），相机远裁剪面设为1000，近裁剪面0.1，然后用LinearEyeDepth和Linear01Depth分别输出深度：

float depth01 = i.screenPos.z / i.screenPos.w; // NDC z float depthLinear = LinearEyeDepth(depth01); // 世界空间米 float depthLog = log2(depthLinear + 1) / log2(1000 + 1); // 对数压缩 return float4(depth01, depthLinear * 0.001, depthLog, 1);

观察绿色通道（线性深度）：如果远处出现明显色带（banding），说明深度精度不足，需要启用Reverse Z或调整裁剪面。这是优化开放世界渲染的必做测试。

4. 常见问题与排查技巧实录：那些年我们踩过的坐标系深坑

4.1 问题速查表：症状、原因、解决方案

4.2 深度相关经典陷阱：Reverse Z的隐藏代价

Reverse Z（z∈[0,1]）解决了远距离精度问题，但带来了新挑战。最典型的是：SAMPLE_DEPTH_TEXTURE采样返回的值是[0,1]，但Linear01Depth函数期望的输入是[0,1]的NDC z，而SAMPLE_DEPTH_TEXTURE返回的已经是经过UNITY_REVERSED_Z处理的值。如果你直接用：

float depth = SAMPLE_DEPTH_TEXTURE(_CameraDepthTexture, i.uv); float linearDepth = Linear01Depth(depth); // 错！depth已是Reverse Z值

结果会是深度完全颠倒。正确做法是：

float depth = SAMPLE_DEPTH_TEXTURE(_CameraDepthTexture, i.uv); #if defined(UNITY_REVERSED_Z) depth = 1.0 - depth; // 恢复为标准NDC z #endif float linearDepth = Linear01Depth(depth);

这个#if判断是必须的，因为Unity在不同平台自动定义UNITY_REVERSED_Z。我在某AR项目中就因此导致虚拟物体穿模：深度比较永远失败，物体总在背景后面。排查时用Frame Debugger抓取深度纹理，发现值全是0.999，才意识到是Reverse Z未处理。

4.3 多平台适配雷区：DirectX与OpenGL的y轴战争

Unity在DirectX下会自动翻转NDC y轴（_ProjectionParams.x = -1），而在OpenGL下不翻转（_ProjectionParams.x = 1）。ComputeScreenPos内部用这个参数做适配，但如果你手动计算，就会出问题。例如，一个自定义的屏幕空间运动模糊Shader：

// 错误写法：假设y轴方向固定 float2 motion = (i.prevScreenPos - i.currScreenPos) * 0.5; // 在DirectX下，prevScreenPos.y和currScreenPos.y符号相反，motion.y会双倍放大

正确做法是：

float2 motion = i.prevScreenPos - i.currScreenPos; motion.y *= _ProjectionParams.x; // 统一到OpenGL方向

这个_ProjectionParams.x就是Unity为你准备的“y轴开关”，忽略它等于放弃跨平台。我曾为一个客户做的VR应用，在Oculus Quest（OpenGL）上完美，在Windows MR（DirectX）上运动模糊方向完全反向，就是因为没加这一行。

4.4 SRP（可编程渲染管线）下的坐标系变异

在URP/HDRP中，坐标系统有重大变化。URP默认禁用_ScreenParams，改用_ScreenSize（xy为分辨率，zw为倒数），且ComputeScreenPos行为不同。最致命的是：URP的_CameraDepthTexture采样返回的是线性深度（米），而非NDC z。这意味着：

// URP中，以下代码是错的 float depth = SAMPLE_DEPTH_TEXTURE(_CameraDepthTexture, i.uv); float linearDepth = Linear01Depth(depth); // depth已是线性深度，再转换就错了

正确做法是直接使用：

float linearDepth = SAMPLE_DEPTH_TEXTURE(_CameraDepthTexture, i.uv);

或者用URP提供的LinearEyeDepth宏（它内部会判断是否为URP）。我在迁移一个HDRP项目到URP时，花了两天时间才定位到这个问题：所有基于深度的效果（SSAO、景深）全部失效，因为深度值被错误地二次转换。建议：在SRP项目中，永远优先查阅官方Shader Library（如URP的Packages/com.unity.render-pipelines.universal/ShaderLibrary/），而不是沿用Built-in管线的经验。

5. 工具链与自动化验证：让坐标范围检查成为日常开发习惯

5.1 自研Shader调试面板：一键显示所有坐标系数值

与其每次写Shader都手动输出调试色，不如做一个通用调试工具。我用C#写了一个Editor Window，它可以：

• 实时显示当前选中Material的_ScreenParams、_ProjectionParams、_WorldSpaceCameraPos等所有内置参数
• 点击“Capture Frame”按钮，自动截取当前帧的_CameraDepthTexture和_CameraOpaqueTexture，并用Compute Shader计算指定像素的NDC坐标
• 输入屏幕坐标（如100,200），自动反算出该像素对应的world position和view space position

核心代码片段（Compute Shader）：

// CS_CoordinateDebugger.compute #pragma kernel CSMain RWTexture2D<float4> result; Texture2D<float> depthTex; float4 _ScreenParams; float4 _ProjectionParams; [numthreads(1,1,1)] void CSMain(uint3 id : SV_DispatchThreadID) { uint2 pixel = uint2(id.x, id.y); float2 uv = float2(pixel) / _ScreenParams.xy; float depth = depthTex.SampleLevel(sampler_depthTex, uv, 0); // 反算NDC z（Reverse Z） float ndcZ = 1.0 - depth; // 反算world position（简化版，实际需用逆矩阵） float4 ndcPos = float4(uv * 2 - 1, ndcZ, 1); float4 clipPos = float4(ndcPos.x, ndcPos.y, ndcPos.z * 2 - 1, 1); // ... 后续矩阵运算 result[id.xy] = float4(ndcPos.xy, ndcPos.z, 1); }

这个工具让我在30秒内就能确认任意像素的NDC值，比手动改Shader快一个数量级。它已集成到我们团队的CI流程中：每次提交Shader代码，自动运行坐标范围测试用例，确保ComputeScreenPos输出始终在合理范围内。

5.2 单元测试驱动的Shader开发：用HLSL编写可验证的断言

受游戏行业TDD实践启发，我为关键坐标转换函数编写了HLSL单元测试。例如，测试ComputeScreenPos在屏幕中心的输出：

// Test_ComputeScreenPos.hlsl #include "UnityCG.cginc" float4 test_center() { float4 pos = float4(0,0,0,1); // 世界原点 float4 clipPos = UnityObjectToClipPos(pos); float4 screenPos = ComputeScreenPos(clipPos); // 断言：screenPos.w应接近1（正交）或略小于1（透视） float wCheck = abs(screenPos.w - 1) < 0.01 ? 1 : 0; // 断言：screenPos.xy / screenPos.w 应接近(0,0) float2 ndc = screenPos.xy / screenPos.w; float ndcCheck = (abs(ndc.x) < 0.001 && abs(ndc.y) < 0.001) ? 1 : 0; return float4(wCheck, ndcCheck, 0, 1); }

在C#中调用：

var testMat = new Material(Shader.Find("Test/ComputeScreenPos")); RenderTexture rt = RenderTexture.GetTemporary(1,1); Graphics.Blit(Texture2D.whiteTexture, rt, testMat); // 读取rt像素，验证r==1 && g==1

这种测试方式让我们在升级Unity版本时，第一时间发现坐标系统变更。去年Unity 2021.3升级后，ComputeScreenPos在某些正交相机下w值突变为2，就是靠这个测试用例在CI中捕获的。

5.3 性能与精度平衡：何时该用float，何时必须用half

在移动平台，half精度足够且性能更好，但坐标转换是少数必须用float的场景。实测数据：在Adreno 640 GPU上，float2 ndc = i.screenPos.xy / i.screenPos.w用half会导致NDC x值在屏幕右侧出现0.002误差，表现为1像素抖动；而用float则完全稳定。我的经验法则：

• 所有涉及除法、深度计算、反投影的变量，一律用float
• UV采样、颜色计算、简单加减，可用half
• 在Shader Model 4.0+（Unity 2019.4+）中，float和half性能差异已微乎其微，优先保证精度

在某款AR眼镜项目中，我们曾为省几个ALU指令把ndc改为half，结果导致虚拟箭头在视野边缘跳动，返工三天才修复。教训是：在图形领域，精度永远优先于微小的性能提升。

6. 项目收尾与个人体会：坐标范围不是知识点，而是调试肌肉记忆

写完这篇长文，我重新打开了那个困扰我两周的屏幕空间反射Bug。这次，我没有急着改代码，而是打开Frame Debugger，抓取_CameraDepthTexture，用上面提到的调试面板输入屏幕中心坐标，看到NDC z值是0.9998——这说明近裁剪面没问题。接着，我检查_ProjectionParams，发现y值是100（远裁剪面100），x是-1（DirectX），一切正常。最后，我注意到反射向量计算中用了normalize(i.worldPos - _WorldSpaceCameraPos)，但i.worldPos是从UnityObjectToWorld转换来的，而反射面是动态生成的Mesh，其world position计算有误差。我把i.worldPos换成mul(unity_ObjectToWorld, v.vertex).xyz，Bug瞬间消失。你看，问题根本不在坐标范围，而在于我对“world position”的信任过度了——坐标范围知识给我的不是答案，而是排除错误的清单。

这就是我坚持认为“取值范围”是肌肉记忆的原因。它不是让你背诵[-1,1]，而是当你看到一个异常的UV采样结果时，大脑自动启动检查流：screenPos.w是否合理？_ScreenParams是否匹配目标纹理？_ProjectionParams.x是否处理了y轴？这个检查流越快越准，你的调试效率就越高。在最近一个开放世界项目中，我们团队把这套检查流程固化为Code Review Checklist，要求所有Shader PR必须包含坐标系验证截图。结果，坐标相关Bug的平均修复时间从4.2小时降到0.7小时，上线后零坐标类崩溃。

最后分享一个小技巧：在Shader开头加一行注释，声明你假设的坐标范围。例如：

// ASSUME: i.screenPos is homogeneous, i.screenPos.xy/i.screenPos.w ∈ [-1,1], z ∈ [0,1] // ASSUME: _ScreenParams.xy = target render resolution in pixels

这不仅是给自己看，更是给后来者一个明确的契约。当有人修改了ComputeScreenPos的调用方式，这个注释就会变成刺眼的红灯——提醒他：这里有个隐含假设被打破了。

坐标系统没有银弹，只有日复一日的验证、怀疑和修正。当你能在不看文档的情况下，凭直觉说出某个像素的NDC z值，你就真正掌握了它。