全局光照引擎选型横评：Enlighten、Progressive Lightmapper 与第三方方案的深度对比
从 Enlighten 退役到 Progressive 成熟 · Bakery vs Progressive 的社区辩论 · 开源替代方案调研 · 独立游戏项目的四项选型评估标准
一分钟速览
Unity 官方当前的 GI 引擎路线图已明确：Progressive Lightmapper（GPU/CPU 两种模式）是唯一推荐方案，Enlighten 在 Unity 2022 LTS 之后逐步退役。对于独立游戏项目，默认选择 Progressive GPU Lightmapper（30 分钟以内场景可出高质量烘焙结果）。若项目需要极高质量的表面质量或极短的迭代周期（10 分钟级），可以考虑第三方方案 Bakery。以下详细拆解各方案的技术特征与选型逻辑。
一、Unity GI 引擎的三个时代
理解 Unity GI 引擎的演进，有助于理解为什么今天 Progressive Lightmapper 是唯一合理的选择。
时代一：Enlighten 时代（Unity 5 – Unity 2021）
Enlighten（由 Geomerics 开发，2014 年被 Unity 收购）是 Unity 历史上第一个内置 GI 方案。其核心思路是预计算辐射度传输（Precomputed Radiance Transfer, PRT）：对场景中静态物体的表面进行辐射度预解算，基于这一预解算实现实时光照变化的间接光照反映。
Enlighten 在发布时具有划时代意义——首次让中等配置 PC 可以在运行时看到间接光照变化。但它的局限同样显著：需要预计算步骤、不支持 GPU 加速、内存开销大、对场景复杂度敏感。当 Progressive Lightmapper 在 Unity 2019 中引入并快速迭代成熟后，Enlighten 的退役已不可避免。
时代二：Progressive Lightmapper 时代（Unity 2019 – 至今）
Progressive Lightmapper 基于路径追踪（Path Tracing）算法，其核心理念是渐进式采样：先渲染一个粗糙结果（几秒钟内可见），然后持续用更多样本降噪直至质量达标。两种模式选择：
| 特性 | Progressive GPU | Progressive CPU |
|---|---|---|
| 硬件需求 | DX11+ / Vulkan GPU（建议 ≥4GB VRAM） | 任意 CPU（利用多核） |
| 采样速度 | 快（尤其是 1080Ti / RTX 级别以上） | 慢（通常为 GPU 模式的 1/3–1/5） |
| 稳定性 | 依赖 GPU 驱动（某些 AMD 驱动版本存在闪退风险） | 高度稳定，适合长时间运行（如云计算烘焙） |
| 最佳场景 | 迭代调试（10–30 分钟出预览） | 最终打包（可运行数小时确保无噪点） |
| 内存限制 | 受 GPU VRAM 限制（大场景需降低贴图分辨率） | 受系统内存限制（通常比 GPU 模式容量大 2–3 倍） |
时代三：未来——实时 GI 与 AI 辅助
目前 Unity 的方向是 HDRP Ray Traced GI（需要 RTX 硬件）和 Adaptive Probe Volumes（APV，在 Unity 6 中替代 Light Probe 系统）。Progressive Lightmapper 在可预见的未来仍将是最主要的静态烘焙方案，但 APV 和实时 GI 的演进值得关注（参见主题 8 和主题 18）。
二、Bakery：社区最值得关注的第三方方案
Bakery（Asset Store 付费，约 $65）是 mr-gi.com 开发的独立 GPU Lightmapper，采用与 Unity Progressive GPU 类似的路径追踪核心，但在几个维度上取得了显著优势：
Bakery 的 3 个核心优势
- 速度优势显著：在同级 GPU（RTX 3060）上，Bakery 达到同等噪点阈值（SNR 40dB）的采样速度 ≈ Progressive GPU 的 1.8–2.5 倍，主因是 Bakery 使用了经过优化的 BVH 构建和光线样本分布策略。
- 光晕控制更细腻：Bakery 支持独立的 Lightmap Smoothness 调节和边缘光晕去除，对于高对比度的边缘场景（窗框附近的强烈阴影过渡）表现更好。
- 批量场景烘焙自动化：Bakery 提供了命令行模式（C# API），可以编程式中断重启批量烘焙，而 Progressive 的自动化支持较弱。
Bakery 的局限
- 不支持移动端方向性 Lightmap（Directional Lightmap 仅限 PC/Console）
- 需要学习额外的工作流和独立于 Unity 烘焙 UI 的 Bakery 面板
- 对 Unity 版本升级的兼容窗口期可能比官方方案长（每次 Unity 大版本更新，Bakery 需要 2–4 周适配）
三、独立游戏项目的选型决策框架
没有绝对的"最佳"方案——只有适合你特定约束条件的方案。以下四项评估标准帮助定位：
| 评估维度 | Progressive GPU | Progressive CPU | Bakery | 备选 |
|---|---|---|---|---|
| ① 项目规模 | 中小场景（< 10 个场景） | 大场景（10+） | 中大型场景 | 混合：中小用 GPU，最终用 CPU |
| ② 迭代频率 | 高（每天多次烘焙） | 中 | 高（Bakery 自动化加速） | — |
| ③ 画质要求 | 良好 | 优秀（更多样本） | 优秀（尤其是边缘质量） | 如需要 Directional Lightmap 必须选 Progressive |
| ④ 团队技术储备 | 零学习成本（内置 UI） | 零学习成本 | 中等（需学 Bakery 面板） | 人员变更频繁的项目不建议 |
编辑观点：对于 90% 的独立游戏项目，Progressive GPU Lightmapper 是完全足够的选择，而且零额外成本、零学习成本、零兼容风险。只有当你在烘焙调试中已经明确感受到"等待时间超过了心流断裂阈值"（通常为每次烘焙 > 30 分钟），才值得为 Bakery 投资。不建议在项目早期就引入 Bakery——先用 Progressive 完成所有内容填充和光照搭建，最后在 polish 阶段评估是否要切换。
四、开源与免费替代方案
对于预算极其有限的独立开发者，以下开源方案可以关注：
- Cycles（Blender 内置）：将场景导出到 Blender，使用 Cycles 渲染器进行烘焙，再导回 Unity。工作流成本高（需要双向同步），但 Cycles 的物理渲染质量是水准最高的选项之一。适合对画质精益求精且不介意跨软件工作流的团队。
- Lightmapping via Bakery-Free trial：Bakery 提供 14 天全功能试用，可以在评估阶段体验其速度优势。
- 自定义烘焙 Pipeline（实验性）：基于 Compute Shader 编写简单的路径追踪烘焙器，仅适合有图形学开发能力的团队，不建议作为生产方案。
五、常见失败原因与工程化应对
烘焙时间过长（> 2 小时）：通常是 Lightmap Resolution 过高或场景中 Triangle 数量过多导致。应对：先使用 1/2 分辨率测试烘焙确定光照方向，再以全分辨率做最终烘焙；使用锁定的 Scene（Prefab 化）减少场景总三角面数。
烘焙结果出现噪点：低采样数下的常见问题。Progressive Lightmapper 中可提高 Direct Samples 和 Indirect Samples（两者独立，Indirect 通常需要 2–4 倍 Direct 的采样数才能消除噪点）。
GPU Lightmapper 闪退/Crash：特别是 AMD 显卡上常见。应对：在 Lighting 窗口中切换至 CPU Lightmapper 作为备选；检查显卡驱动版本（推荐 Studio 驱动而非 Game Ready 驱动）。
Lightmap 压缩导致 Artifact：BC6H（HDR）格式在部分 GPU 上渲染结果出现带状条纹。应对：在 Quality Settings 中禁用 Generate Striped Data，或使用更高精度的压缩格式（如 ASTC 在高通设备上的表现优于 ETC2）。
推荐资源
- Bakery 官方文档：mr-gi.com/documentation（注意对比版本是否适配当前 Unity）
- Unity Learn：Lighting Best Practices 课程（涵盖 Progressive Lightmapper 的完整配置）
- 社区讨论：Unity Forum > Lighting 子板块——各方案的使用者经验分享是最直接的参考源