1. 从模型顶点到屏幕像素矩阵变换到底在做什么很多人第一次接触Unity渲染管线里的矩阵变换脑子里冒出来的是一堆线性代数公式什么平移矩阵、旋转矩阵、缩放矩阵背得滚瓜烂熟但一到实际项目里就懵了——为什么我的模型明明放在场景里摄像机一拉远就跑到屏幕外面去了为什么UI元素跟着摄像机旋转会飘为什么法线方向在非均匀缩放下会出错这些问题的根源都在于没有把矩阵变换当成一条完整的“流水线”来理解而是把它拆成了孤立的数学知识点。我刚开始做渲染相关的工作时也是这样直到有一次做一个模型描边效果发现描边宽度在模型缩放后完全失控才逼着自己把整条变换链路从头到尾捋了一遍。这篇文章就是那次梳理的完整产物。我会从模型空间的顶点坐标出发一路讲到它最终变成屏幕上的像素中间经过的每一个矩阵、每一次坐标空间切换都会拆开揉碎讲清楚。同时我会重点讲那些文档里不会写的坑——比如法线变换为什么要用逆转置矩阵、深度缓冲的非线性到底怎么影响你的效果、不同渲染路径下矩阵的差异等等。不管你是刚接触Shader的新手还是已经能写简单顶点片元着色器但总觉得矩阵这块不够通透的开发者这篇内容都能帮你把这条链路彻底打通。我还会给出可以直接复制到项目里验证的代码片段让你能亲眼看到每个矩阵对最终结果的影响。2. 模型空间到世界空间物体变换矩阵的完整拆解2.1 物体变换矩阵到底包含了什么在Unity里每个GameObject的Transform组件上都有Position、Rotation、Scale三个属性。这三个属性组合起来就构成了这个物体的模型矩阵Model Matrix也叫物体变换矩阵Object-to-World Matrix。它的作用是把顶点从模型空间Model Space变换到世界空间World Space。模型空间是啥你可以把它理解成“模型自己的坐标系”。比如你从建模软件里导出一个角色模型它的原点可能在脚底也可能在腰部这个原点位置就是模型空间的原点。模型空间里的坐标是固定的不会因为你把物体拖到场景哪个位置而改变。世界空间则是整个场景的统一坐标系。当你把模型拖到场景里设置它的Position为(3, 0, 5)实际上就是在说把这个模型的模型空间原点放到世界空间的(3, 0, 5)位置。模型矩阵的构建顺序是先缩放再旋转最后平移。这个顺序不能乱因为矩阵乘法不满足交换律。你可以这样理解缩放和旋转都是相对于物体自身原点进行的而平移是把整个已经缩放旋转好的物体搬到目标位置。如果先平移再旋转物体会绕着世界原点转而不是绕自己的原点转结果就完全不对了。在Shader里Unity已经帮你算好了这个矩阵直接通过unity_ObjectToWorld就能拿到。如果你想知道它的具体数值可以在Shader里输出这个矩阵的某一行来看看。2.2 手动构建模型矩阵为什么顺序如此重要假设一个物体在模型空间里有一个顶点P它的世界坐标P_world可以表示为P_world T * R * S * P_local其中T是平移矩阵R是旋转矩阵S是缩放矩阵。注意这里的乘法顺序是从右往左应用的先对P_local应用S再应用R最后应用T。我用一个具体的例子来说明为什么顺序不能反。假设有一个单位立方体一个顶点在(1, 1, 1)。现在我要把它缩放2倍然后绕Y轴旋转90度最后平移到(5, 0, 0)。如果按正确顺序先缩放再旋转最后平移缩放后(2, 2, 2)旋转90度后绕Y轴(2, 2, -2)假设旋转方向使得x变成-z平移后(7, 2, -2)如果顺序反了先平移再旋转最后缩放平移后(6, 1, 1)旋转90度后(1, 1, -6)缩放后(2, 2, -12)结果完全不同。所以在手动构建矩阵时一定要记住这个顺序。Unity的Transform组件内部也是按这个顺序来构建矩阵的。在C#里你可以用Matrix4x4.TRS(position, rotation, scale)来一次性构建这个矩阵它内部就是按TRS的顺序组合的。如果你需要自己写矩阵乘法一定要注意列主序和行主序的区别——Unity的Matrix4x4是列主序的也就是说矩阵的每一列对应一个基向量。2.3 模型空间的法线为什么要用逆转置矩阵变换这是一个非常经典的坑。顶点的变换直接用模型矩阵就行但法线的变换不能用同一个矩阵尤其是当模型存在非均匀缩放的时候。原因在于法线是垂直于表面的方向向量它描述的是“朝向”而不是“位置”。当你对一个物体进行非均匀缩放时表面的倾斜角度会发生变化法线也必须相应地调整。如果直接用模型矩阵变换法线得到的方向可能不再垂直于变换后的表面。数学上的推导是这样的假设切线向量为T法线向量为N它们满足T·N 0。经过模型矩阵M变换后新的切线为MT新的法线为MN。要保证(MT)·(MN) 0法线实际上应该用M的逆转置矩阵(M^-1)^T来变换。在Unity的Shader里Unity提供了一个现成的矩阵unity_WorldToObject它是unity_ObjectToWorld的逆矩阵。所以变换法线的正确做法是float3 normalWorld normalize(mul(float4(normalObject, 0.0), unity_WorldToObject).xyz);注意这里用的是unity_WorldToObject而不是它的转置因为Unity在Shader里对矩阵乘法的顺序做了处理实际上等价于用逆转置矩阵变换。如果你自己手动构建矩阵一定要记得先求逆再转置。提示如果模型只有均匀缩放三个轴的缩放系数相同那么法线直接用模型矩阵变换也不会出错因为均匀缩放下逆转置矩阵和原矩阵只差一个缩放因子归一化后就抵消了。但一旦有非均匀缩放就必须用逆转置。3. 世界空间到观察空间摄像机矩阵的隐藏细节3.1 观察矩阵的构建逻辑从世界空间到观察空间也叫摄像机空间、视图空间靠的是观察矩阵View Matrix。这个矩阵的作用是把世界坐标系下的点转换到以摄像机为原点的坐标系下。观察矩阵的构建思路是先平移再旋转。具体来说就是把世界原点平移到摄像机位置的反方向然后旋转使得摄像机的朝向对齐到-Z轴方向。在Unity里摄像机的观察矩阵可以通过Camera.worldToCameraMatrix获取。如果你在Shader里写渲染Unity会自动把相关的矩阵传进来比如UNITY_MATRIX_V就是观察矩阵。观察矩阵有一个很重要的特性它把摄像机放在原点摄像机看向-Z方向在Unity的左手坐标系下。这意味着在观察空间里所有可见物体的z坐标都是负的因为它们在摄像机前方。这个特性在写深度相关效果时非常关键。3.2 摄像机矩阵在Shader中的获取方式与差异在不同的渲染路径下获取摄像机矩阵的方式略有不同。如果你写的是内置渲染管线的Shader可以直接用UNITY_MATRIX_V。如果是最新的URP或HDRP矩阵的获取方式会有变化比如URP里需要用GetWorldToViewMatrix()或者直接从CBuffer里读。这里有一个很容易踩的坑在顶点着色器里和片元着色器里某些矩阵的值可能不一样。比如在片元着色器里UNITY_MATRIX_V可能已经被优化掉了或者在某些平台上精度不同。如果你需要在片元着色器里做世界空间的计算最好在顶点着色器里把世界坐标算好然后插值传到片元着色器。另一个坑是摄像机的正交投影和透视投影对观察矩阵没有影响。观察矩阵只负责把世界空间转到摄像机空间投影矩阵才负责把摄像机空间转到裁剪空间。所以不管你是正交相机还是透视相机观察矩阵的构建方式是一样的。3.3 观察空间里的深度值为什么是非线性的这是一个让很多人困惑的问题为什么在观察空间里z值看起来是线性的但到了裁剪空间和屏幕空间深度就变成非线性的了原因在于透视投影矩阵。透视投影矩阵会把观察空间的z值映射到裁剪空间的z值这个映射不是线性的。具体来说透视投影矩阵的第三行和第四行会导致w分量等于-z观察空间的z然后裁剪空间的z除以w之后就变成了一个非线性的深度值。这个非线性带来的实际影响是靠近摄像机的深度精度高远离摄像机的深度精度低。这就是为什么在做深度相关的效果比如软粒子、深度雾、SSAO时远处的物体容易出现深度冲突Z-Fighting。如果你需要在Shader里把深度值转回线性的观察空间深度Unity提供了一个辅助函数LinearEyeDepth它可以把屏幕空间的深度值转成观察空间的线性深度。反过来Linear01Depth可以转成0到1之间的线性深度。注意LinearEyeDepth返回的是观察空间下的深度单位是世界单位。Linear01Depth返回的是归一化后的深度适合用来做渐变效果。4. 观察空间到裁剪空间投影矩阵与齐次裁剪4.1 透视投影矩阵的参数计算过程透视投影矩阵是整条链路里最复杂的一个矩阵。它的作用是把观察空间下的视锥体一个截锥体映射到一个标准的立方体裁剪空间这个立方体的x、y、z范围都是[-w, w]其中w是齐次坐标的第四个分量。透视投影矩阵的关键参数有四个FOV视场角、Aspect宽高比、Near近裁剪面、Far远裁剪面。这四个参数决定了投影矩阵的具体数值。FOV决定了视锥体在垂直方向上的开口角度。Aspect决定了水平方向和垂直方向的比例关系。Near和Far决定了视锥体在深度方向上的范围。投影矩阵的构建公式大致是这样的以Unity的透视投影为例f 1 / tan(FOV/2) m00 f / Aspect m11 f m22 (Far Near) / (Near - Far) m23 (2 * Far * Near) / (Near - Far) m32 -1其他元素为0。注意m32 -1这一项它就是把观察空间的z值取反后赋给w分量从而实现透视除法。这个矩阵的推导过程涉及相似三角形和齐次坐标的变换这里不展开讲但你需要知道的是FOV越大视野越广但物体看起来越小Near和Far的比值越大深度精度越差。4.2 正交投影矩阵与透视投影的本质区别正交投影矩阵和透视投影矩阵最大的区别在于正交投影没有透视除法。也就是说正交投影矩阵的w分量始终是1不会因为距离远近而改变。正交投影矩阵的参数是Size垂直方向的大小、Aspect、Near、Far。它的构建公式比透视投影简单得多m00 1 / (Size * Aspect) m11 1 / Size m22 2 / (Near - Far) m23 (Far Near) / (Near - Far) m33 1正交投影下物体的大小不会因为距离而改变所以常用于2D游戏、UI渲染、以及一些需要精确尺寸控制的场景。在实际项目中选择哪种投影方式取决于你的需求。如果你做的是3D游戏通常用透视投影如果你做的是2D游戏或者需要等距视角的效果正交投影更合适。4.3 裁剪空间的齐次坐标与透视除法裁剪空间是一个四维的齐次坐标空间。一个顶点在裁剪空间下的坐标是(x, y, z, w)。只有当x、y、z都在[-w, w]范围内时这个顶点才会被保留否则就会被裁剪掉。透视除法就是把裁剪空间的坐标除以w分量得到归一化设备坐标NDC。NDC的x、y、z范围都是[-1, 1]在Unity里z的范围是[0, 1]或者[-1, 1]取决于平台但Unity会统一处理。透视除法的意义在于它把远处的物体“压小”近处的物体“放大”从而实现近大远小的透视效果。这也是为什么透视投影矩阵的m32 -1——它把观察空间的z值取反后作为w这样除以w之后z值越负越远坐标就越小。在Shader里你通常不需要手动做透视除法因为GPU会在光栅化阶段自动完成。但如果你在做一些屏幕空间的计算比如把世界坐标投影到屏幕上就需要自己处理这一步。5. 裁剪空间到屏幕空间视口变换与像素映射5.1 视口变换矩阵的构建与作用从裁剪空间经过透视除法后的NDC到屏幕空间需要经过视口变换。视口变换的作用是把NDC坐标映射到屏幕的像素坐标。视口变换的公式是screenX (ndcX * 0.5 0.5) * screenWidth viewportX screenY (ndcY * 0.5 0.5) * screenHeight viewportY其中screenWidth和screenHeight是屏幕的像素尺寸viewportX和viewportY是视口在屏幕上的偏移。在Unity里这个变换通常由GPU自动完成你不需要手动计算。但如果你在做后处理效果需要把屏幕像素坐标转回NDC或者世界坐标就需要用到这个公式的逆运算。5.2 屏幕空间坐标在Shader中的实际应用屏幕空间坐标在Shader里有很多应用场景比如屏幕空间反射SSR需要把世界坐标投影到屏幕空间然后采样屏幕纹理。屏幕空间环境光遮蔽SSAO需要在屏幕空间下计算深度差异。边缘检测需要在屏幕空间下采样相邻像素的颜色。UI渲染UI元素的位置通常直接以屏幕空间坐标给出。在Unity的Shader里你可以通过ComputeScreenPos函数来计算屏幕空间坐标。这个函数返回的是齐次坐标下的屏幕位置需要除以w分量才能得到真正的屏幕坐标。float4 screenPos ComputeScreenPos(UnityObjectToClipPos(v.vertex)); float2 screenUV screenPos.xy / screenPos.w;注意ComputeScreenPos返回的坐标范围是[0, 1]在除以w之后而不是像素坐标。如果你需要像素坐标还需要乘以屏幕尺寸。5.3 深度缓冲的精度问题与解决方案深度缓冲是屏幕空间下存储每个像素深度值的缓冲区。它的精度直接影响到深度测试的准确性。深度缓冲的精度问题主要来自两个方面一是深度值的非线性分布二是深度缓冲的位深。前面说过透视投影下深度值是非线性的靠近摄像机的精度高远离摄像机的精度低。如果Near和Far的比值太大比如Near0.01Far1000远处的深度精度会非常差导致Z-Fighting。解决方案有几种增大Near值把Near从0.01改成0.1深度精度会提升很多。这是最简单有效的方法。减小Far值如果场景不需要看到很远的地方把Far调小也能提升精度。使用反向深度缓冲把深度值反转让近处的精度低、远处的精度高。这在一些引擎里是默认开启的。使用对数深度缓冲在Shader里手动计算对数深度可以大幅提升远处精度但需要修改Shader。提示在Unity里你可以通过Camera.main.depthTextureMode来开启深度纹理的生成。如果你需要读取深度缓冲记得在Shader里声明_CameraDepthTexture。6. 法线变换与切线空间容易被忽略的矩阵细节6.1 法线变换为什么不能用模型矩阵前面已经提到过法线变换需要用模型矩阵的逆转置矩阵。这里再深入讲一下为什么。法线的本质是描述表面的朝向它是一个垂直于表面的向量。当你对物体进行非均匀缩放时表面的倾斜角度会改变法线也必须相应地改变。如果直接用模型矩阵变换法线得到的方向可能不再垂直于变换后的表面。举个例子假设有一个表面法线朝上(0, 1, 0)切线朝右(1, 0, 0)。现在把物体在x方向上缩放2倍在y方向上缩放1倍。变换后的切线变成(2, 0, 0)但法线如果直接用模型矩阵变换还是(0, 1, 0)。这两个向量不再垂直了因为(2, 0, 0)·(0, 1, 0) 0看起来还是垂直的等等这个例子不对因为法线在y方向没有缩放所以还是垂直的。换一个例子法线朝右上(1, 1, 0)归一化后是(0.707, 0.707, 0)切线朝左上(-1, 1, 0)归一化后是(-0.707, 0.707, 0)。现在在x方向缩放2倍y方向缩放1倍。变换后的切线是(-1.414, 0.707, 0)法线如果用模型矩阵变换是(1.414, 0.707, 0)。这两个向量的点积是(-1.4141.414 0.7070.707) (-2 0.5) -1.5不等于0说明它们不再垂直。而如果用逆转置矩阵变换法线模型矩阵M的逆是x方向缩放0.5y方向缩放1转置后还是x方向缩放0.5y方向缩放1。法线(1, 1, 0)变换后是(0.5, 1, 0)归一化后是(0.447, 0.894, 0)。切线和这个法线的点积是(-1.4140.447 0.7070.894) (-0.632 0.632) 0垂直了。所以逆转置矩阵是正确的。6.2 切线空间的构建与TBN矩阵切线空间是法线贴图使用的坐标系。在切线空间里法线贴图的RGB值对应法线的xyz方向。要把切线空间的法线转到世界空间需要用到TBN矩阵。TBN矩阵由三个基向量组成切线Tangent、副切线Bitangent、法线Normal。这三个向量构成了一个正交基把切线空间的向量转到世界空间。在Unity里你可以通过UnityObjectToWorldNormal来变换法线通过UnityObjectToWorldDir来变换切线。副切线可以通过法线和切线的叉积得到但要注意叉积的顺序和切线的w分量w分量表示副切线的方向通常是-1或1。float3 normalWorld UnityObjectToWorldNormal(v.normal); float3 tangentWorld UnityObjectToWorldDir(v.tangent.xyz); float3 bitangentWorld cross(normalWorld, tangentWorld) * v.tangent.w; float3x3 TBN float3x3(tangentWorld, bitangentWorld, normalWorld); float3 normalTangent UnpackNormal(tex2D(_NormalMap, uv)); float3 normalWorldFinal normalize(mul(normalTangent, TBN));注意TBN矩阵的构建顺序切线、副切线、法线分别对应矩阵的三列。在乘法时切线空间的向量左乘TBN矩阵得到世界空间的向量。6.3 非均匀缩放下切线空间的修正当模型存在非均匀缩放时切线空间的基向量也需要修正。切线和法线一样不能直接用模型矩阵变换而是需要用模型矩阵变换后再做正交化处理。具体做法是先用模型矩阵变换切线然后用变换后的法线对切线做正交化减去切线在法线方向上的投影最后归一化。副切线则通过法线和切线的叉积重新计算。float3 normalWorld UnityObjectToWorldNormal(v.normal); float3 tangentWorld mul((float3x3)unity_ObjectToWorld, v.tangent.xyz); tangentWorld normalize(tangentWorld - normalWorld * dot(tangentWorld, normalWorld)); float3 bitangentWorld cross(normalWorld, tangentWorld) * v.tangent.w;这样做可以保证在非均匀缩放下切线空间仍然是正交的法线贴图的效果不会出错。7. 不同渲染路径下的矩阵差异与实战验证7.1 内置管线与URP/HDRP的矩阵获取差异Unity的内置渲染管线和URP/HDRP在矩阵的获取方式上有一些差异这些差异如果不注意很容易导致Shader在不同管线下表现不一致。在内置管线里常用的矩阵有UNITY_MATRIX_M模型矩阵UNITY_MATRIX_V观察矩阵UNITY_MATRIX_P投影矩阵UNITY_MATRIX_MVP模型-观察-投影矩阵UNITY_MATRIX_MV模型-观察矩阵UNITY_MATRIX_VP观察-投影矩阵在URP里这些矩阵大部分仍然可用但有些被替换成了新的API。比如URP推荐使用TransformObjectToWorld、TransformWorldToView等函数来替代直接使用矩阵。HDRP的差异更大很多矩阵需要通过CBuffer来获取。如果你写的Shader需要跨管线使用最好用Unity提供的宏和函数而不是直接引用矩阵。比如用UnityObjectToClipPos来替代mul(UNITY_MATRIX_MVP, v.vertex)。7.2 用可视化方式验证矩阵变换的每一步光看公式容易晕最好的学习方式是把每一步变换的结果可视化出来。我常用的做法是写一个简单的Shader把不同空间的坐标映射到颜色上然后观察模型在不同变换下的颜色变化。比如把模型空间的坐标映射到RGBfloat3 modelColor v.vertex.xyz * 0.5 0.5; return float4(modelColor, 1.0);把世界空间的坐标映射到RGBfloat3 worldPos mul(unity_ObjectToWorld, v.vertex).xyz; float3 worldColor worldPos * 0.1; return float4(worldColor, 1.0);把观察空间的坐标映射到RGBfloat3 viewPos mul(UNITY_MATRIX_V, mul(unity_ObjectToWorld, v.vertex)).xyz; float3 viewColor viewPos * 0.1; return float4(viewColor, 1.0);通过对比这些颜色你可以直观地看到每个矩阵对顶点位置的影响。比如观察空间的z值是负的所以蓝色通道会偏暗世界空间的坐标范围更大所以颜色变化更剧烈。7.3 常见矩阵变换错误的排查清单在实际项目中矩阵变换相关的错误往往表现为模型位置不对、法线方向错误、深度测试异常、屏幕空间效果偏移等。下面是我总结的一份排查清单遇到问题时可以逐项检查问题现象可能原因排查方法模型位置偏移模型矩阵构建顺序错误检查TRS顺序确认是先缩放再旋转再平移法线方向错误未使用逆转置矩阵检查法线变换是否用了unity_WorldToObject深度冲突Near/Far比值过大增大Near或减小Far检查深度缓冲精度屏幕空间效果偏移未除以w分量检查ComputeScreenPos后是否除了w切线空间法线错误TBN矩阵构建顺序错误检查切线、副切线、法线的排列顺序跨管线表现不一致直接引用了管线特定的矩阵改用Unity提供的通用函数和宏这份清单是我在实际项目中踩坑后总结的基本上覆盖了90%以上的矩阵变换问题。遇到问题时先对照这张表排查往往能快速定位原因。8. 个人实操心得与几个容易翻车的细节8.1 矩阵乘法顺序的记忆技巧矩阵乘法的顺序是很多人容易搞混的地方。我的记忆方法是从右往左读先应用的写在右边。比如MVP * vertex读作“先应用M再应用V再应用P”。因为矩阵乘法是从右往左结合的所以最右边的矩阵最先作用于顶点。在Unity的Shader里mul(M, v)表示用矩阵M变换向量v。如果是多个矩阵相乘比如mul(P, mul(V, mul(M, v)))等价于mul(P * V * M, v)。但要注意Unity的矩阵是列主序的所以P * V * M的顺序和数学上的写法可能相反。实际写代码时直接用UnityObjectToClipPos最省事不用纠结顺序。8.2 精度问题在移动端的特殊表现移动端GPU对浮点数的精度支持通常比桌面端低尤其是half精度16位浮点。在矩阵变换中如果用了half精度来计算世界坐标或观察坐标可能会出现明显的精度问题比如模型抖动、深度冲突加剧、法线贴图出现块状伪影。我的建议是在顶点着色器里世界坐标和观察坐标的计算尽量用float精度。虽然half精度更快但精度损失在移动端会被放大。如果性能允许关键矩阵运算都用float。如果必须用half至少保证在计算深度和法线时用float。8.3 一个容易被忽略的细节摄像机的投影矩阵翻转在某些平台上比如某些图形API摄像机的投影矩阵可能需要翻转Y轴。Unity会自动处理这个差异但如果你在Shader里手动构建投影矩阵就需要注意这个平台差异。具体来说OpenGL和DirectX的NDC空间在Y轴方向上是相反的。Unity在内部会做转换但如果你直接读取UNITY_MATRIX_P并手动做投影可能会发现渲染结果上下颠倒。解决方法是检查UNITY_UV_STARTS_AT_TOP宏根据平台决定是否翻转Y。这个坑我在做后处理效果时踩过当时画面上下颠倒排查了很久才发现是投影矩阵的平台差异。后来养成了习惯凡是涉及手动投影的代码都先检查这个宏。8.4 矩阵变换在Shader调试中的实用技巧调试矩阵变换问题时最有效的方法是把中间结果可视化出来。除了前面说的用颜色映射坐标还可以用以下技巧用Gizmos画线在C#里用Gizmos.DrawLine画出变换后的坐标轴直观看到矩阵的效果。用Debug.Log输出矩阵在C#里把Matrix4x4的数值打印出来和预期值对比。用RenderDoc抓帧如果条件允许用RenderDoc抓一帧查看每个DrawCall的矩阵数值和顶点数据这是最准确的调试方式。写一个简单的测试Shader把顶点直接输出到裁剪空间的不同位置观察屏幕上的变化。这些技巧我在实际项目中都用过尤其是RenderDoc几乎是排查渲染问题的必备工具。虽然学习曲线有点陡但一旦上手效率提升非常明显。矩阵变换这条链路从模型空间到屏幕空间中间经过的每一步都有它的道理和坑。把这条链路彻底搞明白不仅能让你的Shader写得更稳还能在遇到渲染问题时快速定位原因。希望这篇内容能帮你少走一些弯路。
