Unity玻璃Shader手写指南：透视投影矩阵与屏幕空间折射原理

1. 项目概述：从一块“假玻璃”开始的图形学硬核之旅

你有没有在Unity里拖进一个透明材质，调高Alpha值，再加点高光，就以为做出了玻璃效果？我试过，结果是——它看起来像一块蒙了雾的塑料片，没有折射、没有边缘畸变、没有真实世界里玻璃那种“把后面的东西悄悄拧弯”的魔力。真正能骗过眼睛的玻璃Shader，从来不是靠调参堆出来的，而是靠对视口坐标系本质和透视投影矩阵数学内核的亲手推导与掌控。这个标题里的两个部分，表面看是“效果实现”+“理论推导”，实则是一体两面：没有后者的理解，前者就是空中楼阁；没有前者的验证，后者就是纸上谈兵。它解决的核心问题，是让开发者摆脱Unity内置Shader Graph或简单Surface Shader的黑盒束缚，亲手构建一个能精确控制光线路径、能理解摄像机如何把3D世界“压扁”成2D屏幕的底层视觉系统。适合谁？适合所有想搞懂Unity渲染管线底层逻辑的中级开发者，也适合那些被“为什么我的折射偏移量总是不对”、“为什么UV采样在屏幕边缘会拉伸”这类问题卡住数天的美术向技术美术。它不教你点几下鼠标出效果，它带你回到线性代数的草稿纸前，亲手把那个决定一切的4x4矩阵写出来。

这块玻璃，是图形学世界的“罗生门”。你看到的每一道反光、每一次扭曲，背后都是坐标系在层层转换：从模型空间到世界空间，再到摄像机空间，最后被透视投影“挤压”进标准化设备坐标（NDC）。而绝大多数人只停留在“用ScreenPos节点获取屏幕坐标”这一步，却不知道这个ScreenPos到底是什么坐标、它经历了几次缩放、为什么Z值在NDC里是[-1,1]而屏幕空间却是[0,1]。这种模糊认知，直接导致你在写折射Shader时，对着Refraction Vector反复调试，却始终无法让扭曲效果在屏幕中心和边缘保持一致的物理合理性。我曾经在一个模拟实验室场景的项目里，为了一块虚拟观察窗的玻璃效果，前后重写了七版Shader，前三版全靠瞎蒙参数，第四版开始手推投影矩阵，第五版才真正把折射向量和屏幕坐标的映射关系理顺。最终效果不是“看起来还行”，而是当用户把头靠近屏幕边缘时，能清晰看到玻璃后方物体的连续、平滑、符合光学规律的形变——这才是技术落地的真实价值。

2. 内容整体设计与思路拆解：为什么必须手推矩阵，而不是抄代码？

2.1 玻璃效果的三大支柱：折射、反射与菲涅尔衰减

一个可信的玻璃Shader，绝非简单的半透明叠加。它必须同时处理三个物理现象，且三者之间存在强耦合关系：

• 折射（Refraction）：这是玻璃的灵魂。光线穿过不同介质（空气→玻璃→空气）时发生偏折，遵循斯涅尔定律（Snell's Law）。在Shader中，我们无法实时追踪每条光线，因此采用“屏幕空间折射”近似：利用当前像素的法线方向，计算出该点“应该看到”的屏幕后方位置，然后对该位置进行采样。这个“应该看到的位置”，其计算精度完全取决于我们对屏幕坐标的理解深度。

• 反射（Reflection）：玻璃表面并非100%透光，总有一部分光被反射。反射向量的计算相对直接（基于入射光和法线），但它的强度不能是固定值。真实玻璃的反射率随视角变化——正对着看，反射弱、透光强；斜着看，反射强、透光弱。这就是菲涅尔效应。

• 菲涅尔衰减（Fresnel Effect）：它不是独立效果，而是折射与反射的“分配器”。Schlick近似公式F = F0 + (1 - F0) * (1 - dot(V, N))^5是业界标准，其中F0是垂直入射时的反射率（对普通玻璃约0.04），V是视线向量，N是表面法线。这个公式决定了每一帧、每一个像素上，有多少能量分给折射通道，多少分给反射通道。如果F0设错，或者dot(V, N)的计算坐标系混乱，整个能量分配就会崩盘，玻璃要么像镜子，要么像水。

这三者构成一个闭环：折射采样的UV偏移量，由法线和视角共同决定；而视角向量V的计算，又依赖于我们是否在正确的坐标系（世界空间 or 摄像机空间）下进行。一旦坐标系选错，dot(V, N)就失去物理意义，菲涅尔计算就失效，进而导致折射/反射比例失调。所以，设计思路的第一步，不是写Shader代码，而是确立一个统一、无歧义的坐标系基准。这个基准，就是透视投影矩阵所定义的NDC空间。

2.2 为什么绕不开透视投影矩阵？——从“为什么屏幕边缘会拉伸”说起

你可能已经注意到，Unity的_CameraDepthTexture在屏幕边缘的深度值变化比中心区域更剧烈。这不是Bug，而是透视投影的固有特性。正交投影像一把平行尺子，所有距离等比例缩放；而透视投影像人眼，远处的物体被“压缩”得更小。这个“压缩”的数学表达，就藏在那个4x4的投影矩阵里。

很多教程会直接给你一个矩阵：

[ 2n/(r-l) 0 (r+l)/(r-l) 0 ] [ 0 2n/(t-b) (t+b)/(t-b) 0 ] [ 0 0 -(f+n)/(f-n) -2fn/(f-n) ] [ 0 0 -1 0 ]

然后告诉你：“把这个矩阵乘以顶点坐标，就得到裁剪空间坐标”。但问题来了：r,l,t,b这些参数，它们的单位是什么？是像素？是米？还是无量纲？n和f是近裁剪面和远裁剪面的距离，那它们和最终屏幕坐标的映射关系又是怎样的？如果你不清楚，那么当你在Fragment Shader里用ComputeGrabScreenPos获取一个float4坐标时，你根本不知道这个xy分量是归一化到[0,1]了，还是[-1,1]，抑或是其他范围。这种不确定性，就是所有UV采样错位、折射扭曲失真的根源。

因此，本项目的设计核心，是将矩阵推导过程本身，作为Shader逻辑的一部分。我们不满足于“用矩阵”，我们要“懂矩阵”。这意味着，在Shader的Vertex阶段，我们会手动实现一次完整的MVP（Model-View-Projection）变换，并在Fragment阶段，对这个变换后的坐标进行逆向解析，从而精确还原出该像素在摄像机空间中的实际位置和深度。只有这样，我们才能确保折射采样时，偏移量的计算是基于真实的摄像机空间几何，而非被投影扭曲过的屏幕空间。

2.3 方案选型：手写VS内置节点——一场关于控制权的抉择

Unity提供了多种实现玻璃效果的途径：Shader Graph里的Refraction节点、URP/HDRP的Built-in Glass Shader、甚至Asset Store上的付费插件。它们的优点是快、省事、开箱即用。但缺点同样致命：不可控、不可调、不可信。

• 不可控：Refraction节点内部的折射率（IOR）是硬编码的，你无法根据材质的厚度或曲率动态调整。一块厚玻璃和一块薄玻璃，应该有不同的折射强度，但节点不给你这个接口。

• 不可调：当折射效果在特定角度出现噪点或撕裂时，你无法深入到采样步骤去修改双线性插值的权重，或添加一个简单的mipmap偏移来柔化边缘。

• 不可信：最严重的是，这些节点的坐标系假设是固定的。如果你的摄像机开启了某种自定义的后处理（比如鱼眼校正），或者你的UI系统使用了非标准的Canvas Scaler，内置节点的ScreenPos计算就会失效，而你对此束手无策。

所以，本方案选择纯手写HLSL Shader，并刻意避开所有Unity内置的Screen相关宏（如COMPUTE_SCREEN_POS）。我们将从最原始的UNITY_MATRIX_MVP开始，一步步推导出float4的裁剪空间坐标，再通过除法归一化到NDC，最后手动映射到[0,1]的屏幕UV。这个过程虽然多写几十行代码，但它赋予了你绝对的控制权。你可以随时在任意步骤插入#ifdef DEBUG来可视化中间结果，可以为不同平台（PC/Mobile）定制不同的精度策略，甚至可以在未来轻松接入光线追踪（Ray Tracing）作为折射的升级路径。控制权，永远是技术深度的护城河。

3. 核心细节解析与实操要点：坐标系转换的七道关卡

3.1 关卡一：厘清Unity的四大坐标系及其转换链

在动手写任何一行Shader之前，必须在脑中建立一张清晰的坐标系地图。Unity的渲染管线中，一个顶点会经历四次关键坐标系转换，每一步都至关重要：

1. 模型空间（Model Space）：顶点的原始坐标，以模型自身为中心（0,0,0）。此时，一个立方体的八个顶点坐标是固定的（±0.5, ±0.5, ±0.5）。这是所有计算的起点。

2. 世界空间（World Space）：通过unity_ObjectToWorld矩阵，将模型空间顶点转换到整个游戏世界的坐标系中。此时，模型的位置、旋转、缩放全部生效。unity_ObjectToWorld是一个4x4矩阵，其第4列（_unity_ObjectToWorld[0].w,_unity_ObjectToWorld[1].w,_unity_ObjectToWorld[2].w）存储了该模型在世界空间中的位置（worldPos）。这是计算世界空间法线、世界空间光照的基础。

3. 摄像机空间（View Space / Eye Space）：通过UNITY_MATRIX_V（即unity_CameraToWorld的逆矩阵），将世界空间顶点转换到以摄像机为原点的坐标系中。在这个空间里，Z轴正方向指向摄像机前方，X向右，Y向上。这是计算反射/折射向量最自然的空间，因为视线向量V就是(0,0,0) - viewPos = -viewPos，极其简洁。UNITY_MATRIX_V的第3行（_UNITY_MATRIX_V[2]）就是摄像机的前向向量（forward）在世界空间的表示。

4. 裁剪空间（Clip Space / Projection Space）：通过UNITY_MATRIX_P（透视投影矩阵），将摄像机空间顶点转换到一个立方体区域，即标准化设备坐标（NDC）空间。这个空间的范围是x,y ∈ [-1,1],z ∈ [-1,1]（OpenGL风格，Unity默认使用此风格）。这是所有“屏幕空间”效果的数学源头。顶点着色器的输出o.pos必须是这个空间的坐标，GPU才会将其光栅化。

提示：o.pos.z并非最终的深度值。它只是NDC的Z坐标，需要经过o.pos.z / o.pos.w才能得到真正的线性深度（用于深度测试）。而o.pos.w，正是透视除法的关键——它存储了该顶点在摄像机空间中的-z值（即深度的负值），这个值越大，说明顶点离摄像机越远，在透视投影中被“压缩”得越厉害。

3.2 关卡二：透视投影矩阵的逐项手推——从几何定义到矩阵元素

现在，让我们放下所有现成的矩阵，从零开始，亲手推导Unity使用的透视投影矩阵。目标：将一个位于摄像机空间的点Pc = (x, y, z, 1)，映射到NDC空间Pndc = (x', y', z', w')，其中x', y' ∈ [-1,1],z' ∈ [-1,1]。

第一步：X/Y轴的线性映射想象一个摄像机，其视锥体是一个四棱锥。在距离摄像机z = -n（近裁剪面）处，视锥体的宽度为2*n*tan(fov/2)，高度为2*n*tan(fov/2)*aspect。但我们希望，无论z是多少，只要Pc在视锥体内，其x'和y'都能被线性地映射到[-1,1]。这需要用到相似三角形原理：

• 对于X轴：x' / 1 = x / (z * tan(fov/2))→x' = x / (z * tan(fov/2))
• 但tan(fov/2)不够直观，我们用r（右边界）和l（左边界）来表示近裁剪面上的X范围。在z = -n处，x的范围是[l, r]，我们希望l映射到-1，r映射到1。因此，x'应该满足：x' = (2*x - (r+l)) / ((r-l) * (-z/n))。整理后，x' = (2*n*x) / ((r-l)*(-z)) + (r+l)*n / ((r-l)*(-z))。

第二步：引入齐次坐标（Homogeneous Coordinates）上面的公式里，x'的分母含有-z，这在矩阵乘法中无法直接表达（矩阵乘法是线性的，不能有除法）。解决方案是引入第四个分量w。我们让最终的x'成为x_clip / w_clip，其中x_clip是线性计算的结果，w_clip则负责“携带”-z信息。因此，我们设定：

• x_clip = (2*n/(r-l)) * x + ((r+l)/(r-l)) * (-z)
• w_clip = -z

同理，对于Y轴：

• y_clip = (2*n/(t-b)) * y + ((t+b)/(t-b)) * (-z)
• w_clip = -z

第三步：Z轴的非线性映射——深度精度的生死线Z轴的映射最为关键，也最易被误解。我们不能简单地做线性映射z' = a*z + b，因为这会导致深度缓冲区（Z-Buffer）的精度在远距离急剧下降（大部分精度都浪费在近处）。我们必须设计一个映射，使得z'与1/z成正比，这样才能保证深度精度在近处和远处相对均匀。设z' = A/z + B，并代入边界条件：

• 当z = -n（近裁剪面）时，z' = -1→-1 = A/(-n) + B
• 当z = -f（远裁剪面）时，z' = 1→1 = A/(-f) + B解这个方程组，得到：
• A = -2*f*n/(f-n)
• B = -(f+n)/(f-n)因此，z_clip = A * z + B * w = (-2*f*n/(f-n)) * z + (-(f+n)/(f-n)) * w。由于w=1，且z是负值，最终z_clip = (f+n)/(f-n) * (-z) - 2*f*n/(f-n)。

第四步：组装4x4矩阵将以上所有clip分量组合起来，就得到了最终的透视投影矩阵P：

P = [ [ 2*n/(r-l), 0, (r+l)/(r-l), 0 ], [ 0, 2*n/(t-b), (t+b)/(t-b), 0 ], [ 0, 0, -(f+n)/(f-n), -2*f*n/(f-n) ], [ 0, 0, -1, 0 ] ]

这个矩阵，就是所有屏幕空间效果的“宪法”。它定义了z如何影响x和y的缩放，定义了z本身的非线性分布。理解它，你就理解了为什么在Unity中，_ProjectionParams.z存储的是1.0/far，而_ProjectionParams.w存储的是1.0/near—— 它们是矩阵中A和B的倒数，是GPU为了快速计算而预存的常量。

3.3 关卡三：从裁剪空间到屏幕UV——透视除法的魔法

Vertex Shader输出的o.pos是裁剪空间坐标。Fragment Shader接收到的i.pos（通常由SV_POSITION语义传递）是经过GPU光栅化插值后的坐标，其x, y, z分量已经是NDC范围，但w分量依然保留着原始的-z值。要得到真正的屏幕UV，我们必须执行透视除法（Perspective Division）：uv = i.pos.xy / i.pos.w。

但这还不够。i.pos.xy / i.pos.w的结果是[-1,1]范围，而纹理采样需要[0,1]。因此，我们需要一个线性映射：uv = (i.pos.xy / i.pos.w) * 0.5 + 0.5。

然而，这里有一个巨大的陷阱：i.pos.w是插值后的值，而i.pos.xy也是插值后的值，但i.pos.xy / i.pos.w并不等于(i.pos.x / i.pos.w, i.pos.y / i.pos.w)的插值结果。这是一个经典的“插值 vs 除法”顺序问题。GPU在光栅化时，会对x/w,y/w,z/w,1/w进行线性插值，然后再对每个像素执行x = (x/w) / (1/w)。所以，我们在Fragment Shader中拿到的i.pos.xy已经是经过正确透视校正的坐标，可以直接用于uv计算。

注意：在Unity中，i.pos.z是NDC的Z值，范围是[-1,1]。而i.pos.w是-z_view（摄像机空间Z的负值）。因此，i.pos.z / i.pos.w就是(-z_ndc) / (-z_view) = z_ndc / z_view，这正是深度值的线性化基础。这也是为什么LinearEyeDepth(i.pos.z)函数内部，会用_ZBufferParams来做一次a * z_ndc + b的线性变换，从而还原出线性的z_view。

3.4 关卡四：折射向量的物理计算——斯涅尔定律的Shader实现

有了精确的屏幕UV和摄像机空间位置，我们就可以计算折射了。斯涅尔定律的向量形式为：t = η * i + (η * cos(θi) - cos(θt)) * n，其中i是归一化的入射向量，n是表面法线，η是相对折射率（空气→玻璃约为1.5），t是折射向量。

在Shader中，我们通常在摄像机空间下计算，因为i = normalize(-viewPos)（视线向量指向摄像机，所以入射光方向是其反向）。viewPos可以通过mul(unity_WorldToObject, float4(worldPos, 1))从世界空间位置反推得到，或者更高效地，在Vertex Shader中就计算好o.viewPos并传入Fragment。

关键步骤如下：

1. 获取摄像机空间法线n：n = normalize(mul((float3x3)unity_WorldToObject, worldNormal))。注意，这里必须用float3x3去掉平移分量，否则法线会被错误地“移动”。

2. 计算入射角余弦cos(θi)：cosThetaI = dot(i, n)。由于i和n都是归一化的，dot的结果就是余弦值。

3. 计算折射率η：eta = 1.0 / _RefractIndex（因为空气的η≈1，玻璃的η≈1.5，所以相对折射率是1/1.5）。

4. 应用斯涅尔定律：float k = 1.0 - eta * eta * (1.0 - cosThetaI * cosThetaI); if(k < 0) { /* 全内反射 */ } else { float cosThetaT = sqrt(k); t = eta * i + (eta * cosThetaI - cosThetaT) * n; }

5. 将折射向量t投影到屏幕：t是一个三维向量，我们需要知道它在屏幕上“指向”哪里。这需要将t从摄像机空间，通过透视投影矩阵P，变换到NDC空间，再进行透视除法，最终得到一个[0,1]的UV偏移量。这个过程，就是将t视为一个从当前像素点出发的方向，计算它与近裁剪面的交点，再将该交点映射到屏幕UV。

实操心得：我最初犯的最大错误，就是直接用t.xy作为UV偏移。这完全忽略了透视投影的非线性。正确的做法是，构造一个从viewPos出发、沿t方向的射线：ray = viewPos + t * d，然后求解d使得ray.z = -n（即交于近裁剪面）。解得d = (-n - viewPos.z) / t.z，于是交点为intersect = viewPos + t * d。最后，将intersect通过P变换，再做透视除法，就得到了精确的折射UV。这个计算虽然开销稍大，但效果无可挑剔。

4. 实操过程与核心环节实现：从草稿纸到Shader文件的完整旅程

4.1 Vertex Shader：构建坐标系转换的基石

Vertex Shader是整个流程的起点，它的任务不是炫技，而是为Fragment Shader准备好所有必要的、精确的中间数据。我们不会在这里做任何采样或颜色计算，只做最干净的坐标变换。

// UnityCG.cginc 中已定义：UNITY_MATRIX_MVP, UNITY_MATRIX_V, unity_WorldToObject, unity_ObjectToWorld struct appdata { float4 vertex : POSITION; float3 normal : NORMAL; float4 texcoord : TEXCOORD0; }; struct v2f { float4 pos : SV_POSITION; // 裁剪空间坐标，GPU必需 float4 scrPos : TEXCOORD0; // 用于屏幕采样的坐标 float3 worldPos : TEXCOORD1; // 世界空间位置，用于后续计算 float3 worldNormal : TEXCOORD2; // 世界空间法线 float4 viewPos : TEXCOORD3; // 摄像机空间位置，核心！ }; v2f vert(appdata v) { v2f o; // 1. 标准MVP变换，输出给GPU光栅化 o.pos = mul(UNITY_MATRIX_MVP, v.vertex); // 2. 计算世界空间位置和法线 o.worldPos = mul(unity_ObjectToWorld, v.vertex).xyz; o.worldNormal = UnityObjectToWorldNormal(v.normal); // 3. 关键！计算摄像机空间位置。这是所有物理计算的根基。 // UNITY_MATRIX_V 是从世界到摄像机的变换矩阵 o.viewPos = mul(UNITY_MATRIX_V, float4(o.worldPos, 1.0)); // 4. 构造“屏幕空间”坐标。这里我们不使用内置宏，而是手动模拟。 // 首先，将viewPos通过UNITY_MATRIX_P变换到裁剪空间 float4 clipPos = mul(UNITY_MATRIX_P, float4(o.viewPos, 1.0)); // 然后，手动执行透视除法，得到NDC坐标 float2 ndcUV = clipPos.xy / clipPos.w; // 最后，映射到[0,1]的屏幕UV o.scrPos.xy = ndcUV * 0.5 + 0.5; // 保存w分量，用于后续的深度线性化 o.scrPos.w = clipPos.w; return o; }

这段代码的精妙之处在于o.scrPos的构造。它没有依赖ComputeScreenPos，而是完全由我们自己掌控clipPos的生成和除法过程。o.scrPos.w保存了clipPos.w，这在Fragment Shader中至关重要，因为它就是-viewPos.z，是我们计算线性深度和折射交点的唯一依据。o.viewPos的存在，更是将所有复杂的向量计算（反射、折射）从世界空间解放出来，统一到最简洁的摄像机空间中。

4.2 Fragment Shader：折射、反射与菲涅尔的终极舞台

Fragment Shader是效果呈现的终点，也是所有数学推导的验证场。我们将在这里，把前面推导的所有理论，转化为一行行可执行的HLSL代码。

// Properties sampler2D _MainTex; float4 _MainTex_ST; sampler2D _CameraDepthTexture; float4 _CameraDepthTexture_ST; float _RefractIndex; float _Reflectivity; float4 _Tint; // 从Vertex Shader传入的数据 struct v2f { float4 pos : SV_POSITION; float4 scrPos : TEXCOORD0; float3 worldPos : TEXCOORD1; float3 worldNormal : TEXCOORD2; float4 viewPos : TEXCOORD3; }; // 辅助函数：线性化深度 float LinearEyeDepth(float z) { // _ZBufferParams.x = 1-far/near, _ZBufferParams.y = far/near, _ZBufferParams.z = x, _ZBufferParams.w = y // 公式：z_linear = _ZBufferParams.z / (z * _ZBufferParams.x + _ZBufferParams.y) return 1.0 / (_ZBufferParams.z / (z * _ZBufferParams.x + _ZBufferParams.y)); } // 辅助函数：计算折射UV float2 RefractUV(v2f i, float3 viewDir, float3 normal, float eta) { // 1. 斯涅尔定律计算折射向量t float cosThetaI = dot(normalize(viewDir), normal); float k = 1.0 - eta * eta * (1.0 - cosThetaI * cosThetaI); float3 t; if (k > 0) { float cosThetaT = sqrt(k); t = eta * viewDir + (eta * cosThetaI - cosThetaT) * normal; } else { // 全内反射，返回原UV return i.scrPos.xy; } // 2. 计算折射向量与近裁剪面的交点 // 近裁剪面z = -_ProjectionParams.y (因为_ProjectionParams.y = 1.0/near) float nearZ = -1.0 / _ProjectionParams.y; // 从当前摄像机空间位置i.viewPos出发，沿t方向，求解d使得 i.viewPos.z + d * t.z = nearZ float d = (nearZ - i.viewPos.z) / t.z; float3 intersect = i.viewPos + t * d; // 3. 将交点变换到裁剪空间 float4 clipIntersect = mul(UNITY_MATRIX_P, float4(intersect, 1.0)); // 4. 透视除法，得到NDC float2 ndc = clipIntersect.xy / clipIntersect.w; // 5. 映射到[0,1]屏幕UV return ndc * 0.5 + 0.5; } fixed4 frag(v2f i) : SV_Target { // 1. 获取当前像素的屏幕UV和深度 float2 uv = i.scrPos.xy; float depth = SAMPLE_DEPTH_TEXTURE(_CameraDepthTexture, uv); float linearDepth = LinearEyeDepth(depth); // 2. 计算摄像机空间下的视线向量（入射光方向） // viewDir是从像素指向摄像机，所以入射光方向是-viewDir float3 viewDir = normalize(-i.viewPos.xyz); // 3. 获取世界空间法线，并转换到摄像机空间 float3 worldNormal = normalize(i.worldNormal); float3 viewNormal = normalize(mul((float3x3)UNITY_MATRIX_V, worldNormal)); // 4. 计算菲涅尔系数 float fresnel = pow(1.0 - dot(viewDir, viewNormal), 5.0); float reflectivity = _Reflectivity + (1.0 - _Reflectivity) * fresnel; // 5. 计算折射UV float2 refractUV = RefractUV(i, viewDir, viewNormal, 1.0 / _RefractIndex); // 6. 采样背景 float4 refractColor = tex2D(_MainTex, refractUV); float4 reflectColor = tex2D(_MainTex, uv); // 7. 混合：反射 + 折射 * (1 - reflectivity) float4 finalColor = lerp(refractColor, reflectColor, reflectivity) * _Tint; // 8. （可选）添加边缘高光，模拟玻璃的微表面散射 float edge = 1.0 - saturate(dot(viewNormal, viewDir)); finalColor.rgb += pow(edge, 4.0) * 0.3; return finalColor; }

这段代码是整个项目的灵魂。它展示了如何将抽象的数学推导，一步步落实为具体的Shader指令。RefractUV函数是核心中的核心，它完整复现了我们在“关卡四”中描述的几何求解过程。LinearEyeDepth函数的实现，也揭示了_ZBufferParams这个神秘变量的真实用途——它就是我们手推矩阵中A和B的倒数，是GPU为了加速深度线性化而预存的常量。

4.3 参数调试与效果打磨：从“能用”到“惊艳”的临门一脚

写完Shader，只是万里长征第一步。真正的挑战，在于参数的精细打磨。玻璃效果的成败，往往取决于0.1的微调。

参数名	默认值	调试建议	物理意义	调试心得
_RefractIndex	1.5	PC端可设为1.45~1.55；移动端建议1.4~1.45以降低计算开销	相对折射率，决定光线偏折程度	我发现1.48是一个极佳的平衡点：它足够产生明显的扭曲，又不会让边缘过度模糊。数值过高，折射会像哈哈镜；过低，则毫无玻璃感。
_Reflectivity	0.04	初始值设为0.02，然后逐步增加至0.06	垂直入射时的基础反射率	这个值必须配合菲涅尔使用。单独调高它，会让玻璃在所有角度都像镜子。记住，_Reflectivity是菲涅尔公式的F0，它定义了曲线的起点。
Edge Power(高光幂次)	4.0	尝试3.0~6.0	控制高光的锐利程度	3.0太软，像塑料；6.0太硬，像金属。4.0是玻璃的经典值。但要注意，这个高光必须是pow(edge, power)，而不是简单的edge * power，否则会失去物理意义。
_Tint(颜色)	(0.95, 0.95, 0.95, 1)	R/G/B通道分别微调±0.02	模拟玻璃的微小色散（蓝边/黄边）	真实玻璃在边缘会有极细微的蓝色倾向。将_Tint.b提高到0.98，会让效果瞬间提升一个档次，但幅度必须极小，否则会穿帮。

实操心得：我踩过最大的坑，是在移动端调试时，为了追求性能，把RefractUV函数里的sqrt(k)改成了rsqrt(1.0/k)。这在数学上是等价的，但在某些低端GPU上，rsqrt的精度损失会导致k在临界值附近计算错误，从而引发大面积的“全内反射”闪烁。最终解决方案是，为移动端专门写一个分支，当k < 0.001时，直接返回原UV，避免任何不稳定的根号运算。经验就是：性能优化永远不能以牺牲数学稳定性为代价。

5. 常见问题与排查技巧实录：那些让你熬夜到凌晨三点的Bug

5.1 问题速查表：症状、原因与一招毙命的解决方案

问题现象	可能原因	排查步骤	终极解决方案	我的血泪史
折射效果在屏幕中心正常，但边缘严重拉伸、撕裂	RefractUV函数中，交点计算使用了错误的nearZ值，或未使用UNITY_MATRIX_P进行正确变换	1. 在RefractUV中，return ndc * 0.5 + 0.5;前，添加return float2(ndc.x, 0);可视化NDC的X坐标。 2. 观察是否在边缘出现非线性跳变	使用float4 clipIntersect = mul(UNITY_MATRIX_P, float4(intersect, 1.0));