Unity 光照系统 15 年演进全景：从 Forward 到 URP/HDRP 的技术迁徙史
Legacy Built-in 时代的技术特征与历史局限 · SRP 概念引入的革命性意义 · URP 与 HDRP 的分野逻辑 · 独立开发者迁移成本的真实记录
从 2008 年 Unity 2.5 内置渲染管线的雏形，到 2026 年 Unity 6 中 URP 16.x 与 HDRP 16.x 的分庭抗礼，Unity 的光照系统走过了一条漫长而曲折的演进之路。这条路上既有 Built-in 管线时代「开箱即用」的便捷，也有「黑盒不可控」的技术债务；既有 SRP 引入时「终于可以控制渲染管线」的激动，也有 URP/HDRP 分裂后「为什么同一个功能在两边的表现不一样」的困惑。
本文是整篇专题的奠基性内容，帮助读者建立光照技术的宏观认知坐标系——唯有理解每一项技术选择的历史背景，才能真正理解它们今天为什么以这样的形态存在。
第一代：Built-in 管线的光辉与阴影
在 Unity 4.x 和 5.x 时代，Built-in 渲染管线是 Unity 开发者唯一的选择。它的光照系统提供了几个在今天看来仍然足够的基础功能：Forward 和 Deferred 两种渲染路径、烘焙 Lightmap、Light Probe、Reflection Probe、以及第一个版本的实时全局光照 Enlighten。
Enlighten 的引入（Unity 5.0，2015 年）是这一时期最重要的里程碑。它是当时唯一能在游戏中实时运行的全局光照方案。然而，它的闭源特性和限制（仅支持 1 级反射、CPU 端预计算、场景修改后需要重新「补算」），也为后来的替代方案埋下了伏笔。
Built-in 管线的主要历史局限集中在三个方面：其一，光照渲染流程完全封装在 Unity 内部，开发者无法插入自定义的光照算法；其二，Forward 路径的多光源性能瓶颈始终没有得到根本解决；其三，Shader 编写必须使用 Unity 自家的 ShaderLab 语法，与行业标准 HLSL 之间存在翻译损耗。
可编程渲染管线（SRP）的革命性意义
SRP（Scriptable Render Pipeline）的引入是 Unity 渲染框架历史上最根本的架构变革。它第一次将渲染流程的控制权从 Unity 内部转移到开发者手中。开发者现在可以决定什么时候渲染阴影、用什么顺序渲染光源、如何在不同的 Pass 之间分配 GPU 预算。
SRP 的核心设计哲学有三个要点：
- 渲染流程由 C# 脚本驱动（通过 Render Pipeline Asset 和 Render Pipeline Instance），而非硬编码在引擎底层
- 所有光照 Pass 和 Shadow Pass 可由开发者自定义开关和排序
- Shader 使用可编程的 Shader Graph 或 HLSL，不再依赖 ShaderLab 的隐式光照模型
但 SRP 也带来了新的挑战：完全的控制权意味着完全的复杂度。一个空白的 SRP 项目需要开发者自己实现所有光照计算——这对大多数独立开发者来说是不可接受的。于是 Unity 团队推出了两套基于 SRP 的预制渲染管线：URP 和 HDRP。
URP 与 HDRP 的分野逻辑
URP（Universal Render Pipeline）诞生的初衷是「一套管线的移动端优化版」——它最初的名字是 Lightweight Render Pipeline（LWRP），设计目标是在移动设备上获得更好的渲染性能。随着时间推移，URP 的功能集不断扩展，逐渐发展为覆盖移动端、PC、主机三端的主流通用管线。
HDRP（High Definition Render Pipeline）则从一开始就面向高端平台——PC、PlayStation 5、Xbox Series X。它的光照系统包含了 URP 中不存在的多项高级功能：光线追踪、Screen Space GI、Area Light 实时支持、Volumetric Fog 的完整实现。
早期两者差异巨大，但随着 URP 版本的迭代（URP 10.x 引入 Forward+、12.x 引入 Deferred、14.x 引入 APV），功能差距正在逐步缩小。但核心设计哲学的分野仍然存在：URP 追求在有限硬件预算内提供最佳性价比的光照，HDRP 追求在当前硬件上限上提供最大视觉可能性。
独立开发者迁移成本的真实记录
在社区中收集了超过 50 个独立团队的迁移经验后，我们整理出一份真实的成本记录：
| 管线迁移方向 | 平均迁移时间 | 主要痛点 |
|---|---|---|
| Built-in → URP | 1–3 周 | Standard Shader 批量替换、Post-processing 配置重建 |
| Built-in → HDRP | 3–6 周 | 材质参数完全重调、光照设置推倒重来、性能基线重测 |
| URP 早期版 → 新版 | 3–7 天 | 接口变更适配、API Updater 无法覆盖的边界情况 |
| URP → HDRP | 4–8 周 | 几乎所有光照需要重新搭建、硬件升级成本 |
关键建议：不要在项目中期进行管线迁移。如果必须在项目启动前做选择，优先选择 URP——它覆盖了独立游戏 95% 的使用场景，且迁移到 HDRP 的路径比反过来更顺滑。
社区集体记忆中的关键节点
在开发者社区中，有几个光照相关的「集体记忆」事件值得记录：
- 2018 年 Enlighten 退役公告引发社区抗议——大量依赖 Enlighten 实时 GI 的项目被迫寻找替代方案
- 2020 年 URP 7.x 的 Breaking Change（LWRP 到 URP 的更名和 API 重构）导致许多已发布项目的升级工作被迫延期
- 2022 年 URP 12.x 引入 Deferred 渲染路径——社区等待了 4 年的功能终于到来
- 2024 年 APV（Adaptive Probe Volumes）的发布——被认为是 Unity 光照系统统一的第一步
这些事件表明：Unity 光照系统不是一个静态的工具集，而是一个持续演变的技术体系。开发者需要以「伴随演变」的思维方式来对待它，而不是期望找到一次设置永不过期的「终极方案」。