URP 光照管线深度剖析：Forward 与 Deferred 渲染路径的选型决策模型
Forward 多光源性能瓶颈机制 · Deferred G-Buffer 架构与透明物体限制 · Forward+ 引入背景 · 移动端特殊考量
在 Unity URP 中切换渲染路径是每个独立游戏开发者迟早要面对的技术决策。它不是一个「选 Forward 还是 Deferred」的二元问题，而是在光源数量、透明物体比例、目标平台算力三个维度上寻找最优交集的多维决策问题。
本文从底层原理出发，建立三层评估框架帮助独立开发者做出架构级正确选择，并给出每种选择的最优参数配置模板。
Forward Rendering 的光照计算复杂度
Forward Rendering 的渲染逻辑：对于每个可见物体，遍历所有影响该物体的光源，为每个光源计算一次完整的颜色输出，结果累加。数学上，一个拥有 N 个物体、M 个光源的场景，Forward 路径的 Pass 数量上限为 N × M。
当光源数量有限（通常 URP 默认限制每物体 8 个光源）且物体数量可控时，Forward 是高效的。但当场景中存在 10 个以上的可见 Point Light 时，Draw Call 数量和 Fill Rate 压力会线性增长——这就是 Forward 的多光源性能瓶颈机制的本质。
URP 的 Forward 优化手段：URP 在 Forward 路径上内置了每物体最大光源数限制（Additional Lights Count），超出限制的光源以逐顶点（Per-Vertex）方式计算，而不是逐像素（Per-Pixel）。这是一个性能降级策略——远处的额外光源会失去像素级的精细度，但代价只是略显粗糙，远好于完全没有光照。
Deferred Rendering 的 G-Buffer 架构
Deferred Rendering 的渲染逻辑分为两个阶段。几何阶段（Geometry Pass）：将每个物体的材质属性（颜色、法线、光滑度、金属度等）渲染到多张渲染目标（MRT，Multiple Render Targets）中，这组 RT 统称 G-Buffer。
光照阶段（Lighting Pass）：对屏幕上的每个像素，从 G-Buffer 中读取材质属性，计算所有光源的累加光照。光照复杂度从 Forward 的 N × M 降为（屏幕像素数 × 光源覆盖该像素的影响范围）。
这种架构带来一个核心优势和两个限制：
核心优势：光源数量不再影响几何渲染的性能——不管场景中有 5 个还是 50 个 Point Light，几何 Pass 的开销完全相同。光照 Pass 的开销取决于每个光源覆盖的屏幕面积，而不是场景中的物体数量。
限制一：透明物体无法参与 Deferred Pass。G-Buffer 无法存储多层材质属性的叠加信息，因此透明物体必须在 Forward 模式下单独渲染。当一个场景中透明物体占比超过 20%，Deferred 的优势就被大幅削弱。
限制二：G-Buffer 内存带宽消耗大。典型的 URP Deferred G-Buffer 包含 3-4 张 RT（法线+光滑度、漫反射+金属度、深度等），总带宽占用约 200-400 MB/s，对移动设备是一个显著的负担。
Forward+（Cluster-based）的引入背景
URP 12.x 及以后版本引入了 Forward+ 渲染路径，作为 Forward 和 Deferred 之间的折中方案。其核心思想是：将屏幕空间划分为二维网格（Tile），每个 Tile 维护一组影响该区域的光源列表。在光照计算时，每个像素只需遍历其所在 Tile 的光源列表，而不是检查场景中所有光源。
Forward+ 的优势：保留了 Forward 对透明物体的原生支持，同时大幅缓解了 Forward 的多光源性能瓶颈。它特别适合光源数量多但每个光源覆盖范围小的室内场景——在这种情况下，每个 Tile 的光源列表很短，光照计算复杂度几乎与光源总量无关。
Forward+ 的局限：Tile 细分需要计算着色器（Compute Shader）支持，部分移动 GPU 不支持或性能不佳。
独立游戏渲染路径选型决策矩阵
| 场景特征 | Forward | Forward+ | Deferred |
|---|---|---|---|
| 每帧光源数 ≤ 8 | ✅ 推荐 | ✅ 可用 | ⚡ 过度 |
| 每帧光源数 8–30 | ⚠ 边缘 | ✅ 推荐 | ✅ 推荐 |
| 每帧光源数 > 30 | ❌ 不推荐 | ✅ 可用 | ✅ 推荐 |
| 透明物体占比高（>20%） | ✅ 推荐 | ✅ 推荐 | ⚠ 需混合 |
| 移动端低端设备 | ✅ 推荐 | ⚠ 视 GPU | ❌ 带宽限制 |
| PC 中高端 | ⚠ 可用 | ✅ 推荐 | ✅ 推荐 |
| 需要 MSAA | ✅ 原生支持 | ✅ 原生支持 | ❌ 需定制 |
| 需要 HDR + Tonemapping | ✅ | ✅ | ✅ |
一键决策规则：如果你不确定，选择 Forward+。它在大多数场景下是 Forward 和 Deferred 的最佳平衡点。只有当目标平台不支持 Compute Shader 时才回退到 Forward。只有当光源数量确实超过 30 且透明物体极少时才考虑 Deferred。
移动端选型的特殊考量
移动端的 Tile-Based Deferred Rendering（TBDR）架构对光照进行硬件级别的优化。Apple 的 PowerVR 系列 GPU 和 ARM 的 Mali 系列对 TBDR 有原生支持。
在 TBDR 架构下，Deferred Rendering 的 Tile 内存特性与硬件架构天然匹配——几何阶段的数据在 Tile 本地缓存中完成处理，无需频繁访问主存带宽。这意味着在某些移动 GPU 上，Deferred 的性能反而可能优于 Forward。
但前提是：Deferred 的 G-Buffer 总带宽不超过 Tile 本地缓存的容量。超过后，数据会 spill 到主存，性能急剧下降。对于中低端移动设备，G-Buffer 至少需要 3 张 16-bit RT（法线+粗糙度/金属度、漫反射+AO、深度），每张 1280×720 的 G-Buffer 约 5.3 MB——在 32 KB Tile 缓存面前，四张同时加载不可行，需要逐 Tile 处理。
移动端基线建议：
- 低端移动设备（Mali-G52 级别）：使用 Forward，每物体最大光源数限制为 2（主光+环境光）
- 中端移动设备（Mali-G76 / A13 级别）：使用 Forward+，最大光源数 4
- 高端移动设备（Mali-G78 / A17+）：可选 Forward+ 或 Deferred，最大光源数 8
社区核心争议：Forward+ 是否真的「解决了」问题
自 Unity 引入 Forward+ 以来，社区对其实际效果一直存在分歧。支持方认为 Forward+ 在 90% 的场景中消除了 Forward 与 Deferred 之间的选择困惑——它既保留了 Forward 的透明物体支持和 MSAA 兼容性，又在多光源性能上接近 Deferred。
反对方指出：Forward+ 的 Tile 计算开销是固定的，即便场景中只有一盏灯，也要执行 Tile 划分的计算着色器调度（约 0.2–0.4ms 的开销）。在光源较少的场景中，这个固定开销毫无意义。此外，Forward+ 的 Tile 边界处的光照接缝问题（当光源被 Tile 边界一分为二时）需要 extra pass 处理，增加了实现复杂度。
我们的观点：对于独立游戏，Forward+ 的固定 0.2ms 开销相对于它提供的多光源性能保障，是值得支付的保险。只有当你的游戏场景中每帧光源几乎不超过 4 个时，才应该直接使用 Forward。