Unity Shader从材质到渲染管线：顶点/片元着色器与URP选型

从材质的那个小球说起：Shader在Unity里到底占什么位置

你把Unity装好，新建一个场景，Hierarchy里躺着Directional Light和Main Camera，Project面板右键建一个Material，拖到球体上，球体就亮了。这一步太顺了，顺到很多人做了半年项目都没打开过材质属性里那个Shader下拉框。但真正决定那个球长什么样的，不是模型，也不是那个白球贴图，而是挂在材质上的一份Shader。

Unity Shader这件事，说难不难，但它卡人的地方很特别——你可能写过几十个C#脚本，能熟练拖拽Transform、处理碰撞、做摄像机跟随，逻辑写得清清楚楚，可一旦要写Shader，突然发现所有东西都变成了矩阵、语义、通道和一堆看不懂的宏。这不是你笨，是因为Shader运行的地方在GPU上，它的思考方式和CPU完全不同：CPU是按你的代码一行一行顺序执行，GPU是几万个线程同时干同一件事，谁先谁后你管不着。

这篇内容我想把Unity Shader这件事从头捋一遍，重点不是给你一个漂亮的公式，而是让你明白它为什么长成现在这个样子。看完之后，你应该能做到这几件事：知道顶点着色器和片元着色器各自负责什么阶段；知道Unity里那么多Shader写法该挑哪种；能自己写出第一个能跑、能改、能调试的Shader；碰到阴影不对、透明穿帮、移动端掉帧的时候，知道往哪个方向查。适合刚学Unity、对渲染层完全没概念的人，也适合那些已经会用Shader Graph连线、但说不清背后在干什么的人。

1. Shader到底是什么：把渲染管线拆开看

1.1 显卡里那条流水线在干的活

先把"渲染"两个字翻译成人话：把一堆三维数据，压成屏幕上的一张二维图像。这个过程由GPU接管，走的是一条固定流程，行业里叫渲染管线。它的顺序大致是：CPU先把模型顶点、索引、贴图、各种变换矩阵打包好，通过Draw Call提交给GPU；GPU拿到这批数据后，先做顶点变换，把每个顶点从模型空间挪到裁剪空间；接着把点连成三角形，做图元装配；然后光栅化，把三角形拆成一堆小小的片元，你可以粗略理解为"候选像素"；最后每个片元算颜色，通过深度和混合测试，写进帧缓冲。

这套流程里，绝大部分环节是硬件写死的，你改不了：光栅化怎么拆三角形是固定的，深度测试的规则也是固定的。但有几个环节是开放的，硬件允许你塞一段程序进去，替它决定"顶点该挪到哪"和"这个片元该是什么颜色"。你塞进去的这段程序，就是Shader。

所以在Unity里，一份Shader往往包含两个核心部分：一个顶点函数，负责算坐标和传递数据；一个片元函数，负责算最终颜色。中间那些插值、光栅化、测试，硬件帮你做了，你控制不了也不需要控制。理解这个分工，是后面一切的前提。

1.2 顶点着色器：管位置和传参

顶点着色器是逐顶点运行的。你有一个一万人顶点的模型，它就跑一万次，而且这"一万次"是并行跑的，互相之间不知道对方在干什么。这一点特别关键，因为很多人写Shader时会本能地想"我遍历一下所有顶点找最高的那个"，这在顶点着色器里根本做不到——你只能看到当前这一个顶点。

它主要干两件事。第一件是把顶点坐标做变换，通常是从模型空间乘上模型矩阵到世界空间，再乘视图矩阵到观察空间，最后乘投影矩阵到裁剪空间，输出一个裁剪空间坐标给硬件。手写的时候你会看到类似mul(UNITY_MATRIX_MVP, v.vertex)这样的写法，本质就是这三个矩阵合并后的结果。在内置管线里这个宏可以用，但在URP或HDRP里它已经被替换掉了，得换成TransformObjectToHClip这类函数，这个坑后面会细说。

第二件事是把顶点上的数据往下传，比如法线、切线、UV、顶点色。你在顶点函数里算好，用带TEXCOORDn语义的变量输出，硬件会在三角形内部按重心坐标做插值，到片元阶段时每个像素拿到的就是一个平滑过渡的值。UV能正确贴图、法线能平滑过渡，靠的就是这个插值机制。

1.3 片元着色器：一个像素一个像素地算颜色

片元着色器是逐片元运行的，这个数量级比顶点大得多。一个1080P全屏的模型，片元可能上百万，所以片元着色器里的每一行代码都会被放大几百万倍，性能敏感度极高。

它拿到的是插值后的数据：插值后的UV、插值后的法线、插值后的世界坐标。然后你要根据这些数据算出这个片元该显示什么颜色，返回一个RGBA值。光照、纹理采样、菲涅尔边缘光、溶解、噪声扰动，全都在这里做。

有一个概念要澄清：片元不等于像素。光栅化生成的一些片元可能还没进帧缓冲就被深度测试裁掉了，所以片元数一般大于等于最终写入屏幕的像素数。这也解释了为什么有些场景看着不复杂但显卡很吃力——被裁掉的片元照样跑完了整个片元着色器，只是最后没写进屏幕而已。

提示：顶点着色器里不要做逐顶点的光照计算指望它好看。老式的顶点光照在低模上会出现明显的块状高光，现在基本都是逐像素光照，或者干脆预计算好光照贴图。

1.4 为什么Unity要自己造一套Shader语言

如果你去看原生的图形API，写一个着色器要处理大量平台差异：不同图形接口的着色器语法、坐标系差异、矩阵约定都不一样。Unity做了一件很讨巧的事，它发明了ShaderLab——一层包裹语言，用来描述"我有哪些属性、我有几个Pass、渲染状态怎么设、走哪个LOD、回退到哪个Shader"，而具体的着色计算可以写在里面的代码块里。

这么做的好处是同一份Shader能编译到好几个目标平台。坏处是初学者容易分不清哪些是ShaderLab语法、哪些是真正的着色语言语法。一个典型的错觉是把Tags、Cull、ZWrite当成着色语言的一部分，其实它们是ShaderLab的渲染状态指令，压根不参与GPU那边的计算，它们编译后变成的是GPU的状态设置。

还有一层：Unity很多年前用的是Cg语言，后来逐步转成HLSL。现在你在网上搜到老教程，看到CGPROGRAM和ENDCG，那是老写法；新的应该用HLSLPROGRAM和ENDHLSL。两者大量语法互通，但在SRP（可编程渲染管线）下CG那套基本不维护了。

1.5 除了顶点和片元，还有别的着色器吗

有，而且值得知道它们的存在。几何着色器可以在图元级别增删顶点，比如把三角形变成三个新三角形做毛发；曲面细分着色器可以把低模细分出更多顶点，做地形或者动态细分；计算着色器最特殊，它不参与渲染管线，是拿GPU当并行计算器用，适合粒子物理、后处理卷积、图像模糊这类吞吐密集的活。

不过在Unity的实际项目里，新手九成九的时间都花在顶点片元着色器上。计算着色器在移动端支持度参差不齐，微信小游戏这类WebGL环境对它的支持非常有限，如果你打算往小游戏方向走，前期别把重心放这儿。

2. Unity里那么多Shader写法，到底该挑哪个

2.1 内置管线：顶点片元着色器和表面着色器

如果你用的是内置渲染管线，会碰到两种主要写法。第一种是顶点片元着色器，你自己写vert和frag函数，光照、阴影、雾效全都得自己处理。好处是完全可控，坏处是要自己处理一堆光照循环、阴影采样、光照探针，代码量不低。

第二种是表面着色器，写一个surf函数，用SurfaceOutputStandard之类的结构描述表面属性（反照率、金属度、光滑度、法线），Unity在编译期帮你把这些展开成一整套顶点片元代码，顺便处理光照和阴影。它写起来非常快，几十行就能做出接受光照的材质。

表面着色器的代价是编译慢、变体多、不透明。它生成出来的代码你看得见但改不动，一旦要做出格的效果就束手束脚。而且它是内置管线专属，URP和HDRP里根本不支持。现在新项目基本都往SRP走，所以我个人建议：表面着色器了解即可，重点学顶点片元。

2.2 URP和HDRP：Shader Graph与手写HLSL

URP和HDRP属于可编程渲染管线。这套体系下Unity推出了Shader Graph，节点连线式编辑，所见即所得，URP下开箱即用。对美术、TA或者只想快速做效果的开发者来说，Shader Graph的效率确实高，改一个参数立刻能看到结果，不用编译等半天。

但Shader Graph不是万能的。它生成的代码你不好插手，某些需要精细控制指令、想做极致移动端优化的场景，手写HLSL更合适。还有一个现实问题：Shader Graph生成的Shader变体数量容易失控，如果不加控制，一堆材质会让打包体积和编译时间都很难看。

我自己的做法是混合使用：常规的、需要频繁调参的效果用Shader Graph，追求性能或者需要特殊平台适配的用HLSL手写。这两种不冲突，同一个项目里可以并存。

2.3 一张表说清选型逻辑

注意：选型之前先确认项目用的是哪条管线。在内置管线里写HLSLPROGRAM然后发现TransformObjectToHClip找不到，或者在URP里用UNITY_MATRIX_MVP编译报错，都是选型没对齐导致的，这类错误占了新手报错的很大一部分。

2.4 为什么我劝你先手写一遍再上Shader Graph

这有点像学开车先学手动挡。Shader Graph把光照、坐标变换、平台差异都封装成节点了，用起来爽，但一旦效果不对，你连从哪查都不知道。手写过一遍之后，你会知道顶点变换发生了什么，光照方向从哪来，UV的平铺偏移是怎么算的，阴影采样需要哪些宏。再回去用Shader Graph，你就能看懂它背后在干什么，出问题也能定位。

3. 动手写第一个Shader：从骨架到能跑

3.1 文件骨架逐行拆解

先看一份能在内置管线跑起来的最小Shader，我加了注释，每一块都说明白。

Shader "Custom/BasicUnlit" { Properties { _MainTex ("主贴图", 2D) = "white" {} _Color ("叠加颜色", Color) = (1,1,1,1) _Intensity ("亮度", Range(0, 4)) = 1 } SubShader { Tags { "RenderType"="Opaque" "Queue"="Geometry" } LOD 100 Pass { Cull Back ZWrite On ZTest LEqual HLSLPROGRAM #pragma vertex vert #pragma fragment frag #pragma multi_compile_fog #include "UnityCG.cginc" struct appdata { float4 vertex : POSITION; float2 uv : TEXCOORD0; }; struct v2f { float4 pos : SV_POSITION; float2 uv : TEXCOORD0; UNITY_FOG_COORDS(1) }; sampler2D _MainTex; float4 _MainTex_ST; float4 _Color; float _Intensity; v2f vert (appdata v) { v2f o; o.pos = UnityObjectToClipPos(v.vertex); o.uv = TRANSFORM_TEX(v.uv, _MainTex); UNITY_TRANSFER_FOG(o, o.pos); return o; } fixed4 frag (v2f i) : SV_Target { fixed4 col = tex2D(_MainTex, i.uv) * _Color * _Intensity; UNITY_APPLY_FOG(i.fogCoord, col); return col; } ENDHLSL } } FallBack "Diffuse" }

Properties块里声明的是暴露在材质面板上的参数，注意这里只是声明，真正能用的变量必须在下面再声明一次，而且类型要能对上。这个"声明两遍"的设计新手最容易漏，漏了之后材质面板上参数照样能改，但Shader里读到的一直是默认值，表现就是"改了没反应"。

SubShader是一组Pass的集合，Unity会从上往下挑第一个当前硬件能跑的SubShader。Pass里就是一次完整的绘制。LOD用来做质量分级，数字越小越简单。

3.2 顶点函数里到底算了几件事

顶点函数里我做了三件事，逐个说。第一件UnityObjectToClipPos(v.vertex)，把模型空间的顶点坐标一次性转到裁剪空间。这个函数内部帮你乘了模型、视图、投影三个矩阵，内置管线里可以直接用。要注意它的输入是模型空间坐标，如果你手上已经是世界空间坐标了，得换成UnityWorldToClipPos。

第二件TRANSFORM_TEX，处理UV的平铺和偏移。材质面板上每个贴图参数旁边都有Tiling和Offset两个小格子，你在材质上改它们，值其实是通过_MainTex_ST这个自动生成的变量传进来的。TRANSFORM_TEX做的就是uv * _MainTex_ST.xy + _MainTex_ST.zw。手动写一遍你就明白为什么要在材质上改平铺而不是改UV坐标了。

第三件雾效宏。如果你的场景里开了雾，不做这一步物体在后处理阶段会显得和周围不搭，尤其是大场景远处的物体。multi_compile_fog这个编译指令会为不同的雾模式生成变体，代价是变体数增加。

3.3 片元函数与语义的作用

片元函数返回fixed4，后面跟SV_Target语义，意思是"这个值输出到第0号渲染目标"，也就是屏幕。如果你在做多重渲染目标（比如延迟渲染的G-Buffer，或者你自己写后处理同时输出多张图），就会看到SV_Target0、SV_Target1这样的写法。

appdata里的POSITION和TEXCOORD0是输入语义，告诉GPU"这个字段从顶点的哪个通道取数据"。v2f里的SV_POSITION是必须的，硬件靠它决定这个顶点最终落在屏幕的哪个位置。其他字段你随便用TEXCOORD0到TEXCOORD7，它们本质上只是"编号的数据通道"，不一定非得装UV，你完全可以拿TEXCOORD1传世界坐标。

提示：SV_POSITION语义的字段在片元阶段的值不是单纯的插值结果，它是经过透视校正的屏幕空间坐标。想从它反推屏幕UV，得除以屏幕尺寸，或者直接用ComputeScreenPos。

3.4 在URP里怎么改这份代码

URP下直接用上面这份会报错，因为UnityCG.cginc和UnityObjectToClipPos都不在了。要改成引入Core.hlsl，用TransformObjectToHClip，另外Pass里得加Tags { "LightMode"="UniversalForward" }，不然URP不认识这个Pass，物体直接消失，这个现象特别迷惑人——Console不报错，物体就是看不见。

Tags { "LightMode"="UniversalForward" } ... #include "Packages/com.unity.render-pipelines.universal/ShaderLibrary/Core.hlsl" o.pos = TransformObjectToHClip(v.vertex.xyz);

另外URP里fixed类型虽然还能用但不推荐了，统一用half或float。这个改动看起来小，但迁移老项目的时候是高频报错点，值得记一笔。

3.5 从单色到有光照：加一个简单的高光

想让它接受主光方向，可以在片元里自己算一个简单的Lambert加高光：

float3 N = normalize(i.worldNormal); float3 L = normalize(_WorldSpaceLightPos0.xyz); float3 V = normalize(_WorldSpaceCameraPos - i.worldPos); float3 H = normalize(L + V); float ndl = saturate(dot(N, L)); float spec = pow(saturate(dot(N, H)), _Shininess); float3 color = baseColor * ndl + spec * _SpecColor.rgb;

这里_WorldSpaceLightPos0是Unity自动传进来的主光方向，_WorldSpaceCameraPos是相机位置，都是内置变量。但注意，这套写法只处理了主方向光，多盏灯、点光源、聚光灯都不会有反应，真要做好得写完整的ForwardBase和ForwardAdd Pass，或者直接用Shader Graph。这也说明了为什么很多人最终还是回到现成方案——从零造光照的轮子成本很高。

4. 渲染状态和那几个最容易翻车的配置

4.1 Cull、ZWrite、ZTest、Blend怎么配

Cull Back剔除背面，是默认值，也是性能最优的选项。做树叶、布片、旗帜这类单面模型时经常要Cull Off，但要注意关掉之后三角形数量翻倍，移动端要谨慎。另外关掉剔除不会自动修正法线方向，光照会算错，通常要在片元里根据是否正面朝向手动翻转法线：用VFACE语义拿到正面标记，再乘上去。

ZWrite On表示写入深度，不透明物体必须开，否则后面的物体会盖在前面物体上，出现经典的前后穿帮。透明物体一般要关掉深度写入，靠Queue排序来保证渲染顺序，但排序是按物体中心点排的，大物体和互相穿插的透明物体一定会出问题，这是图形学的固有限制，不是Unity的锅。

Blend决定新颜色怎么和帧缓冲里已有颜色混合。常规半透明用Blend SrcAlpha OneMinusSrcAlpha，发光叠加用Blend One One。混合模式写错会导致颜色发白、发灰或者完全看不见，这是排查透明问题时首先要看的。

4.2 阴影不生效？先查这四件事

阴影问题是问得最多的。物体投影不出来，按顺序查：第一，Shader里有没有ShadowCaster这个Pass，没有的话它压根不参与阴影贴图的绘制。用内置管线时只要写了FallBack，Unity会把FallBack里的阴影Pass补上；自己写URP Shader时经常忘了加，结果就是只有别人能投到它身上，它自己投不出去。

第二，Shader的变体有没有被裁掉。打包时如果用了变体裁剪，可能会把需要的变体剔了，表现是编辑器里正常，真机或者打包后没阴影。

第三，阴影距离和级联设置。质量设置里的阴影距离如果比物体距离主相机的距离还小，阴影自然不出现。级联数量调低会让远处阴影精度骤降，看起来像消失。

第四，偏移参数。阴影贴图有分辨率限制，斜面上容易出现条纹状的自我遮挡，行业叫阴影痤疮。调ShadowBias和NormalBias能缓解，但调太大又会导致阴影和物体分离，看起来像漂浮，这叫彼得潘效应。这两个参数本质上是拿精度换瑕疵，没有完美解，只能调到观感能接受。

4.3 顶点动画一定要改包围盒

这是我从项目里踩出来的：只要你在顶点着色器里动了顶点的位置，Unity的视锥剔除就会按原始网格的包围盒来判断。也就是说，顶点被位移到包围盒外面的部分，会在相机还看不到网格本体时被整块剔除，表现为物体在屏幕边缘突然整体消失或者突然弹出。

解决办法是手动扩大Renderer的包围盒，或者直接改材质属性里的_BoundsMin、_BoundsMax，让剔除系统按更大的范围判断。也可以在脚本里定期更新Mesh.bounds。这个问题和Renderer的包围盒机制直接相关，做草叶摆动、旗帜飘动、布料模拟的时候几乎必然遇到。

4.4 移动端和小游戏平台的额外约束

移动端GPU的带宽和精度都紧张。片元着色器里常见的优化手段：把float降成half甚至fixed（内置管线），能省不少寄存器和带宽；避免在片元里写动态分支，GPU对分支的处理方式是两条路都算完再选一条，分支省不了多少反而可能更慢；避免在透明的UI和粒子上做无意义的大面积叠加，过度绘制是移动端掉帧的头号原因，尤其是全屏半透明的特效。

微信小游戏这类WebGL环境还有额外限制：计算着色器支持很有限，一些高精度纹理格式不可用，纹理压缩格式也得按平台挑。这个平台对Shader变体数量尤其敏感，因为变体多了会显著影响下载体积和运行内存。做小游戏项目时，能减少关键字就减少关键字，shader_feature比multi_compile更省，因为前者只会编译实际用到的组合。

还有一个隐蔽的点：限定数据块大小和常量缓冲区的对齐。不同平台对常量缓冲区的对齐要求不一样，一个float3后面跟一个float可能被硬件按float4对齐，导致内存布局和你以为的不一样。跨平台项目里，能合并成float4就合并，别留悬空的小类型。

5. 调试与排查实录：把黑盒打开

5.1 效果不对时的排查顺序

我自己的习惯是从外往内查。第一步先确认Shader有没有编译错误，Console里的红字要一条条看，很多时候报错信息里的行号和实际位置差几行，因为宏展开会打乱行号。第二步用一个最简Shader（纯红输出）替换，看物体是否可见，确认是Shader问题还是模型、材质、剔除的问题。第三步逐步加功能，UV输出、法线输出、光照输出，一步一步缩小范围。

这个方法看着笨，但比对着代码发呆快多了。很多"效果不对"其实不是Shader逻辑错，而是材质上贴图没给、法线反了、模型没UV、渲染队列设置错了。

5.2 常见问题速查表

5.3 我常用的几个调试手段

第一招是假彩色输出。把UV直接当颜色返回float4(uv,0,1)，画面会变成红绿渐变，一眼就能看出UV有没有问题、有没有超出0到1范围。把法线当颜色返回float4(normal*0.5+0.5, 1)，画面会变成彩色球，能立刻看出法线方向对不对。这两招比任何工具都快。

第二招是帧调试器。它能一步步展示每个Draw Call，看到当前用了哪个Shader、哪些渲染状态、渲染目标长什么样。排查"这个物体为什么画成这样"非常有效，尤其是后处理和半透明的叠加问题。

第三招是抓帧工具。遇到严重像素级的问题，抓一帧下来逐个管线阶段看，能精确到哪个Pass的哪个输出出了问题。这类工具上手有门槛，但一旦用熟，排查效率提升非常明显。配套的还有Shader调试变体，可以把中间变量可视化到屏幕上，适合排查数值范围溢出、负值、NaN这类问题。

第四招是Shader的编译错误面板。有些错误不会在Console里完整显示，需要打开Shader文件看顶部的报错提示行。还有一种情况是Shader编译成功但效果异常，那多半是平台差异或者精度问题，这时候在前面加#pragma target 3.0之类的指令往往能让差异暴露出来。

5.4 关于代码和Shader配合的几个实际心得

有个效果我做过很多次：物体逐渐溶解消失。实现方式是在片元里采样一张噪声贴图，用一个_Progress参数去比较，低于阈值的直接裁掉。这个_Progress就是C#脚本每帧传进来的，配合Mathf.PerlinNoise生成的自然噪声，边缘可以做出不规则的感觉，比纯随机数好看很多。这也说明Shader不是孤立存在的，脚本控制参数、Shader负责表现，是常规的组合方式。

还有一点，别在Shader里做本该用代码做的事。比如位置的动画、缩放、旋转，用Transform做比在顶点着色器里算要简单得多，除非你要做顶点级的特殊形变。分清哪些工作属于CPU、哪些属于GPU，是提升效率的关键。

我也想提醒一句，Shader的维度很多：管线（内置还是URP）、平台（PC还是移动还是小游戏）、精度（全精度还是半精度）、变体数量、渲染队列，任何一个维度没对齐，都可能出现"编辑器正常、真机不对"的经典问题。我的习惯是做效果时先在目标平台上跑一遍最小验证，别等做完了整体迁移，那时候排查成本会翻好几倍。

最后分享一个我踩过的坑：有一次写了个溶解效果，编辑器里完美，打包到移动端之后边缘变成硬邦邦的锯齿，怎么调参数都没用。后来发现是片元里用了对屏幕坐标求导的函数，移动端部分GPU对这种跨像素运算的支持行为不一致，值在边缘跳变导致的。改成在顶点阶段把需要的值算好传下来做插值，问题就没了。这类事情看文档看不出来，只能靠真机跑出来，所以任何涉及跨像素运算、导数、屏幕空间采样的效果，都建议在目标设备上单独验证一遍，别只信编辑器。

后面如果还要往下走，可以试着从这三条线扩展：一条是把光照模型往PBR方向做深，理解能量守恒和BRDF为什么长那样；一条是往性能方向钻，研究变体管理、指令优化、移动端带宽；还有一条是往工具链方向走，把Shader和编辑器扩展结合起来，做美术能直接用的参数化效果。这三条路都挺长，但每一条走到一定深度，你对渲染的理解都会和现在完全不一样。