渲染管线：从 CPU 提交到屏幕像素

1.1 一条把 3D 变成 2D 的流水线

渲染管线（Rendering Pipeline）是一条流水线：输入是场景里的三维数据，输出是屏幕上的二维像素。 它由两个完全不同的执行者接力完成 —— 前半段跑在 CPU 上，叫"应用程序阶段"；后半段跑在 GPU 上，叫"渲染管线"。

之所以强调"接力"，是因为这两段的工作性质完全不同：

1.2 一帧画面的完整旅程

把所有环节串起来，一帧的流程大致是这样。这张图从上往下读：左边一列是 CPU 端的四步 （①~④，正好对应第 2 章的四个小节），下面一行是 GPU 端的四段（对应第 4~7 章）， 中间那条箭头就是两者的分界线。

注意 ①~④ 是被"循环"罩住的 —— 每个可见物体都要从头走一遍，所以这几步的开销要乘以物体数量， 这正是 CPU 端优化的重点。另外留意 ④ 的位置：它在 CPU 这一侧，做的是下达命令， Shader 代码真正跑起来是在下面的 GPU 那一段里。

帧缓冲画完之后，通常还要再走一遍后处理（Post Processing）：把整张画面当成一张纹理， 做调色、Bloom、景深、抗锯齿之类的处理，最后才送到显示器。这一篇主要讲主流程，后处理留到后面单独展开。

2.1 剔除：先把看不见的扔掉

一个场景里可能有成千上万个物体，但摄像机一帧里能看到的往往只有几百个。 如果把这些看不见的物体也提交给 GPU，等于白白浪费了整条链路的开销 —— 所以应用程序阶段的第一件事就是剔除（Culling）。

Unity 里常用的剔除手段有这么几类，它们会叠加生效：

• 视锥体剔除（Frustum Culling） —— 用物体的包围盒与相机视锥做相交测试，完全在视锥外的直接排除。这是引擎自动做的，不需要你写代码。
• 层级剔除（Layer Culling Mask） —— 通过 Layer 和相机的 Culling Mask 匹配，手工控制"这个相机不看某类物体"。适合做小地图相机、UI 相机这类特殊视角。
• 遮挡剔除（Occlusion Culling） —— 判断物体是否被前面的墙体完全挡住。需要预先烘焙遮挡数据，对室内场景收益很大，对开阔场景往往没效果。

2.2 排序：决定先画谁后画谁

剔除之后，剩下的物体要排个序。排序规则由两个东西决定：渲染队列（RenderQueue）和与相机的距离。

最关键的是一道分水岭：2500。

2.3 打包数据：把指令准备好

排好序之后，CPU 要为每个物体准备一份"绘制指令包"。这一包里装的东西大致分四类：

这里有个容易被忽略的点：打包数据的成本本身就和物体数量成正比。 哪怕某个物体最终只占屏幕几个像素，这份"包"该准备还是得准备 —— 这就是为什么减少物体数量（而不是减少像素）能直接优化 CPU 端。

2.4 绘制调用：交给 GPU

数据准备好后，CPU 通过图形 API 把指令提交给 GPU。这里有两个经常被混着说的概念：

• SetPass Call —— 切换 Shader / 渲染状态的次数。切换一次，GPU 就要重新配置一遍管线状态，开销较大。
• Draw Call —— 提交一次"画这个网格"的调用。数量直接影响 CPU 的提交开销。

// 一帧的大致结构
Render() {
  // ① 剔除：拿到这一帧真正要画的物体列表
  var visible = Culling(camera);

  // ② 排序：按 RenderQueue 和距离排好序
  Sort(visible);

  // ③ + ④ 逐个物体打包并提交
  foreach (var obj in visible) {
    SetPass(obj.material.shader);   // 状态变了就产生一次 SetPass Call
    SetupUniforms(obj.matrixVP,      // 变换矩阵
                  obj.material,      // 材质参数
                  lights);           // 光源信息
    DrawCall(obj.mesh);              // 提交绘制
  }
}

所以"优化 Draw Call"并不是指某个 API 很慢，而是指上面这个循环每转一圈的固定开销。 合批（Batching）的意义就是让多个物体共用一次提交，把循环圈数降下来。

3.1 GPU 管线的数据流

数据交到 GPU 手上之后，还要再走几道工序。这一段的特点是：顺序由硬件写死， 能写代码的地方只有两处 —— 顶点处理与片元处理，中间夹着一段完全由硬件执行的固定功能。

把两行对着看就清楚了：上面一行是谁在执行，下面一行是数据此刻待在哪个空间。 同一个三角形会在这条链路上被反复改写 —— 从一堆三维坐标，变成裁剪空间里的四个分量， 再变成屏幕上的二维位置，最后变成一片片的像素颜色。

3.2 Shader 代码与管线的对应

上面这张图听起来抽象，但落到代码上其实非常具体：一个最简 Shader 里， 几乎每一行都能在链路上找到一个位置。下面这段只做一件事 —— 把贴图原样贴到模型上， 但它的结构是完整的。

Shader "Rain/StageMap" {
  Properties {
    _MainTex ("Texture", 2D) = "white" {}
  }

  SubShader {
    Tags { "RenderType" = "Opaque" }   // ⑥ CPU 端据此把它排进不透明队列

    Pass {
      CGPROGRAM
      #pragma vertex vert        // ① 指定顶点处理的入口
      #pragma fragment frag      // ② 指定片元处理的入口
      #include "UnityCG.cginc"

      struct appdata {           // ③ 顶点 Shader 的输入：来自顶点缓冲
        float4 vertex : POSITION;
        float2 uv     : TEXCOORD0;
      };

      struct v2f {                // ④ 顶点 Shader 的输出：会被插值后送给片元
        float4 pos : SV_POSITION;
        float2 uv  : TEXCOORD0;
      };

      v2f vert (appdata v) {
        v2f o;
        o.pos = UnityObjectToClipPos(v.vertex);  // ⑤ 模型空间 → 裁剪空间
        o.uv  = v.uv;                                // 自定义数据原样往下传
        return o;
      }

      fixed4 frag (v2f i) : SV_Target {          // ⑦ 逐片元执行
        return tex2D(_MainTex, i.uv);          // ⑧ 纹理采样：UV → 纹素颜色
      }
      ENDCG
    }
  }
}

4.1 三个矩阵与四个空间

顶点 Shader 里最常见的那一行 UnityObjectToClipPos(v.vertex)， 其实是三个矩阵连乘。用照相机打比方最好理解 —— 想拍一张照片，你会做三件事：

1. 把物体摆好（决定它在世界里的位置和朝向）→ 模型矩阵 M（Model）
2. 把相机架好（决定从哪儿、朝哪儿看）→ 视图矩阵 V（View）
3. 按下快门（决定画面范围与透视强弱）→ 投影矩阵 P（Projection）

三件事对应四次空间切换，顶点就是这样一步步被"搬运"到裁剪空间的：

为什么一个 4×4 矩阵就能同时装下旋转和平移？靠的是齐次坐标： 把顶点补一个 w = 1，平移量就能塞进矩阵的最后一行（或最后一列， 看 API 约定），乘法形式因此可以统一。举个最小的例子 —— 把顶点 (0, 2, 3) 平移 (10, 0, −3)：

// 顶点 p = (0, 2, 3)，平移量 t = (10, 0, -3)
[ 1 0 0  10 ]   [ 0 ]   [ 10 ]
[ 0 1 0   0 ] · [ 2 ] = [  2 ]
[ 0 0 1  -3 ]   [ 3 ]   [  0 ]
[ 0 0 0   1 ]   [ 1 ]   [  1 ]

顶点里存的始终是它相对于自身原点的坐标，模型矩阵负责把它换算到场景里； 这一层分离很有用：同一个网格可以被不同物体复用，只是各自带一个不同的模型矩阵而已。

4.2 相机空间是怎么定的

投影矩阵的推导我们先放下，先补上中间那一步：视图矩阵是怎么把整个世界搬到"相机看到的样子"的。 它需要三样输入 —— 相机在哪、看哪里、以及"上"是哪一边：

换句话说是这样：视图矩阵做的事情，等价于先把世界旋转到相机基上，再把相机平移到原点。 旋转部分是把世界坐标投影到 right / up / forward 三个方向上的分量， 所以矩阵的左上 3×3 部分直接由这三根归一化向量拼成；平移部分则是 −EYE 在这个基下的坐标。

5.1 硬件操作阶段：一串固定动作

顶点 Shader 吐出裁剪空间坐标之后，程序控制权就交回给硬件了。接下来这串动作全部由固定电路完成， 顺序也不能改：

5.2 光栅化到底输出了什么

光栅化做的事情可以用一句话概括：拿三角形去覆盖像素网格，逐个判断像素中心有没有落在三角形里面， 落在里面的就算被覆盖，生成一个片元。它输出的不是"像素"，而是"候选像素"的清单。

22 与 23 都不重要，重要的是这个换算关系：片元数量取决于覆盖面积，而不是取决于模型有多少顶点。 所以一个顶点数很少的大平面（比如整屏的地面、天空盒）反而可能成为性能杀手。

片元里带着什么

光栅化在生成片元的同时，会把顶点 Shader 传下来的 v2f 成员按重心坐标插值成属于这个像素的值。 常见的片元属性有：

• 深度值 z —— 必须有。输出合并阶段的深度测试全靠它，缺了它遮挡关系就无从判断
• 位置 —— 屏幕坐标（以及可选的世界坐标），做投影、雾效、折射时要用
• 法线 —— 光照计算的主角，通常还要带切线以便做切线空间法线贴图
• UV —— 采样贴图的地址，多重 UV（UV0 / UV1）常用于光照贴图与细节贴图
• 顶点色 —— 便宜的遮罩与色调信息，常用于风格化渲染
• 你自己加的自定义数据 —— 从顶点 Shader 一路插值下来的任何东西

6.1 纹理技术：从 UV 到纹素

片元 Shader 的主要任务是给这个片元定一个颜色，而颜色通常来自两件事： 从贴图里取样（纹理技术），再按光照模型算一遍（光照计算）。同一个模型， 没贴图看起来是"灰模"，贴上纹理再叠上光照，才有材质感。

先解决取样这件事。顶点里带的 UV 是一对 [0, 1] 范围内的归一化坐标， 而贴图上真正被读写的最小单位是纹素（texel）。把 UV 换算成纹素地址， 需要一步缩放：

换算公式是 纹素地址 = u × 宽度 − 0.5（减 0.5 是因为纹素中心落在 (i + 0.5) / 宽度 上）。上面这张图里，地址算出来是 2.0 —— 一个边界值， 它不该只取某一个纹素，而是要看周围四个纹素中心的脸色。这就是过滤要解决的事。

纹素取样这件事，工程上要回答五个问题：

• 怎么采样 —— UV 与纹素地址之间的换算，以及 UV 超出范围怎么办
• 怎么过滤 —— 地址落在纹素之间时，取最近的那个，还是把周围几个加权平均
• 远距离怎么办 —— Mipmap：贴图变小之后按哪一级采样
• 怎么寻址 —— 平铺、截断、镜像还是填边框色
• 怎么压缩 —— 显存和带宽有限，纹理格式怎么选

过滤：最近邻与双线性

最近邻（Nearest）直接取地址最近的那个纹素，速度最快，边缘会有明显锯齿， 像素风或需要保留硬边时反而是优点。双线性（Bilinear）取周围四个纹素中心， 按距离加权平均，视觉上平滑得多，代价是每个片元要做 4 次取样 + 3 次插值。

双线性只处理"同一级贴图内"的插值。如果把 Mipmap 的层级也一起算进来， 就是三线性过滤（Trilinear）—— 在两级 Mipmap 之间再做一次插值，代价是 8 次取样， 但能让远处的地面在移动时不再"跳变"。

Mipmap：用分辨率换稳定

Mipmap 是一张贴图的"金字塔"：第 0 级是原图，第 1 级是长宽各缩小一半的版本， 依次递减到 1×1。远处的表面投射到屏幕上可能只占几个像素， 此时按原图采样会出现严重的闪烁（摩尔纹）—— 硬件会根据这个像素在 UV 空间的覆盖范围（footprint）自动挑一个合适层级。

寻址模式：UV 跑到 [0, 1] 之外

压缩：省下的是带宽，赔上的是精度

纹理压缩和 PNG / JPG 不是一回事：图片格式要在运行时解压成完整的 RGBA， 而 GPU 纹理格式是硬件直接随机读取的块压缩，块与块之间互不依赖。 所以它是"显存 + 带宽"的优化，而不是"文件体积"的优化。以一张 88 × 88 的贴图为例：

放到整张图上看更直观：一张未压缩的贴图可能占 17 MB，转成 ETC 之后约 3 MB， 换成更大压缩块的 ASTC 6×6 只有约 2.5 MB。反过来，格式选得太保守 （比如为了保精度全部不压缩），带宽压力会直接体现在帧率上。

6.2 光照：直接光与间接光

颜色有了纹理做底，接下来要靠光照把它"点亮"。这里先建立一个最重要的二分法： 光到表面的路径只有两种 —— 直接来的，和反弹来的。

差别在于成本：直接光可以实时算，间接光基本都要预计算或近似。 完整解一遍"无数条光线在场景里来回弹"就是全局光照（GI）， 实时渲染做不到，于是有了后面 6.4 节那套"拆开近似"的框架。

6.3 Phong 模型与它的三项分解

有了光的方向，接下来要决定"表面被照亮之后是什么颜色"。最经典的模型是 Phong， 它把颜色拆成三项相加，其中两项只跟光与表面的几何关系有关：

float3 N = normalize(i.normal);
float3 L = normalize(_LightPos.xyz - i.worldPos);  // 表面 → 光源
float3 V = normalize(_WorldSpaceCameraPos - i.worldPos);  // 表面 → 相机
float3 R = reflect(-L, N);                      // L 的镜面反射方向

float ndl  = saturate(dot(N, L));                    // ① 漫反射系数
float spec = pow(saturate(dot(R, V)), _Smoothness); // ② 高光系数

float3 color = _BaseColor.rgb * ndl  * _LightColor.rgb
             + _SpecColor.rgb * spec * _LightColor.rgb
             + _AmbientColor.rgb;                          // ③ 环境项

6.4 光照分析的基本框架

直接光与间接光、漫反射与镜面反射，这两组二分法一交叉，就得到了一张 2 × 2 的表格。 它是排查光照问题的第一张地图：任何一项光照，都落在这四个格子里。

这四个格子加起来，就是一张材质最基础的"光照账本"：

// 基础框架：四个格子相加
直接光漫反射 + 直接光镜面反射 + 间接光漫反射 + 间接光镜面反射

// 在它之上继续加细节
+ 环境光遮蔽 AO        // 压暗缝隙与夹角，让间接光"讲道理"
+ 反射 Reflection      // 屏幕空间反射 / 平面反射
+ 次表面散射 SSS       // 皮肤、玉石：光穿透后再溢出
+ More…               // 各项目按需叠加

= 最终颜色

7.1 帧缓冲：三张画布叠在一起

片元上完色之后，还有最后一道关卡：它到底能不能写进画面、怎么写进去。 这道关卡由输出合并阶段负责，它手里有四个动作，按固定顺序执行： Alpha 测试 → 模板测试 → 深度测试 → 混合。全部通过之后，结果才会写进帧缓冲。

拿两个三角形走一遍就很清楚：先画蓝三角，它的颜色写进 Color Buffer， 同时把每个像素的深度写进 Depth Buffer；再画红三角时， 每个片元先拿自己的深度和 Depth Buffer 里已有的值比 —— 更近就覆盖颜色并更新深度，更远就直接丢弃。遮挡关系就是这么"算"出来的。

7.2 深度测试与 Early-Z

深度相关的行为可以拆成两个独立的开关： 深度测试（ZTest，比不比）和深度写入（ZWrite，通过之后要不要把新深度存下来）。 测试用的是一个比较函数，常用的几种是：

但这里藏着一个浪费：按传统顺序，深度测试发生在片元着色之后。 也就是说，那些最终会被挡住的片元，颜色已经算完了 —— 白白花了算力。 Early-Z 就是把深度测试提前到片元着色之前：

7.3 混合：半透明的正确打开方式

不透明物体走到深度测试就结束了：赢了就覆盖，输了就丢弃。 半透明不行 —— 它必须和已经在画面上的颜色混在一起，所以多了"混合"这一步：

SubShader {
  Tags { "Queue" = "Transparent" }   // ① 排到 2500 之后的半透明队列

  Pass {
    ZWrite Off                            // ② 不写深度，避免挡住后面的半透明
    Blend SrcAlpha OneMinusSrcAlpha       // ③ 标准 Alpha 混合
    // …片元着色…
  }
}