说实话，写这篇Part 2之前，我犹豫了很久。Part 1拆的是直接光照和PBR材质，那属于“把饭煮熟”的范畴，参数调得再离谱，只要方向对，画面总能看。但全局光照不一样，它决定的是“这顿饭有没有锅气”，是渲染里最微妙、也最容易被性能预算卡死的一环。Unity URP、Unity HDRP、UE4这三套方案，放在同一个场景里测GI，你会看到三种完全不同的设计哲学，也基本预示了项目中期你会在哪个坑里哭。
这篇文章我不打算堆参数表，也不做那种“A比B好”的粗暴结论。我会直接拆解：这三个方案各自的全局光照是怎么算出来的、在什么场景下会露馅、以及你作为开发者在选型时真正该关注什么。如果你是做场景美术、TA或者图形程序，这篇文章至少能帮你省掉两三天瞎试的时间。
1. 先捋清楚：这一轮到底在比什么
网上聊Unity和UE渲染对比，最容易陷入“画质碾压”的争论。但全局光照这块，画质只是表象，核心差异在于间接光的来源和实时性。
简单回顾一下PBR管线里全局光照的位置。直接光（太阳、点光源）是一次弹射，计算简单，大部分引擎都做得很好。真正让画面“活”起来的，是间接光：阳光打到地面再反弹到墙面、墙壁之间的颜色互相渗透、暗部不至于死黑。这些间接光，就是全局光照要解决的。
三套方案其实代表了三条技术路线：
- URP（轻量管线）：以离线烘焙为主，实时全局光照基本不做，或者说受限于平台和性能，做得非常克制。
- HDRP（高清管线）：混合路线。默认用屏幕空间全局光照（SSGI）做实时间接光，同时保留烘焙光照图（Lightmap）和反射探针（Reflection Probe）作为补充。
- UE4（以Lumen为代表）：实时全局光照的激进派。从4.26开始，Lumen用一套软件光栅化和屏幕追踪的组合方案，实现了动态GI，完全不依赖烘焙。
这三条路线没有谁绝对先进，因为它们服务的平台和项目类型完全不同。URP服务的是手机和低端PC，HDRP服务的是高端PC和主机，UE4（尤其Lumen）默认你有一颗不错的显卡，且愿意为画质付出性能。
比较的关键维度只有四个：实时性、质量、工作流复杂度、性能开销。后面的所有内容，都是围绕这四个维度展开的。
2. Unity URP的全局光照：在性能悬崖边跳舞
2.1 URP的GI构成：烘焙为主，实时基本为零
先说结论：URP的全局光照，本质上是“预计算”的。项目里看到的间接光，99%来自两部分：
- Lightmap（光照贴图）：把静态物体烘焙到一张纹理上，贴图里存的就是这个表面收到的直接光和间接光总和。运行时直接采样，不额外计算。
- Light Probe（光照探针）+ Reflection Probe（反射探针）：负责给动态物体提供间接光。探针记录的是周围空间的光照信息，动态物体移动时按位置插值采样。
这种方案的优势非常明显：运行时开销极低。光照结果已经被烘焙进纹理了，每像素成本就是一次纹理采样，移动端完全扛得住。这也是URP默认推荐的工作流。
但代价也很惨烈：场景里的任何变化，都需要重新烘焙。你挪了一把椅子，如果它是静态物体且参与GI，烘焙结果就变了。更麻烦的是，动态物体只能从光照探针获取间接光，精度远不如烘焙进贴图的静态物体。同一个场景里，静态和动态物体挨着站，你会发现静态物件的暗部有细腻的反光，动态角色身上的暗部却像糊了一层灰——这是Light Probe插值精度不足的典型表现。
2.2 实操：URP的烘焙参数和Lighting设置
URP烘焙用的是Unity内置的Progressive Lightmapper（渐进式光照贴图烘焙器）。它和旧版Enlighten最大的区别是：基于路径追踪算法，CPU和GPU都能烘焙，而且烘焙过程中可以实时预览。
关键参数设置：
- Lightmapper选择：在Player Settings里可以切CPU/GPU。GPU烘焙（OptiX）通常比CPU快3~10倍，前提是你有一张N卡。CPU版本胜在稳定，内存不够或者场景极复杂时反而更可靠。
- Lightmap Resolution：单位是“像素/世界单位”（texels per unit）。室外大场景建议2~4，室内小场景4~8。这个值直接决定锐度和烘焙时间，翻倍意味着四倍的像素量。
- Lightmap Padding：相邻UV岛之间的间距，单位是像素。太小会漏光，太大浪费分辨率。经验值4~8像素。
- Max Lightmap Size：控制单张图最大尺寸，超出会被拆成多张。移动端建议512或1024，PC可以到2048。
- Compression：移动端保持Normal Quality，PC可以High Quality，注意观察色彩断层。
除了这些，还有两件事是新手最容易忽略的：
UV2的Generation Mode：模型必须有第二套UV（也叫Lightmap UV）。URP支持自动生成，但自动生成的UV在处理复杂模型时经常产生重叠的UV岛，导致烘焙结果出现条纹和漏光。规范的流程是在DCC软件（如Blender、Maya）里手动展一套不重叠的UV2，尤其是建筑类项目，这一步千万不能省。
Static Flag（静态标记）：只有标记为Contribute GI（在Static下拉菜单里勾选）的物体才会参与烘焙。很多人刷了一组反射探针，却忘记把需要贡献间接光的物体标记为静态，烘焙结果自然缺东西。
2.3 URP的瓶颈：网格“漏光”与动态物体缺失感
URP烘焙方案有一个非常经典的痛点：Lightmap漏光（Light Leak）。比如一个墙角，烘焙后从接缝处透出光线，或者天花板和墙壁交界的地方出现一圈亮边。原因通常不是光参数错了，而是Lightmap分辨率太低、UV岛间距不够，或者模型本身的几何体在烘焙时没有足够的封边（padding）。
如果项目组里没人懂烘焙，这个坑会在第一次室外场景测试时集中爆发。一群美术围着烘焙结果改半天，最后发现是建模师偷懒没展UV2。
动态物体的缺失感更隐蔽。URP的Light Probe只记录球谐光照（SH），精度很低。如果角色在室内，周围有一盏很亮的台灯，角色靠近台灯时身体的受光变化，烘焙方案里几乎没有反应，因为探针无法捕捉这么细致的亮度梯度。HDRP的SSGI和UE4的Lumen在这一点上吊打URP，不是算法多先进，而是它们根本没有放弃动态物体的间接光。
所以，如果你做的是移动端或者中低端PC项目，URP的烘焙GI是唯一现实的选择，但必须接受它的两个先天短板：场景变更需要重新烘焙、动态物体的光照精度低。
3. Unity HDRP的全局光照：把“实时”和“烘焙”缝在一起
3.1 HDRP的SSGI：屏幕空间的间接光
HDRP默认启用的实时GI方案是SSGI（Screen Space Global Illumination）。它的原理可以这样理解：把屏幕渲染出来的颜色和深度信息当成一个“缓存”，然后在这个缓存里做光线步进（Ray Marching），追踪每个像素的间接光来源。
好处是完全动态。物体移动、光源变化、材质变化，间接光立刻跟着变，不需要任何烘焙，也没有Lightmap分辨率的概念。你推倒一面墙，墙背后的间接光瞬间变化，这在URP烘焙里是不可想象的。
代价也很明显：SSGI只能看到屏幕内能看到的东西。光线被屏幕边缘截断，或者被靠近摄像机的物体挡住，后面的间接光就消失了。比如你在墙角放了一盏灯，灯光被墙壁本身挡住，屏幕上看不到那面墙的另一侧，SSGI就无法把光“跑”到墙后面。这导致HDRP场景在特定角度下会出现间接光“跳变”，物体转动时，暗部颜色突然变亮或变暗。
3.2 HDRP的混合路线：烘焙GI + 实时GI共存
HDRP比URP聪明的一点是：它允许你把烘焙GI和实时GI叠加使用。默认设置下，间接光照来源是“Mixed”状态，同时包含Lightmap和SSGI贡献。
具体做法：
- 静态物体继续烘焙Lightmap，保证大面积、稳定的间接光质量。
- 动态物体、以及SSGI能覆盖到的区域，用屏幕空间的方式补充实时间接光。
- 反射探针（Reflection Probe）负责镜面反射和高光反射的间接光。
这套混合方案的意义在于：它兼顾了质量、实时性和性能。大面积的地面、墙壁、天花板，用烘焙贴图保证稳定；角色、可移动物体、以及快速变化的光源，交给SSGI。视觉上既没有烘焙方案的呆板，也没有纯实时方案的噪点和性能压力。
不过注意，HDRP的SSGI是逐像素的，性能消耗随着屏幕分辨率上升。4K下全开SSGI，中端显卡很容易掉帧。建议用Adaptive Resolution或者把SSGI质量档位降到Medium，效果依旧可接受。
3.3 实操：HDRP的GI设置顺序和避坑
HDRP的GI配置相对复杂，但你只要按顺序做完三件事，基本不会出大问题：
确认Lighting Mode：HDRP的Lighting Mode有Realtime、Mixed、Baked三种。如果你想着重体验SSGI，可以先用Realtime模式，等画面稳定了再开Mixed补烘焙。实际项目建议直接从Mixed开始，因为Realtime模式下没有Lightmap支撑，大面积场景的间接光质量会非常差。
Volumetric（体积光照）别乱开：HDRP的体积雾（Fog）和体积光（Volumetric Lighting）虽然好看，但会严重影响GI表现。体积光参与间接光计算，导致SSGI的追踪路径被体积雾干扰，产生光晕和噪点。没把握的情况下，先关掉Volumetric，把GI调对再开。
Reflection Probe的摆放密度：HDRP的反射探针比URP更吃资源，而且反射分辨率极高。不要在场景里无脑刷几十个探针，每面墙一个探针的做法在HDRP里就是性能灾难。建议：室内房间最多2~3个探针，室外用天光（Sky）里的反射烘焙代替。
遇到过这样的案例：团队第一次接触HDRP，美术按URP的习惯在每个房间摆4个反射探针，结果场景掉帧严重。排查到后来，不是GI的锅，是反射探针本身每帧都在做立方体贴图采样，数量一多，性能直接崩。
3.4 HDRP的局限：SSGI的“屏幕空间”致命伤
前面提过，SSGI只能处理屏幕内的信息。这带来一个特殊的bug场景：摄像机背后有光源，物体正面的间接光完全不可用。比如你站在一间房间里，背后的窗户透进天光，你面前的一面墙理论上应该被天光影响，但因为摄像机看不见窗户，SSGI对墙的间接光贡献为零，墙面暗部直接死黑。
解决方法是加一个较低强度的烘焙Lightmap作为“兜底”，或者在场景里放一个低优先级的光照探针，确保SSGI失效的区域依然有名无实的间接光来源。HDRP默认就带了这套兜底机制，但很多人不明所以，把它关掉了，导致各种莫名其妙的暗部问题。
4. UE4的全局光照：Lumen是怎么把烘焙逼到墙角
4.1 传统UE4方案：Lightmass和Volumetric Lightmap
在Lumen之前，UE4的全局光照分成两条线：
- 静态光照烘焙（Lightmass）：类似Unity的Progressive Lightmapper，生成光照图（Lightmap）和体积光照图（Volumetric Lightmap）。质量高，但同样有烘焙时间长、动态物体无GI的毛病。
- ILC（Indirect Lighting Cache）和SSGI：UE4早期通过引擎自带的 Screen Space Global Illumination 来做动态GI，但质量和效率都不够稳定，被Lumen取代是顺理成章的事。
Lightmass这套方案在室外的表现其实相当好，大场景的地形、建筑、植被的间接光烘焙很细腻。但室内动态场景就非常吃力了。比如一个可开关的灯，开关瞬间所有静态物件的光照变化需要实时计算，这就不是烘焙能解决的，而这个功能在Lumen里是基本的。
4.2 Lumen的核心思路：不烘焙，也能实时全局光照
Lumen的出现，是UE4对“动态GI”的一次彻底转向。它把全局光照拆成了两个部分：
- 屏幕空间追踪：和HDRP的SSGI类似，在屏幕范围内做光线追踪，捕捉最直接的间接光。
- 软件光栅化表面缓存（Surface Cache）：这是Lumen真正厉害的地方。它不追踪每一条光线，而是把场景中的Mesh先光栅化到一张低分辨率的“表面缓存”（Surface Cache）里，然后在缓存里做多弹射。相当于离线烘焙的Lightmap被实时更新了，更新频率很低（每帧或每几帧），但结果近乎实时。
这两个部分合在一起，Lumen能做到：动态物体的间接光实时更新，静态物体的间接光也实时更新，而且光线可以跨越屏幕边界。比如前面的“窗户在身后”场景，Lumen用表面缓存记录了窗户后的光照信息，墙面依然能收到间接光。这一点就远超HDRP的SSGI。
而且Lumen默认支持软件追踪，不一定需要RTX显卡。中低端的显卡也能跑，只不是质量低一些、分辨率和弹射次数降一些而已。这是它在兼容性上比硬件光追大的多的优势。
4.3 实操：Lumen的调试参数和性能感知
Lumen的全局光照质量主要由三个参数决定：
- Final Gather Quality：负责最终聚集的精度，数值越高，画面越干净，但没有明显噪音。建议至少4，追求画面干净可以到8以上。这参数在后期处理体积（Post Process Volume）里调整。
- Radiance Cache Quality：控制间接光照的缓存精度，影响暗部的层次。提升这个值能减少暗部的“涂抹感”。
- Scene Detail Quality：控制场景缓存的分辨率。它决定表面缓存的细节量，调高后，小草、小物件也能有更准确的间接光，代价是显存和带宽。
调试Lumen的经验：不要一上来就拉满参数。正确的流程是，先用低参数跑一版，把发现明显问题的灯光和材质先修正，比如曝光、自发光强度不对，这种基础问题在高参数下会掩盖掉。等场景稳定性了，再逐步提高Final Gather Quality到想要的档位。
性能方面，Lumen在室内和室外的消耗不一样。室内因为空间小，光反弹距离短，表面缓存更新少，性能相对轻松。室外的开阔场景，地形和植被的间接光需要处理更多几何体，负载明显增加。建议室外优先开Lumen的“Screen Space”选项，减少Surface Cache的工作量。
4.4 Lumen的质量死角：反射和粗糙度
Lumen的间接镜面反射（即屏幕上物体反光）依然依赖屏幕空间和Surface Cache，粗糙度较高时数据会变糊。这导致一些材质（比如金属、漆面、水面）在高光反射质量上不如传统反射探针方案。UE4社区常见的方法是：Lumen负责间接漫反射，额外的反射捕获（Sphere Reflection Capture或Planar Reflection）负责镜面反射细节。两套方案叠加用，效果才完整。
5. 横向对比：同一场景，三种思路
下面这个表可以直接抄走，做项目技术选型时放在评审文档里非常有用。
| 维度 | Unity URP（烘焙GI） | Unity HDRP（SSGI+烘焙） | UE4（Lumen） |
|---|---|---|---|
| 间接光实时性 | 无（烘焙固定） | 屏幕内实时，屏幕外靠兜底 | 完全实时（含屏幕外） |
| 动态物体GI | 探针插值，精度低 | 屏幕内准确，屏幕外缺失 | 准确且完整 |
| 场景变更成本 | 重新烘焙 | 无需全量烘焙，混合方案 | 无需烘焙 |
| 质量上限 | 受Lightmap分辨率限制 | 高，但有屏幕空间瑕疵 | 高，暗部噪点需调参 |
| 平台适配 | 移动端、低端PC | 中高端PC、主机 | 中高端PC、主机 |
| 主要痛点 | 动态物体假、烘焙迭代慢 | 屏幕边缘“跳光”、性能波动 | 调参门槛高、反射较弱 |
用同一个室内场景来举例：
场景设定：一个白天阳光透入的房间，房间中央有一把椅子可以拖动。
- URP：烘焙完成后画面很干净，椅子是动态物体，靠近窗户时椅面上的间接光完全不变，黄黄的一片。移动椅子并不会触发重烘焙，但你想把墙刷成深浅不同的颜色，需要重新烘焙，等十几分钟，再看效果。
- HDRP：椅子的间接光随位置变化，靠近窗户时确实亮了一些，但椅背转到侧面、窗户被椅子自身挡住时，间接光马上跳到另一个值。墙面的变化是实时的，因为SSGI在算，代价是帧率掉几帧。
- Lumen：椅子面的光影变化自然顺滑，墙面的颜色变化也是实时。没有跳变感，但暗部有轻微噪点，需要调高一档Final Gather Quality才能接受。
这个对比不是说谁赢谁输。URP在这个场景里是最快、最稳的；HDRP在动态和性能之间取了个平衡；Lumen则是在画质和动态性上更激进，但对硬件和调参要求更高。
6. 实操中容易踩的坑与排查思路
这几年帮团队排查渲染问题，发现全局光照的很多怪现象其实都有固定套路。下面几类问题出场率最高，直接整理成速查表。
| 症状 | 原因 | 排查方式 |
|---|---|---|
| 静态物体表面有条纹/漏光 | Lightmap UV2重叠或间距不够 | 检查模型的UV2是否重叠，调整Padding到合理值 |
| 动态物体暗部颜色脏/变化失真 | Light Probe密度不足或位置偏移 | 在亮度梯度大的区域手动加探针，检查探针是否被物体卡住 |
| 角色靠近墙时，间接光突然消失 | HDRP的SSGI只追踪屏幕内 | 降低硬件要求，补充烘焙Lightmap兜底，或者让摄像机角度能看到光源 |
| 全场景偏暗、暗部死黑 | 曝光设置和GI强度不匹配 | 检查Physical Camera/Auto-Exposure设置，再考虑提升GI（反射）强度 |
| Lumen暗部噪点像“雪花” | Final Gather Quality过低 | 调高Final Gather Quality到8；注意后期体积里的Temporal Filter也要开 |
| 移动端烘焙结果色彩断层 | 压缩格式和Lightmap精度不够 | 提高Lightmap的Max Size或者改用RGBAHalf格式 |
| 场景里有大量反射探针，帧率狂掉 | 反射探针数量过多 | 用反射探针池或降低单个探针分辨率 |
还有一个几乎人人都踩过的坑：光照图坐标系不一致。URP烘焙时场景没有用统一的单位（比如一角一单位），导致了Lightmap在世界空间和UV空间的映射不一致，结果烘焙出来一片糊。无论用哪个方案，项目开头就把单位定死，引擎默认单位是多少就按这个来，别改。
7. 最后给一个排查顺序建议
如果你现在正被全局光照的问题折磨，我的建议是别急着调参数，先按这个顺序检查：
- 确认Lighting Mode和Static Flag是对的。这个问题在团队协作项目中非常常见——美术改了物体的静态标记但没有重新烘焙，或者切换了Lighting Mode导致烘焙结果无效。
- 检查反射探针和Light Probe的位置。探针被卡进墙角、被模型挡住，是最常见的光照穿透问题来源。
- 关掉雾和体积光。HDRP里这两者会干扰GI，UE4里体积雾也会污染Lumen追踪。全关掉再看效果，定位问题更干净。
- 调整曝光。很多所谓暗部有问题，其实是曝光设置错了。暗部不是死黑，是曝光值压得太低。你先试自动曝光，把EV调到合理范围再说。
全局光照是渲染里唯一需要“品”的部分。URP烘焙的光是“定妆照”，HDRP的SSGI是“半实时半离线”，UE4的Lumen是“活的光”。选哪一种，和你团队的硬件预算、项目形态、美术产能都有关系，不存在一个“永远正确的答案”。
我个人的习惯是，偏移动端项目一律烘焙，但会花足够时间调Lightmap和Probe；PC端项目优先用Lumen（因为没有明显更好的选择），如果发现硬件撑不住，再降级到HDRP的SSGI加烘焙混合方案。总之不用太纠结“哪个引擎最强”，而是要问“我的项目在哪一档，最需要哪种光照手感”。
这块内容还能往下拆，比如Lumen和HDRP在建筑可视化里的具体表现、URP烘焙在开放世界里的分块策略，这些我们之后单独开篇聊。
