前阵子一个做独立游戏的朋友问了我一个挺典型的问题：同一套低模场景，在URP里烘焙完，切到HDRP之后光照颜色和亮度全变了；放到UE4里用Lightmass重新烘焙，出来的效果又是另一个味道。我说这太正常了，因为三个方案对全局光照的理解和执行路径完全不一样，URP、HDRP和UE4的GI差异，比它们之间的PBR高光算法差异大得多，也更容易让项目在后期返工。

这篇作为《Unity URP / HDRP 和 UE4 PBR 渲染对比》系列的第二篇，专门拆全局光照。我会把三套方案的底层思路、烘焙工作流、动态GI能力、性能成本以及常见坑都过一遍。无论你是Unity转UE、UE转Unity，还是从Built-in管线往URP/HDRP迁移，这篇文章应该能帮你省下至少两三轮试错的时间。

1. 先看三套管线对"全局光照"这件事的根本态度

1.1 URP：把GI当作一种预算内可选项

URP的设计初衷决定了它的GI定位。它面向的是移动端、WebGL、低端PC，这类设备对带宽、ALU和内存占用极其敏感，所以URP的全局光照能力基本就是"烘焙静态光照贴图 + Light Probe + Reflection Probe"三件套。它不提供屏幕空间全局光照，更不提供实时光追GI，Shader Graph里能调的GI相关节点也很有限。

这意味着，你在URP里做一个室内场景，如果只有一盏平行光做主光源，没有烘焙GI，暗部的死黑是正常的，不是引擎坏了。URP默认连AO都不是光照计算的一部分，而是靠美术贴图去模拟。理解了这一点，你就明白为什么URP项目的美术资源里，环境光遮蔽贴图比在HDRP项目里更重要。

1.2 HDRP：物理正确优先，GI是渲染管线的核心环节

HDRP给自己的定位就是"面向高端PC和主机平台的、基于物理的渲染管线"。它在GI侧最大的变化，是把光照的度量单位全部换成了物理单位：方向光用勒克斯（lux），点光源和聚光灯用流明（lumen）或坎德拉（candela），颜色用色温（Kelvin）。这个改动不是UI上的花活，而是直接关系到PBR能量守恒的准确性。

打个比方，URP里你放一个Intensity为1的点光源，这个"1"没有任何物理含义，纯粹是美术调出来的相对值；而HDRP里一盏灯的流明数是真实可换算的，灯光衰减、高光响应、GI反弹能量的叠加都建立在物理正确的输入上。这就是为什么同一个场景在URP里手调得好好的灯光，导进HDRP后看上去"平"了很多——因为HDRP会用物理衰减和单位换算把你的数值重新解释一遍，URP里那个"1"在HDRP里可能只相当于一个很暗的小夜灯。

HDRP的GI能力也更进一步：它在烘焙之外，支持屏幕空间全局光照（SSGI）、基于硬件光追的实时GI（RTGI）、自适应的探针体积（APV），还带了一个离线路径追踪器。这些能力对应了不同的硬件成本和视觉目标，后面我会细拆。

1.3 UE4：从离线烘焙走向动态GI的双轨制

UE4的传统强项是Lightmass离线烘焙。它基于光子映射算法，在烘焙前会向场景中发射大量光子，追踪光子在物体间的反弹，最终生成光照贴图和间接光照数据。这套方案质量高、可控性强，但对迭代速度极不友好：改一次灯光位置，烘焙通常要重跑几十分钟甚至数小时。

UE4为动态物体准备的方案是间接光照缓存（Indirect Lighting Cache），它让角色、载具等动态Actor在移动时能实时采样周围烘焙好的间接光照，效果比没有强得多，但也只是"从静态烘焙结果里插值"，不是真正的实时GI。到了UE5时代，Lumen作为默认的实时全局光照方案出现，它才真正实现了无需烘焙的动态间接光照。所以如果你在UE4里做项目，做好Lightmass烘焙仍然是最踏实的选择；如果你想追求全动态GI，考虑Lumen，但那已经是UE5的话题了。

三套管线的GI能力可以先用一张表看个大概：

看这张表你会发现，UE4的GI技术栈和Unity两个管线其实很有对应关系，只是各自的命名和工作流不同。但正是这些差异，导致了很多团队在切换引擎时的"光照水土不服"。

2. 烘焙工作流：Lightmap与Lightmass的实操对照

2.1 URP烘焙的整套参数怎么调

Unity的烘焙光照从Built-in管线到URP，再到HDRP，操作入口基本都在Window > Rendering > Lighting窗口里。对于URP项目，最常用的工作流是设置Lighting Mode为Baked Indirect，或者Submesh模式（如果希望实时光源参与直接光、只烘焙间接光的话）。前者适合纯静态场景，后者的灵活性更高，例如开关灯、调整太阳角度的效果会更自然。

烘焙分辨率我这里给一个参考起点：移动端小物件0.5~1 Texel Per Unit，中大型场景1~2，PC端强调画面质感的场景可以到2~4。Texel Per Unit的意思是模型表面每个texel对应多少世界单位，数值越小烘焙纹理越模糊，数值越大贴图越精细，内存和烘焙时间也线性上升。别忘了调整Padding值，默认是2~4个texel的空白边距，如果场景里有UV接缝漏光问题，先检查Padding而不是急着改模型。

还有两个"新手几乎必踩"的细节。第一，模型必须带有合法的Lightmap UV（也就是UV2），在模型导入面板的Lightmap UV Settings里自动生成时，要确认没有重叠、拉伸过大的岛屿。第二，静态物体要勾选Contribute GI，动态物体则要在Light Probe Group的覆盖范围内。很多人在URP里烘焙半天发现场景还是黑，大概率就是忘了把地面、墙体的Mesh Renderer设置为Static，或者没勾Contribute GI。

2.2 UE4 Lightmass：不那么快，但效果扎实

UE4的Lightmass烘焙在Build菜单里触发，它的质量主要由Lightmass项目设置控制：Static Lighting Level Scale、Indirect Lighting Quality、Indirect Lighting Smoothness。其中Static Lighting Level Scale非常关键，它决定了Lightmass在场景中放置的体素网格精度，数值越小网格越密，烘焙越精细，但时间成倍增长。我习惯在初期验证视觉时用1.0，正式出效果图时调到0.5左右，再往下调整体感收益不大，时间成本却非常高。

Lightmass的核心算法是光子映射：烘焙前期向场景发射大量携带能量的光子，光子在物体表面被吸收、反射，这个过程决定了间接光的分布。它跟Unity的Progressive Lightmapper其实在宏观思路上有相似之处（都是蒙特卡洛采样逼近真实光照），但Lightmass做了大量的平滑和滤波处理，所以最终光照贴图的低频漫反射过渡非常柔和，这是它输出版本风格化更"油画感"的原因之一。

如果你在UE4里控制的Lightmap Resolution从64一路调到512，烘焙时间增长得比你想得还猛。比较实际的做法是：先全场景用128出草稿，确认灯光数量和角度满意后，再把主景观物体调到256或512重新烘焙。UE4里Lightmap的分辨率是按Box2D比例设置的，调高后内存占用明显上升，一个开放场景的Lightmap显存占用动辄几百MB并不是新鲜事。

这里补一句：UE4的Lightmass烘焙完，如果你发现暗部有一些明显的"色带"（banding），多半是光照贴图压缩格式和精度导致的，试试把贴图压缩设置改成NoCompression或者用更高精度的Float格式。Unity这边类似的问题则可以通过关闭Lightmap的Compression或者设为High Quality来处理。

2.3 反射探针的摆放比你想的更讲究

全局光照不只是漫反射间接光，镜面反射的间接光同样重要。URP里叫Reflection Probe，UE4里叫Reflection Capture，功能上是同一类东西：捕获周围环境并生成立方体贴图，给粗糙度低的材质提供反射来源。

关键点是探针的位置。探针放得太稀，角色走到走廊拐角时，金属墙面的反射会从一个环境"跳"到另一个环境，形成肉眼可见的突变；放得太密，Draw Call和内存开销又上去了。我的经验是一般场景每20~30米放一个探针，走廊、门洞、房间转角这些反射变化剧烈的位置一定要单独放，并且在UE4里调整好Reflection Capture的Radius和Falloff，让探针影响范围平滑过渡。URP里同样有Box/Sphere两种投影模式，Box模式适合室内直角结构，Sphere适合开阔外景。

3. HDRP的进阶GI：SSGI、体积光照与光追GI的取舍

3.1 SSGI的本质：屏幕空间里"偷"间接光

HDRP提供的Screen Space Global Illumination，原理是用当前帧的深度缓冲、法线缓冲和颜色缓冲，在屏幕空间里估算每个像素点从周围环境获得的间接漫反射光。它的直观效果是：墙角不再死黑，物体交界处会出现类似环境光遮蔽的渐变，室内场景的整体亮度会明显上升。

但SSGI有先天局限。屏幕空间信息只有在相机可见的区域才存在，所以物体背后、屏幕边缘、被前景遮挡的墙面，都是它的盲区。你会看到墙角暗部"一闪一闪"或者大面积漏光的情况——这是SSGI在尝试从有限的可见像素里硬猜不可见光照的结果。开启SSGI后，画面中物体移动幅度较大时还会有拖影或者能量闪烁，因为它依赖帧间历史数据做累积。

所以我的建议很直接：SSGI适合做"增强"，不适合做"主GI"。把它当作场景中动态区域、角色周围区域的一种补光手段，静态大范围的间接光照该烘焙还是要烘焙。HDRP里SSGI的开关在HDRP Asset里开启后，还可以在Volume组件里调Intensity和扩散速度。性能开销方面，在4K分辨率下SSGI大约会吃掉整个帧时间的15%~25%，移动端根本不用考虑。

3.2 体积雾：被低估的"间接光放大器"

HDRP里还有一个容易被忽略的GI相关项：Volumetric Fog。它看起来只是雾效，但实际上雾的散射和吸收作用会改变整个场景的明暗层次。开了Volumetric Fog后，光从窗口射进室内，灰尘颗粒和空气都会"接住"光源，形成光柱和光晕，这种感觉会让眼睛误以为GI计算得更精准。

Volumetric Fog对性能的影响同样不可小觑，高分辨率下的3D纹理采样和多张深度切片计算非常吃GPU。建议在主机上开启并把Density控制在0.02~0.05之间，Anisotropy调成0.3~0.7来获得更自然的散射效果。如果你只是想要一点视觉通透感，不需要真的体积光，就别开。

3.3 光追GI：实时光源下的杀手锏

HDRP的光追GI（RTGI）依赖DXR硬件，需要至少RTX 20系或RDNA2以上的显卡。它最大的价值是动态光源：太阳角度变化、室内灯光开关、手电筒照射时，间接光会实时响应，而不是像烘焙方案那样只能在烘焙时刻固定下来。

我做过一个车库门开合的HDRP演示场景：门打开，阳光照进来，地面反射光实时照亮了车底和墙面，关闭门后整个空间迅速"暗"下去。这种动态间接光的变化，用烘焙方案是根本无法模拟的，只能靠预先烘焙多套Lightmap切换，或者美术手工放置伪补光。RTGI给的是物理上正确的答案，所以它尤其适合做建筑可视化、预渲染过场动画和高端PC/主机游戏。

RTGI的代价也不小。开启后每帧的采样数决定了噪点水平，采样过低画面会出现明显的颗粒闪烁；采样提上去，帧数直线下降。我通常会把RTGI的采样控制在每秒1~2个Bounce，配合TAA和DLSS来降噪，这样在4K下还能保持可玩的帧率。如果你的项目目标是60帧主机体验，RTGI最好只在过场或者特定关卡局部开启。

3.4 APV：Unity 6带来的探针体系革新

传统Light Probe Group的放置方式，是美术手动在场景里摆放密密麻麻的探针点，室内、室外、高低落差处都要照顾到。这个工作费时费力，而且探针密度分布往往凭感觉，许多区域塞了十几根探针但贡献很小，另一些关键区域反而漏了。

Unity 6引入了Adaptive Probe Volumes（APV），它用自适应空间划分代替了手动排列的探针组，烘焙时根据场景几何的复杂度和光环境的梯度自动放置探针。APV在URP和HDRP中都能使用，烘焙出的探针数据体积比传统Light Probe Group更小，间接光照的细节表现更好，尤其适合室内外结合的大型关卡。如果你的项目即将升级到Unity 6，我建议直接把Light Probe的工作流整体迁移到APV上，不仅省时间，效果和内存占用都更有竞争力。

4. 动态光源与动态物体的GI：三种方案的临场处理

4.1 动态物体如何获得正确的间接光

不管在哪个引擎里，动态物体都无法使用静态光照贴图。Unity的解法是Light Probe：把探针分布在场景中，动态物体移动时，运行时从包围它的若干探针插值出间接光。HDRP里还可以用Light Probe Proxy Volume（LPPV）来让大型动态物体获得更精细的采样，这比单个物体的单点采样更能表现光照在物体表面的变化。

UE4对应的方案是Indirect Lighting Cache。它的工作方式略有不同：动态Actor移动时，引擎会在周围查找Lightmass烘焙好的光照信息，再用一组Sphere（球体）缓存间接光并实时插值。UE4的ILC在角色上的效果比较自然，角色从亮处走到暗处，身上的间接光会平滑过渡，不会像Unity的Light Probe那样偶尔出现"跳变"。

实操层面上，Unity的Light Probe放置一定要覆盖所有活动区域，尤其是走廊拐角、门口、楼梯上下两端；UE4则需要把Primitive Type设为Movable的物体主动开启Indirect Lighting Cache，并在项目设置里适当增大ILC的自定义缓存数量。

4.2 全动态光源的GI缺失：怎么"骗"过去

如果你在URP里用一套完全动态的灯光方案，比如白天黑夜循环、可交互灯具，静态烘焙帮不上忙，间接光照几乎等于没有。此时画面里动辄会有死黑的角落、生硬的明暗断层，纯靠美术调色很难救回来。

这时候有两个常用的"骗术"。第一是使用Light Probe Group覆盖全场景，然后让动态光源同时影响探针的k值，让探针尽量跟随最近的主光源方向变化；第二是给物体加一层基于AO贴图的暗角，用美术资源模拟间接光遮蔽效果。在URP里这两种办法组合下来，效果足以骗过大多数人的眼睛，而且性能开销可以忽略不计。

HDRP和UE4如果走全动态光，我更推荐HDRP用SSGI做补光，UE4则可以在移动端用整张烘焙光照贴图配合可移动光源的shadow来减轻违和感。指望在全动态光源下追求物理正确的间接光，只有Lumen或RTGI这类实时GI方案才能真正满足，而移动端根本吃不消这个开销，所以到头来，还是得靠美术和探针的手工搭配。

4.3 不同平台的GI预算分配

直接给一张我实测时常用的参考表（以室外半开放场景、动态主角为例）：

这张表不是绝对值，不同场景和GPU的差异很大，但可以帮你快速评估：如果一个移动端项目想在URP里上SSGI，那基本就是给帧率宣判死刑。

5. 实时GI的正面交锋：UE5 Lumen与HDRP RTGI

5.1 Lumen赢在"全动态"和"无烘焙"

虽然这篇标题是UE4，但聊全局光照绕不开Lumen。Lumen最颠覆的一点是它让"没有烘焙Lightmap"成为了可能：所有场景光直接受光源影响，房间里的灯开关、太阳移动、爆炸火光，都会实时改变整个空间的间接光分布。

Lumen的实现不是靠暴力光线追踪，而是采取软件光追（有向距离场追踪）+ 表面缓存（Surface Cache）的组合方案。它先把场景光照预计算成低分辨率缓存，再在运行时用屏幕空间追踪和SDF追踪去采样这些缓存。结果就是，它可以在GTX 10系这类不支持硬件光追的显卡上运行，只是性能表现参差不齐。而且Lumen对场景的要求比较特殊：需要开启虚拟阴影贴图（Virtual Shadow Maps），对模型的面数、距离场精度都比较敏感，一个没优化好的场景在Lumen下的表现可能还不如传统烘焙。

5.2 HDRP RTGI偏"准"，Lumen偏"快"

我把两个方案拉出来对比过：HDRP的RTGI在漫反射GI和镜面反射上的物理正确性，确实比Lumen更严格，毕竟它是实打实发射光线做追踪的；但Lumen在没有硬件光追的情况下跑出来的效果，远比RTGI在同等硬件上流畅得多。换句话说，RTGI适合追求真实感的短流程或者高配PC演示，Lumen适合想做全动态GI又不想被硬件绑死的项目。

这种取舍在实际项目里会变成很现实的问题：如果你的美术团队已经适应了HDRP的物理光照单位，并且项目预算允许你优化RTGI的采样和降噪，那么HDRP RTGI的光质会让你满意；如果你要做一个大地图的探索游戏，主要精力花在关卡设计上，根本没时间给几百个房间烘焙和摆探针，那UE5 Lumen的默认全动态方案就非常省心。

5.3 我们做项目时选哪条路

说点更实际的选型建议。纯移动端项目，URP烘焙是最稳的，不要试图碰实时GI；PC端单机线性流程，HDRP配烘焙+SSGI，局部加RTGI，画质和性能可以平衡得很好；开放世界、大型沙盘类项目，建议直接上UE5 Lumen，虽然引擎重心在UE5，但UE4项目将来迁移到UE5时，Lumen的选型会让你省不少事。

如果你的团队已经深扎UE4且有成熟的美术管线，强行切UE5其实有风险。Lumen和Lightmass在美术验收标准上差异很大，Lightmass下简单粗暴的Lightmap Resolution和反射捕获参数，在Lumen下全部变成距离场精度和表面缓存分辨率的问题，美术要重新学一套排查流程。这件事没有绝对的对错，只有成本预期是否匹配。

6. 实测踩坑与个人选型心得

6.1 换管线的GI"归零"：从URP到HDRP的第一课

我一个实际项目从URP迁到HDRP，第一版渲染出来，整个场景颜色寡淡、暗部阴森。排查下来发现是灯光的数值体系完全变了：URP里方向光Intensity=1就很亮，HDRP里方向光需要按真实世界的Lux给，比如晴天正午约50000~100000 lux，室内主光可能只有几百lux。你不在HDRP的物理光照单位下重新校准所有灯光，GI结果根本不可能对。

另一个坑是颜色空间。URP默认Gama空间下的烘焙结果，在HDRP的Linear空间里如果继续沿用旧的Lightmap，间接光强度和色彩平衡都会偏掉。所以迁移管线时，所有光照贴图和灯光的数值都必须归零重新调一遍，这不是简单的"配个色"或者"用LUT拉一下"就能解决的。

6.2 漏光、接缝和黑块的排查思路

遇到烘焙后的漏光问题，我还是偏向先怀疑UV。Lightmap UV的岛屿如果跨过了模型表面的硬边，烘焙出的光照就会在硬边两侧产生颜色渗透，看起来像漏光。解决办法是在模型的UV2生成设置里勾选Pack Margin和"保持岛屿在硬边切割"，同时给Padding留足够大的值。

黑色斑块的来源则通常是Lightmap分辨率不够或者场景里残留了密闭的面。UE4里如果发现某个墙面黑成一团，先检查它是不是双面都接收光照，或者模型里有没有隐藏的背面朝向。Unity里则要排查Mesh是不是开启了Receive GI，以及该物体是否被某种后处理特效遮挡。这套排查逻辑说白了就是：先看UV，再看分辨率，最后看标签和组件开关，不要一上来就怀疑引擎。

6.3 不同项目类型的最优选型

• 做休闲游戏、卡牌、2D半3D、微信小游戏：URP烘焙，性能稳定，管线简单。
• 做PC/主机3A的线性关卡：HDRP烘焙+SSGI，保留RTGI的口子给过场CG。
• 做开放世界、动作冒险、模拟经营：优先UE4 Lightmass烘焙过渡到UE5 Lumen，重点考虑的是团队规模化后的光照review流程。
• 做建筑可视化、产品渲染：HDRP的物理光照单位和离线Path Tracing几乎是最优选，UE4的Path Tracer虽然也好用，但HDRP在美术流程中操作手感更流畅。

6.4 最后一点个人体会

做图形相关工作这些年，我最大的感觉是全局光照没有标准答案，只有"适合项目"的答案。烘焙省性能但迭代慢，实时GI效果惊艳但吃设备，SSGI和体积雾是中间的折中。真正好用的团队，往往不是把某个GI方案用得多极致，而是能清晰地知道当前项目的硬件目标、美术风格和迭代节奏，然后在烘焙、屏幕空间、光追这三档能力之间恰当地组合。

如果你正在做一个Unity URP的项目，现在就想往HDRP靠，我建议你先做一个屋顶亮度和地表反射的样板场景，快速验证物理单位下的灯光校准值，同时让美术团队提前用HDRP的光照单位去调整材质和贴图风格。这能让你在项目中期才发现"光照全乱"之前，就把最大的风险消掉。