企业官网建设流程全解析

1. 这轮对比的背景：PBR之后，光照才是渲染的真战场

1.1 为什么Part2要单独写全局光照

Part1我们聊了Unity URP、HDRP和UE4在PBR材质模型、Shader着色、法线细节上的差异。评论区不少人问：材质表现都差不多了，为什么画面放在一起还是差一截？

答案几乎都出在光照上，尤其全局光照。

PBR解决的是"这个表面该长什么样"，但真正决定画面能不能"活"起来的，是光线在场景里多次反弹后的结果。漫反射地面反射到墙面、墙面反射到角色暗部的微弱补光、玻璃附近的地面反光——这些东西单靠直接光永远做不出来。没有合理的间接光，哪怕材质参数再准，画面也会显得"干净过头"，看着像产品展示而不是场景。

这篇Part2就是针对全局光照的专项对比。我会按Unity URP、Unity HDRP、UE4三条管线各自的GI方案展开，包括它们依赖哪些技术、开销在哪儿、适合什么项目，以及我在实际项目里踩过的坑。无论你是刚入行的Unity开发者，还是打算从Unity迁移到UE4，或者单纯想了解Unreal的Lumen到底强在哪，这篇都能给你一个相对完整的参照。

1.2 三条管线对全局光照的入口设计差异

先说一个容易混淆的点：其实"URP、HDRP、UE4对全局光照的支持"并不能简单按"有没有"来区分，而要看它们把GI放在哪个层级、由谁负责计算。

Unity URP定位轻量管线，默认以烘焙方案为核心，Lightmap、Light Probe、反射探针是老三样。引擎本身不强制要求高端显卡做实时GI，移动端和低端PC主要靠烘焙预计算。

Unity HDRP则做了一次取舍：它保留了烘焙GI的入口，但在较新的版本里把重心放到逐像素的实时GI迭代上，比如屏幕空间全局光照、反射、体积光这些效果。HDRP本质是给性能有富余的平台准备的，DX11、DX12、PS5、高端PC这类环境才会充分发挥。

UE4的跨度更大。老项目还在用Lightmass烘焙静态光照，但UE5时代Lumen成为默认方案，可以在没有硬件光追的情况下做全动态的无限反弹间接光。Lumen对动态场景的支撑能力，恰恰是Unity两条管线默认方案里最不擅长的一块。

这三套体系解决的是同一个问题，迭代路径却完全不同。接下来我们逐个拆。

2. Unity URP的全局光照：轻量管线如何做到"够用且可控"

2.1 Lightmap烘焙与实时光照探针的搭配

URP项目里最常见的GI组合，就是Lightmap加Light Probe。这套组合的核心思路是：把静态物体的间接光烘焙到贴图里，动态物体用探针做近似采样。

Lightmap烘焙的原理并不复杂。引擎在编辑器里通过渐进式GPU烘焙（Progressive GPU Lightmapper）模拟光子多次反弹，把最终的入射辐照度记录到每个静态物体的UV2通道上。运行时物体不需要计算反弹，直接采样Lightmap就能得到间接光。

这里有个容易忽略的细节：所有参与烘焙的静态物体必须展开UV2，也就是Lightmap UV。很多新手第一次烘焙发现物体发黑，打开UV预览一看，烘焙贴图挤在一小块区域或者完全重叠，就是因为Mesh没有正确的第二套UV。

• 静态物体勾选Contribute GI，并且Lightmap Static设为On
• 场景里给主要物体设置合理的Scale In Lightmap，一般默认1，大件遮挡物可以稍微调低来节省分辨率
• 在Lightmap Settings里根据场景大小调整Lightmap Resolution，建议从2到4开始调，单位是texels per unit
• 烘焙质量过高会导致时间指数级上升，先用低分辨率摸一遍布局，再开高精度出最终贴图

烘焙完成后，场景里的静态物体就有了相对准确的间接光，但这个方案的代价是动态物体没有场景间接光。为了让角色、载具这类会移动的物体获得大致匹配的间接光，就必须在场景里布置Light Probe Group。

Light Probe Group的布置经验是：不要均匀铺满，而是贴着地面、墙边和遮挡物边角加密节点，半空中可以稀疏一些。探针位置越接近实际的漫反射路径，动态物体上采样到的间接光颜色越自然。布置完在Scene视图里看Gizmo，能直观看到梯度和分布。

2.2 反射探针与Light Probe Group对动态物体的补充

只靠Diffuse GI还不够，PBR材质的金属和光滑表面还需要环境反射。URP里的反射信息来源主要是Reflection Probe。

反射探针本质是把探针位置周围的环境渲染成Cubemap，运行时按粗糙度对Cubemap做模糊和采样。URP默认用Local Reflection Probe，适合封闭室内和局部区域；远处的大环境可以用天空盒或者一个覆盖全场景的探针兜底。

探针的规格和质量很容易被忽视。常见问题有两个：

1. 探针更新时机没设置好。如果是静态场景，探针烘焙一次关掉Realtime即可；如果场景里有大量移动物体希望反射也跟着变化，可以打开实时更新，但会带来每帧额外渲染开销。
2. 探针分辨率不够导致金属表面糊成一片。特别是车漆、金属地板这类光滑表面，128的Cubemap远不够用，至少要256以上。

再补充一个Light Probe和Reflection Probe的配合逻辑。Light Probe解决动态物体的漫反射间接光，Reflection Probe解决动态物体的镜面反射，二者缺一不可。只放探针不布置Light Probe，角色身上暗部会显得非常"死"；只布置Light Probe不放反射探针，金属材质则完全看不出反光环境。

2.3 URP 14+的Adaptive Probe Volumes（APV）实测

如果你用的是Unity 2022.2以上，URP里还能接触到Adaptive Probe Volumes，也就是APV。这套方案本质上是用自适应放置的探针网格替换传统的Light Probe Group，烘焙时近距离更多探针、远距离更少探针，然后运行时对这些探针做自适应采样。

我实机测下来的感受是：APV对中型开放场景的间接光均匀度提升非常明显，比手摆Light Probe容易出效果，烘焙时间和后处理控制也更直观。但它不是没有坑。

APV最需要注意的：Memory Budget和Probe Spacing的平衡。探针太密会让内存和烘焙时间暴涨；太疏又会出现光照斑块。我习惯先用3m的Spacing做全场景粗烘焙确认大关系，再用1m间距对重点区域做局部细分。烘焙时如果出现明显的漏光或暗斑，优先检查场景物体的Bounds是否覆盖了烘焙范围，以及探针体积是不是被SDF裁剪误伤了。

另外，APV对静态物体和动态物体的统一性处理得比老方案好，角色在不同区域间移动时间接光过渡更自然，不会出现Light Probe插值产生的"忽明忽暗"问题。光这一点就值得从旧方案迁移过来。

不过APV目前仍然基于烘焙，也就是说它解决的是动态物体对静态GI的采样问题，并没有改变静态GI本身的预计算本质。如果你项目里大量场景元素是动态的，比如可破坏的墙壁、移动的载具、随机生成的建筑，URP这套方案就会捉襟见肘。

3. HDRP的全局光照：强制迭代+混合路径的取舍

3.1 HDRP禁用了什么，又自己加了什么

HDRP在GI策略上和URP有个明显区别：它默认关掉了不少内置的简单GI手段，转而提供一套更依赖实时迭代的解决方案。

比如Light Probe Group虽然在HDRP里有对应入口，但官方推荐用APV替代；Reflection Probe继续保留，不过HDRP的探针支持实时和烘焙混合；Lightmap也仍然可以用，但走了另一套烘焙管线，和URP的烘焙参数不通用。

HDRP真正拿得出手的是几项实时GI技术：

• SSGI（Screen Space Global Illumination）：在屏幕空间内计算间接光反弹，对视觉提升极其明显
• SSR（Screen Space Reflection）：基于深度和法线做逐像素反射，替代低精度探针反射
• Contact Shadows：在物体接触处补足近距离阴影细节
• Volumetric Fog和Volumetric Lighting：让光照透过体积雾时产生体积散射效果

这套组合拳打出来的画面，会让PBR材质在复杂光照下呈现更立体、更符合物理直觉的表现。我经常用HDRP做建筑可视化Demo，单开SSGI之后，室内白色墙壁往天花板和地面补的颜色会让场景立刻"活了"。

3.2 屏幕空间全局光照（SSGI）与反射

SSGI的核心思路是：利用当前帧的深度缓冲、颜色缓冲和法线缓冲，在屏幕空间里"向后投射"光的反弹。它不需要预计算Lightmap，也不需要额外放置探针，只要屏幕里能看到的东西，都能参与间接光计算。

这套方案的好处是动态场景支持极好，物体移动、光源变化都能实时响应。但代价也非常具体：

• 屏幕外的东西不会参与GI，所以摄像机转一下，间接光可能突然跳变
• 低分辨率或极小尺寸物体容易出现光斑、漏光
• 性能开销在移动端几乎不可用，主要面向PC和主机

我的经验是，SSGI和探针方案之间不是替代关系，而是互补关系。静态场景的远距离间接光交给Lightmap或APV，近距离的动态间接光由SSGI补充，反射交给SSR和Reflection Probe做二级混合。HDRP把所有这些选项都暴露在Volume Override里，你可以按项目需求自由开关。

HDRP里的Reflection System我也多说一句。它用的是Hierarchical Cubemap和Screen Space Reflection混合的方式。你可以在Lighting面板里设置反射探针的全局质量等级，HDRP会按距离和优先级把探针结果与SSR插值。相比URP里探针"要么看要么不看"的割裂感，HDRP的反射连续性确实好一截。

3.3 探针与Lighting层级系统

HDRP从2022版本开始强化了Lighting层级（Lighting Layers）和多套探针系统的配合。所谓Lighting Layers，本质上可以理解为给光源和探针打标签，让不同层级的物体只接收指定标签的光照。

这个特性在实际项目里非常有用。比如角色身上想让主光和补光生效但不要被环境探针影响过多，就可以单独分出角色光照层；地面和建筑又用另一套探针层。调试光照时不用再"一刀切"地禁掉某个光源，而是按层独立调节。

但要注意，Lighting Layers是在Shader Pass级别做mask的，使用不当会导致某些物体直接变成黑色或漏光。排查这类问题时，第一步就是先确认物体和光源是否在同一层，而不是急着去调Lighting面板。

3.4 体积光、体积雾和GI的联动

HDRP和另外两条管线画风差异最大的地方，就是它对体积效果的整合。Directional Light体积光、Volumetric Fog和GI之间是有联动关系的：光通过雾介质时发生散射，散射结果又会被反射探针和SSGI采到，形成更统一的亮暗关系。

实操里我建议把体积雾当成一个"光场容器"来调，而不是开个开关了事。默认的Volumetric Fog密度设置为0.01时几乎没什么视觉效果，但如果你把Anisotropy调高，会看到光晕沿着散射方向拉长，配合GI会让室内光感非常绵润。

性能方面，体积雾的分辨率默认128x128x64，俗称"雾格子"。场景范围很大时可以降低这个分辨率换取性能，保证边缘不穿帮就够用。Debug窗口里直接看Froxel Grid，能非常直观地看到雾格子在场景里的分布密度。

4. UE4的全局光照：从烘焙Lightmap到Lumen的跨度

4.1 Lightmass烘焙与Lightmap UV

UE4老版本项目里最常见的GI方案是Lightmass烘焙。它的定位和Unity的Lightmap非常像，但流程上有一些不同点。

Lightmass有独立的烘焙设置，在Build菜单里运行。烘焙时引擎会先为静态网格体生成Lightmap UV，如果模型本身没有第二套UV，会自动展开。不过自动展开的质量一般都不如美术手工拆分的好，尤其是大面积曲面或密集小物件，容易出现拉伸和重叠。

常见的Lightmass参数里，Static Lighting Level Scale控制光照贴图整体分辨率，Num Indirect Lighting Bounces控制间接光反弹次数。反弹次数默认3，但很多场景到5左右会有更柔和的暗部过渡，代价是烘焙时间的指数增加。

Lightmass烘焙出的结果质量其实很高，尤其是大面积环境光遮蔽的柔和感，早期很多游戏就是靠它做出照片级静态画面的。但它和URP的问题是同一个：不支持动态场景。运行时任何物体移动、光源关闭，预计算的间接光并不会跟着变化。

4.2 Lumen实时全局光照的落地表现

UE5里Lumen直接把全局光照拉到了另一个维度。Lumen有两种模式：Software Lumen和Hardware Ray Tracing Lumen。前者靠软件追踪在低端设备上也能跑出声场，后者走DXR硬件光追，效果更准但要求显卡更硬。

Lumen的工作方式可以简单理解成：对每个需要接收GI的表面点，从它出发向周围发射一组短距离光线，在场景的SDF（有向距离场）和网格体上探测遮挡和反弹。因为SDF对场景做了预计算抽象，所以动态物体也能被追踪到，这就解决了传统Lightmap遇到动态场景就失效的痛点。

实际项目里Lumen和普通Lightmap放在一起对比，最直观的差异是间接光的渐变连续性和动态变化响应。太阳角度变了，室内墙壁的反光颜色和形状都会跟着实时调整，这种"光自己在适应场景"的感觉，用烘焙方案很难做出来。

但Lumen不是没有代价。软件追踪模式在复杂场景里会产生Noise和漏光，尤其是细长物体和薄片结构，因为SDF对薄物体的表达本身就容易出问题。如果项目里大量出现铁丝网、栏杆、树叶这种结构，Lumen的光斑可能会让你调试到自闭。

解决思路一般是：把细节几何从SDF追踪中排除，或者用距离场分辨率提高加精修；实在不行对这些细节物体关闭GI接收，靠探针和平面反射补救。Lumen性能分析里我也建议直接从Screen Probe Gather Settings入手，调整每像素的追踪强度和屏幕空间占比，往往比盲目降低全局质量更有效。

4.3 反射捕获、DDGI与SSGI的互补

提到UE4就绕不开它的反射体系。UE4里最传统的反射方案是Reflection Capture，本质和Unity的Reflection Probe差不多，烘焙Cubemap然后按粗糙度采样。但它的定位有点尴尬：Lumen开启时，Lumen自带反射通道；关闭Lumen时，Reflection Capture的固定画面又容易穿帮。

我自己的项目里，如果关掉Lumen，会保留Reflection Capture作为大环境兜底，然后叠加SSR处理近距离反射。SSR在屏幕空间内追踪反射光线，动态物体、动态光源都能响应，也不会像探针那样因为覆盖范围不足产生明显跳变。缺点是屏幕外和遮挡后的反射信息都是残缺的，所以需要探针来补远场。

DDGI（Dynamic Diffuse Global Illumination）是另一条路线。它用一组实时更新的Irradiance Probe Volume替代静态Lightmap，探针位置上的光照信息每秒更新几次，从而让动态物体获得动态间接光。UE4社区里很多研究性项目用DDGI实现类似Lumen的效果，但需要自己维护Volume放置和更新逻辑，工程量和Lumen相比不是一个量级。

我的结论是：Lumen已经让UE4的实时GI形成了"全动态"的默认心智，Reflection Capture和SSR不再是核心竞争力，只是辅助配件。如果你用UE4还想着传统烘焙贴图，那等于主动放弃了引擎最强的动态光照优势。

5. 三条管线全局光照的对照表与选型建议

5.1 核心参数对比表

为了让大家快速对照，我把三套管线在全局光照上的关键差异整理成表。

5.2 不同项目类型该怎么选

给项目选GI方案，我一般先分清四个场景。

第一类是移动端休闲或中轻度游戏，目标机型是中低端安卓机。这个场景下URP+Lightmap+Light Probe是最稳的，HDRP基本不用考虑。移动端如果非要用APV，建议控制探针总量，Shader复杂度也要压低，不要开SSGI或者体积雾。

第二类是PC/主机上的偏向写实画面或单机项目。HDRP会是收益最明显的选择，室内场景用SSGI+APV能兼顾性能和动态感；室外大世界可以把SSGI关掉或降级，靠烘焙+探针扛大尺度间接光。

第三类是使用UE5做次世代游戏或数字孪生演示的项目。直接开Lumen，软件追踪起步，硬件追踪根据显卡配置升级。烘焙Lightmap只作为Lumen不支持的极端情况兜底。

第四类是建筑可视化、影视预演这类对画面质感敏感但对帧率宽容度更高的场景。HDRP和UE5 Lumen都能用，关键看团队对Unity还是UE4熟悉。这类项目里间接光连续性和反射质量远比运行帧率重要。

5.3 帧率开销与Shader复杂度的一些实测数据

这里提供我自己的性能测试参考，不是官方标准，仅仅作为选型时的量级参考。

同样的纯室内场景，几何面数约200万，在RTX 3060、1080p下：

• URP关闭SSGI、使用Lightmap+APV时，GI相关Pass约占0.3ms到0.8ms，Shader整体较轻
• HDRP开启SSGI和SSR时，GI相关Pass约2ms到3ms，再加上体积雾约1ms，整帧压力明显增大
• UE4开Lumen软件追踪时，GI相关开销约3ms到5ms，与场景复杂度强相关。如果开硬件追踪，显卡负载会进一步上升，但在新一代GPU上光斑更少

移动端如果硬开HDRP的SSGI，几乎是一场灾难。我见过有同行在高端手机上强顶SSGI，帧数直接从60掉到30上下，发热也压不住。URP的烘焙方案在移动端稳定得多，这也是为什么移动端项目默认就走在烘焙路线上。

从Shader复杂度角度说，URP的间接光采样用的是引擎内置标准Lit Shader，逻辑简单，合批率高。HDRP的Lit Shader多了SSGI和屏幕空间反射分支，指令数明显增加。UE4的默认Lit Shader在Lumen激活后也会插入额外的追踪代码，材质变多时编译时间会让你怀疑人生。

6. 踩坑记录：实战中容易忽略的GI细节

6.1 阴影与GI的联动问题（混合光照模式）

这是Unity开发里非常经典的一个坑：光照模式选错，烘焙出来的GI会和实时阴影对不上。

URP里Mixed Lighting分Subtractive、Shadowmask、Baked Indirect等模式。很多新手只看到"混合"两个字，就无脑选Subtractive，结果烘焙后所有静态物体接收不到实时阴影，画面整体发飘。

我的建议是：需要保证主方向光实时投影时，优先用Shadowmask模式。它允许烘焙间接光的同时保留实时阴影Mask，动态物体和静态物体都能正常投影。Baked Indirect适合光源基本不动的场景，但要注意方向光的阴影设置，否则实时阴影会导致整个场景暗部和GI脱节。

UE4里也有类似的坑，Lightmass烘焙后如果Directional Light的Cast Dynamic Shadow设置和Lightmap不协调，会出现物体脚下阴影和墙面间接光"两层皮"的视觉分裂。排查这类问题时要开Lighting不再依赖猜，直接用引擎的Lighting Debug视图看各个光照通道的贡献值。

6.2 法线细节对GI的影响（法线贴图后的间接光丢失）

PBR场景里加了Normal Map之后，表面看起来细节很丰富，但很多间接光方案对法线细节的响应并不好。

URP的Lightmap和Light Probe一般只按原始顶点法线计算间接光，Normal Map的细节只会影响直接光着色。这会导致一个现象：物体直接光下细节很锐利，但暗部过渡非常"平"，缺乏微小的环境遮蔽感。

HDRP的SSGI对屏幕法线敏感度更高，所以配合Normal Map时暗部细节好很多。这也是HDRP画面更"贵"的原因之一。UE4 Lumen也类似，它会用当前像素的法线做追踪，Normal Map造成的表面朝向变化会真正影响间接光分布。

实操上，想让Lightmap烘焙的正确还原法线细节，可以适当提高烘焙分辨率。但高分辨率烘焙不一定解决所有问题，因为Lightmap本身记录的是低频光照信息。真正的解法是在材质层叠加AO贴图，或者用HDRP/UE4的实时GI方案从硬件上解决。

6.3 后期调试与性能分析的几个工具

排查全局光照问题，有几个工具我几乎天天用。

Unity侧首选Frame Debugger。它能把渲染过程拆成一帧一帧的Draw Call，你可以直接看到哪个Pass用了Lightmap、哪个Pass在做SSGI。配合RenderDoc做GPU捕获，能检查每个GBuffer通道里存的值，确认间接光数据有没有正确写入。

HDRP的Debug Mode更完备：左下角的Display Stats可以显示当前GI和反射的耗时分布；Lighting模块里还有专门的GI Debug画面，可以分别显示APV探针分布、SSGI贡献、SSR遮罩。遇到光斑或漏光，按显示的图层逐个排除最快。

UE4里开Lumen场景调优，强烈建议在Project Settings里把Lumen的可视化模式打开，可以看SDF距离场、追踪光线长度、探针分布等。配合Stat GPU看实时开销，再对照GPU Visualizer里的Lumen相关Pass，基本能定位瓶颈是追踪分辨率不足还是样本数太多。

别小看这些调试流程。全局光照的问题往往不是单一参数引起的，而是多个系统叠加出来的。没有可视化工具辅助，你只能靠肉眼猜，效率极低。

我自己处理这类渲染问题还有个习惯：先把所有实时GI开关全部关掉，从纯烘焙或纯直接光开始，确认每个图层单独的效果是否正常，再逐渐打开SSGI、SSR、Lumen等选项。每开一层就验证一次画面变化，哪个选项产生的故障就立刻定位。踩坑多了之后你会发现，大部分GI异常都不是"某个功能坏了"，而是功能之间的相互干扰没有理顺。

回到篇首的问题：为什么材质差不多，画面观感还是差一大截？答案现在应该更清晰了——全局光照才是决定画面层次感和真实感的分水岭。URP给的是最稳妥的性价比答案，HDRP给的是性能换取质感的答案，UE4的Lumen则代表全动态GI的另一条路线。选哪套方案，取决于你的平台、美术方向和性能预算，而不是谁的招牌更响。希望这篇对比能帮你少踩几个我踩过的坑。