企业官网建设流程全解析

作为一个在Unity和UE4之间反复横跳多年的图形程序，我一直觉得渲染管线的对比是个特别值得聊的话题。上一篇文章整理了三套管线在PBR基础光照模型上的差异，这次专门聊全局光照，也就是大家常说的GI。这个领域的水最深，URP、HDRP和UE4看似都在做间接光照，但实现路径和最终效果差距很大，有些坑只有实际项目里踩过才明白。这篇文章我尽量把三套方案的核心逻辑讲清楚，再结合自己实际项目里的调参经验，给一些可以直接参照的选型建议。

1. 三套渲染管线的定位差异，决定了GI方案的根本走向

1.1 从烘焙架构看三套方案的本质区别

很多刚接触这三套引擎的同学会把URP、HDRP和UE4的全局光照放在一起比较，但实际上它们解决的问题不太一样。URP的前身是LWRP，设计目标是移动端和低端设备，所以它的GI方案首先要考虑的是“能跑”和“跑得动”。HDRP的目标平台是PC和主机的高端画质，所以它的GI方案有更多实时的成分，也要配合更复杂的体积光照系统。UE4则是一个封闭但高度整合的商用引擎，它的GI体系以烘焙和实时探针为主，同时提供了从LPV到Screen Space GI再到Lumen这样一条清晰的技术演进路线。

从底层看，URP本质上是精简版的渲染管线，它在渲染路径上砍掉了许多材质模型和光照特性，换来的是跨平台的高兼容性。这就导致URP在全局光照上不可能走HDRP那样复杂的实时GI路线，它的烘焙光照贴图和Light Probe是主力方案。HDRP则是为延迟渲染和高端特性设计的，它虽然也支持烘焙，但光照贴图的质量和编码方式比URP更精细，同时支持更多的探针类型和实时反射。UE4这边更像是“全家桶”，烘焙+实时混合的做法非常成熟，从静态光照到动态角色的间接光照都有对应的解决方案。

这种定位差异直接决定了开发者的使用预期：如果你的项目要同时跑在手机和PC上，URP的GI够用；如果追求主机级别的画面质感，HDRP的GI才有发挥空间；而UE4的GI体系则强在“一套方案应付大多数场景”，从建筑可视化到开放世界都能找到合适的档位。

1.2 名词扫盲：直接光、间接光、反弹与光照贴图

在深入对比之前，有必要把几个基础概念捋清楚，否则后面看参数容易绕晕。直接光照指的是光源直接照射到表面的光，这个在PBR里由光源的强度、颜色、角度和表面的法线分布共同决定。间接光照指的是光打在物体A上之后反弹到物体B上的那部分能量，PBR渲染里如果没有间接光，所有暗部就会死黑一片，缺乏真实感。全局光照就是把直接光和间接光都算进去的完整光照系统。

光照贴图是烘焙GI最经典的载体。它的原理是预先计算静态物体表面的间接光照结果，以贴图的方式存储在模型的UV上，运行时直接采样。Light Probe则是为动态物体准备的间接光照采样点，引擎在烘焙时生成一片三维空间中的探针，动态角色经过时从周围探针插值取色。Reflection Probe负责记录环境反射信息，用于表面高光和镜面反射的补充。这三样东西，在Unity里叫Lightmap、Light Probe Group和Reflection Probe，在UE4里叫Lightmap、Light Volume和Reflection Capture，名字不同，思路一致。

搞明白这些基础名词之后，再看三套引擎的GI实现就觉得不那么抽象了。URP的全局光照本质上是“烘焙为主，探针辅助”，HDRP在这个基础上增加了更多实时和体积化的手段，UE4则把光烘焙、探针和实时光追组合成了一套完整的解决方案。

2. 拆解URP的全局光照：轻量但够用，关键在参数调优

2.1 URP的烘焙光照体系与LPPV的坑

URP的实时渲染路径是单Pass的前向渲染，光照贴图采样和Light Probe插值都是走内置的Shader宏实现的。从使用习惯上看，URP的全局光照操作是“照明窗口里勾选Baked GI，然后把静态物体标记为Static，生成光照贴图”。这一步和内置渲染管线的逻辑差不多，但URP在背后处理光照贴图的采样和编码时有自己的优化逻辑。

用URP做GI有一个很容易被忽略的点：Light Probe Proxy Volume，也就是LPPV。这个组件在内置渲染管线里用得不多，但在URP里做移动端动态物体GI时，很多人会遇到动态物体间接光颜色“飘”的问题。原因在于Light Probe在场景中稀疏分布时，插值结果会穿过墙体或遮挡物，导致角色站在室内却采到室外的探针颜色。LPPV的作用是在指定体积内生成加密的虚拟探针，改善插值质量，但URP对LPPV的支持有一些历史遗留问题，部分版本在Tile渲染下表现不稳定。

我自己在URP项目里处理这种问题时会做两层保险：第一，Light Probe Group的探针布置尽量人工介入，别全自动生成，特别要在大厅、走廊、门口这些过渡区域手动加密；第二，开启LPPV后，把虚拟探针的Resolution控制在一个合理的档位，不是越高越好，因为虚拟探针的数量直接吃内存和绘制调用。LPPV的虚拟探针其实是在运行时被引擎当作一个Mesh来渲染的，探针太多会直接拉高顶点数。

2.2 URP烘焙参数里的“三件套”与实用调节经验

URP烘焙GI的核心参数其实就三块：Lightmapper的设置、Lightmap Resolution和Compression。先看Lightmapper，URP的默认选项是Progressive GPU，这个模式的好处是烘焙速度快，迭代反馈及时，而且支持光反弹次数的实时预览。如果你在烘焙时发现画面偏噪点或暗部发黑，先别急着怀疑贴图压缩，看看Bounces值是不是设得太低。默认值通常是2，做室内场景建议调到3或4，代价是烘焙时间翻倍，但暗部会干净很多。

Lightmap Resolution这个参数，不同类型项目差异很大。移动端小场景用每单位40到50个Texel，表现力基本能压出来；PC项目60到80是常见区间；我见过一些建筑可视化项目直接拉到120，那样墙面细节会很锐，但Build体积也会飙升。这里有一个容易被忽略的技巧：调节Resolution之后，要留意一下烘焙贴图在磁盘上的实际大小，因为Unity会把光照贴图打包进AssetBundle，Resolution提高1倍，贴图体积提升4倍，掉的是包体和内存。合理的做法是先低精度跑一版看光照分布，满意后再提高精度出最终版。

Compression这一项，默认是开启的。开启后光照贴图会变成DXT或ASTC格式，内存占用相对友好，代价是边缘可能出现轻微的颜色溢出和渗色。如果项目里主场景是大面积浅色墙面和精细物件，建议把Compression关掉，用RGBA Half格式，接缝和质量都会改善，代价是内存和包体直线上升，这个取舍要由项目的硬指标决定。URP里还有一个容易误启的选项：Use Direct Lightmap。这个选项控制的是光照贴图中是否分离直接光和间接光。开起来后，实时方向光和烘焙贴图的直接光部分可以做混合，理论上能得到更灵活的动态光照切换，但URP在部分移动端GPU上对这个混合支持不佳，会出现光照贴图区域随着方向光变化而不自然的情况，所以我一般只在纯PC项目里启用。

2.3 实时GI的缺失：URP的软肋与变通玩法

URP本身没有实时的间接光反弹方案。这意味着你在URP里放一个动态的点光源，它能照亮物体表面形成直接光，但无法让这个光在场景中产生一次间接反弹，也没有任何实时的颜色溢出效果。这是Panel类渲染管线的共性，不是URP独有的缺陷，但是对比起HDRP和UE4，URP在动态GI这块确实显得“简陋”。

不过URP可以通过变通方式来弥补这个软肋，最常见的是Light Probe + Realtime Reflection Probe的组合。把场景里的反射探针设置为Realtime模式并开启Refresh Mode的Via Scripting，可以用脚本在角色移动或灯光变化时刷新探针，这样动态物体身上能够带上一部分环境色的间接感。实测下来，这个方法在小空间内效果相当不错，比如一个卧室、一个商店或是角色靠近墙壁的区域。但到了开阔场景，反射探针覆盖范围有限，问题又会显现出来，动态物体走进不同区域时，颜色过渡依然依赖Light Probe插值。

还有一条路子是走360度全景捕抓的动态环境光。做法是在角色头顶挂一个Camera，用RenderTexture实时输出环境信息，经过降噪处理后采样为漫反射环境色。这个方案在室内场景的视觉提升非常明显，因为室内本身就是低照度高反射密度的环境，全景捕抓能拿到准确的局部环境色。缺点是每帧多一次额外渲染，移动端需要考虑性能预算。总的来说，URP项目里想实现接近实时GI的效果，本质上是用“高密度探针采样+实时反射捕抓+一点后处理色调映射”来模拟，而不是指望引擎原生支持实时反弹。

3. HDRP的全局光照：算力换质感的路线

3.1 静态光照的完整升级：从光照贴图到体积化间接光

HDRP对待静态全局光照的方式和URP完全是两个思路。URP主要依赖2D光照贴图，HDRP除了更高质量的光照贴图之外，还有一套动态烘焙版本转换系统，支持在编辑器里动态调整光源属性后实时看到烘焙结果的近似效果，直到最终烘焙时才固化。这个对美术调参来说非常友好，不用每次都等完整烘焙结果，在亿级别场景里能省很多迭代时间。

HDRP的光照贴图编码方式也比URP复杂，默认是方向性光照贴图（Directional Lightmap）+ 球谐编码（SH）的组合。方向性光照贴图允许表面在采样间接光时带上光照方向信息，这对法线贴图细节的表现特别重要。普通光照贴图只存颜色信息，所以法线细节是平的；方向性光照贴图存储了每个点的主光方向，法线贴图的凹凸感能通过间接光表现出来。UE4也用了类似方案，但HDRP的SH系数用得更细致，每个贴图里除了方向还有多个球谐频段。

除了光照贴图，HDRP还引入了Probe Volume（探针体积）。它和URP的LPPV类似，但功能上要强得多——HDRP的探针体积可以管理多级细节层级，大规模场景下远处用稀疏探针，近处用密集探针，烘焙时自动生成自适应密度，不需要手动去布点。这个特性在URP里是没有的，我也不止一次看到Unity中国社区里有人在问“HDRP的Light Probe为什么不会穿透墙体”，其实就是Probe Volume的插值策略和内置管线的Light Probe不太一样。

3.2 实时反射与SSGI：HDRP的“伪实时GI”组合拳

HDRP的实时反射系统比URP强在支持多反射探针混合和实时Planar Reflection（平面反射）。反射探针可以设置不同的权重和影响范围，墙面、地板、金属物件的反射可以单独控制，配合HDRP的Surface Options里的Smoothness细节，能营造出很强的视觉质感。平面反射是做地面倒影的神器，比如一个大理石地板在HDRP里开启Planar Reflection后，整个空间的真实度能提升一个档次。不过反射对象要小心筛选，平面反射的渲染成本是“整个场景再画一遍”，我们要在反射委托函数里剔除掉不必要的物体，否则中等规模场景的帧耗时能翻倍。

SSGI（屏幕空间全局光照）也是HDRP比较有代表性的特性。它通过分析当前帧的深度和颜色信息，在屏幕空间内模拟光线的反弹效果，让靠近墙面的地方出现颜色溢出，暗部角落有微弱的二次光照。这个效果在视觉上非常接近实时GI的观感，但本质上是“拿上屏画面做文章”，所以它有两个天然限制：超出屏幕外的情况采不到，被遮挡的高频细节容易闪烁。HDRP的SSGI多用于近距离和高视线焦点区域，大面积远景配合烘焙和探针反而更稳妥。

提到HDRP的GI，就不能不提Path Tracing渲染器。这不是为实时渲染服务的，而是在HDRP的Frame Settings里开启给离线烘焙和预渲染输出用的。它支持最高质量的光线追踪，包括多次反弹的间接光、焦散、体积光等。很多电影级画质的HDRP演示画面其实是用Path Tracing离线渲染出来的，不是实时的表现。这个差距要在项目里心里有数，否则容易把目标定得过高。

3.3 HDRP GI的性能预算分析与调优细节

HDRP的GI方案每一样都吃性能，不是开箱即用的。光照贴图本身的采样开销比URP更高，因为多了方向性数据，移动端的带宽压力会相对明显。探针体积的密度越高，运行时插值计算越重，内存占用也越大。实时反射和SSGI是逐帧开销，所以要严控在画面里大面积区域同时启用的行为。

实际项目里，HDRP场景的GI调优通常分三阶段走：第一，把静态场景的烘焙做到了“能看”的程度，保证大面积间接光正确；第二，在角色周围或摄像机焦点区域开启SSGI和实时反射，用局部高精度掩盖全场景的精度不足；第三，用Light Probe和Probe Volume补齐动态物体的间接光，同时监控内存和帧耗时。这个顺序我在多个项目里验证过，比一开始就全面开启HDRP的实时GI功能要稳定得多。

这里有一个容易踩的坑：HDRP的GI相关的Pass和URP不同，它默认是Lighting Pass整合在Forward或Deferred渲染路径里，一旦在Shader里自定义了光照，就必须匹配HDRP的Lighting API，不然GI参数根本传不进来。很多开发者从URP迁移Shader到HDRP时，发现场景中物体有光照但间接光是黑的，十有八九就是自定义Shader没有接HDRP的光照结构。把思路理清楚之后，HDRP的GI升级路径确实值得投入，尤其当项目以PC和主机为发布平台时，画质的收益非常直观。

4. UE4的全局光照：从烘焙体系到Lumen的转变

4.1 烘焙Lightmap的技术细节与Volumetric Lightmap

UE4的烘焙光照体系经历了多个版本的迭代，但核心套路这些年变化不大。静态物体的间接光存储在Lightmap里，Static Lighting Scenario可以支持同场景多套光照贴图之间的切换，做昼夜循环非常方便。UE4的Lightmap UV通常由引擎自动生成，也可以在静态网格体的Build Settings里手动调，它的密度控制比较直观，通过Lightmap Resolution来控制。大面积Mesh的Lightmap Resolution如果设置得太低，墙面会出现明显的明暗色块，这个现象叫Lightmap Seaming，调高Resolution自然消失。

UE4的Volumetric Lightmap（体积光照贴图），可以理解为三维版本的Light Probe。它把一个空间划分成正交的体素格子，在格子里存储间接光信息，动态物体在这套格子里插值采样。和Unity的Light Probe相比，Volumetric Lightmap的优点是密度和分布可以由场景形状自适应，封闭空间内部和洞口附近的采样质量明显更高。在Lumen出现之前，UE4处理动态角色进入室内场景时，用的就是这套机制。

4.2 实时GI的演进：从SVOGI到屏幕空间的尝试，再到Lumen的落地

UE4的实时GI路线比Unity更早也更激进。早期的SVOGI（稀疏体素八叉树全局光照）尝试把场景体素化后在体素空间内传播光照，但受限于内存和动态场景的支持度，在正式项目里用得很少。后来的Screen Space Global Illumination（SSGI）在效果上接近HDRP的SSGI，也是屏幕空间内的间接光模拟，但同样受限于屏幕空间的信息瓶颈。再到后来实现真正的Lumen，UE5把它作为默认GI方案，UE4.26之后也支持通过插件开启Lumen，虽然功能和性能不如UE5那么完整，但在UE4项目里已经能做实时GI了。

Lumen在内部是一套混合型的GI系统。对于远距离和大场景，它使用**Mesh Distance Field（网格距离场）**作为场景简化后的表面表示，光照在距离场里进行追踪和反弹，所以能看到阳光照进走廊后在墙面上形成大范围暖色调的溢出。对于近距离和细节区域，Lumen切换到屏幕空间追踪，从深度缓冲和法线缓冲里采样更高频的间接光信息。这两种模式的切换是自动的，开发者一般不需要干预，但对性能的影响差别明显——距离场追踪跟场景复杂度相关，屏幕空间追踪跟屏幕分辨率和材质复杂度相关。

Lumen在UE4里最惊艳的地方是动态光源也能产生全局光照。一盏手电筒在走廊里晃动时，墙面上的间接光颜色和衰减是实时的，这在URP和HDRP里几乎没法直接做到。对以“开放世界”“昼夜循环”“动态光照叙事”为目标的项目来说，Lumen带来了设计上的自由度。

4.3 光追GI：硬件级渲染的UE4实现与视觉提升

UE4的光追GI走的是硬件光线追踪路线，基于DXR（DirectX Raytracing）。它把真正的光反弹路径计算出来，效果最为物理准确，包括Caustics效果和正确的多次反射。启用光追GI后，场景中的间接光不需要烘焙，动态物体和光源的位置随意变化，渲染结果都是统一的，这在建筑可视化和影视预览领域特别实用。

光追GI的性能开销非常大，中高端显卡也只能在1080P下维持中低帧率，对项目和硬件都有门槛。我见过有的团队把光追GI只在“定镜头的过场动画”里使用，实时玩法场景用Lumen或烘焙，这样既保留了质量，又控制了运行时性能。在UE4里调试光追GI时，有个参数经常被忽视：Final Gather Quality。这个值控制最终光照采样中每个像素执行的额外光线数量，它从性能角度讲是最敏感的一个参数。实际调参时可以先把这个值降低到0.5左右跑预览，确认光影分布后再拉高到1或2出最终效果。

4.4 一个容易被忽略的UE4 GI角色：Distance Field Ambient Occlusion

聊UE4的GI，不能只谈间接光，还要提它的距离场环境光遮蔽（Distance Field Ambient Occlusion）。这个功能利用网格距离场在屏幕空间内计算环境光遮蔽效果，没有屏幕空间的代价，对低模、远景和植被效果非常出色。在Lumen项目里，DFAO能补充近距离接触阴影的表达，让物体与地面、墙面之间的过渡更扎实。如果项目用的是烘焙光照，DFAO也能作为动态物体接触阴影的补充，避免角色在半空或靠近墙壁时缺乏深度感。

DFAO的实际调参有两个地方容易出问题：Distance Field Scale控制距离场的精度，调太大会让表面出现锯齿状假阴影，调太小的细节丰富但内存上涨；Occlusion Exponent控制阴影的柔和度和强度，默认值在2.0左右。做开放世界草坪场景时，DFAO配合Lumen的短距离追踪，能让每根草在地面投下柔和的遮蔽阴影，这是纯光照贴图达不到的层次感。

5. 横向对比：URP、HDRP、UE4的GI核心参数与适用场景

5.1 一张表看懂三套引擎GI的优缺点

表格列出来之后一目了然，URP适合移动端和轻量项目，HDRP适合PC和主机上追求画质的项目，UE4在开放世界和电影级画面方面有天然优势。这不是“谁强谁弱”的问题，而是“谁更适合当前项目形态”的问题。

5.2 三套引擎在“暗部细节”和“颜色溢出”上的实质差距

全局光照最终呈现出的观感，最直观的差异集中在两个地方：暗部细节和颜色溢出。暗部细节指的是阴影区域里能不能看清物体的轮廓和纹理，颜色溢出指的是红色墙面会不会把红光映到旁边的白色物体上。URP的烘焙GI在暗部细节上表现尚可，因为它可以调节Bounces保证暗部有微弱的间接光，但颜色溢出的精度一般，烘焙参数不当会出现大面积的色彩渗漏。HDRP的烘焙在暗部细节上更干净，因为方向性Lightmap让法线细节的间接光表现更好，SSGI还能补充一部分屏幕空间内的颜色溢出。UE4的Lumen在暗部细节和颜色溢出上表现最好，因为它有真实的光反弹计算，特别是颜色溢出在动态光源和动态物体之间也能保持一致性，这是烘焙方案做不到的。

我自己做过一个对比小实验：一个白色房间里放一盏暖色台灯，墙角放一个蓝色椅子，分别用URP烘焙、HDRP烘焙+SSGI、UE4 Lumen渲染。结果是URP的画面里墙角的蓝色溢出几乎是零，HDRP有一些淡淡的蓝晕，UE4 Lumen能看到明显的蓝色氛围光。这就是“物理准确”和“物理近似”的差距。如果项目在美术层面更依赖氛围感和色彩叙事，这个差距会直接影响最终表现。

5.3 三套引擎在移动端和PC端的实际表现差异

移动端是URP的主场。URP的GI开销被控制得很低，光照贴图以简单的编码方式和低精度纹理存储，中低端手机也能流畅运行。但HDRP和UE4的Lumen/光追GI完全不适合移动端，它们的计算量和内存占用不是移动GPU能承受的。如果非要在移动端用UE4，通常只能退回烘焙光照加Light Volume的方案，本质上和URP的做法差别不大，但UE4在移动端兼容性上相对更繁琐，需要在项目设置里做很多手动配置。

PC端的表现在最大画质档位上，UE4的Lumen和光追有明显优势。HDRP在PC端的表现同样不俗，特别是配合高分辨率光照贴图和SSGI，能接近Lumen的观感，但在动态场景和光源变化频繁的情况下，HDRP的烘焙限制会暴露出来，而Lumen完全没有这个问题。简而言之，如果项目的核心亮点是动态昼夜循环和自由探索，UE4的Lumen会省很多心；如果是大量静态场景配合固定视角，HDRP和URP的烘焙方案也完全够用。

6. 实操选型建议与踩坑记录：怎么选最稳，什么问题最常见

6.1 根据项目类型快速圈定GI方案的决策清单

做技术选型时可以参考下面这个清单快速缩小范围。

• 移动端小游戏、休闲游戏、互动营销：选URP。GI方案用烘焙光照贴图加Light Probe，必要时开启LPPV，重点控制烘焙精度和内存占用。
• PC端质感游戏、建筑可视化、数字孪生：优先HDRP。用烘焙方向性光照贴图加Probe Volume，再加SSGI和实时反射，画质上限高且可控性强。
• 主机或高端PC的大世界、开放世界、动态光照类游戏：选UE4。可以用Lumen作为主力GI，烘焙作为底噪补充，如果机器足够强再开启光追GI用于特定场景。

这里面还有一层逻辑：同一个团队如果既有移动端又有PC端需求，可以考虑用URP和HDRP两条渲染管线分开做，Unity的管线切换在2021 LTS及以上的版本里已经比较成熟，但资产消耗和管理成本会翻倍，需要提前想清楚。如果团队是UE4为主，移动端可以考虑用UE4的Mobile Renderer配合烘焙，不要硬上Lumen。

6.2 各引擎GI调试时最常踩的几个坑

先说URP，最典型的问题是光照贴图接缝。接缝的本质是分块贴图在UV边界上的采样不连续，解决办法不只是调Padding，还要检查模型导入设置里Lightmap UV有没有正确生成，特别是通过Blender或Max导出的模型，Lightmap UV通常不会自动生成。另外URP的Light Probe插值穿墙问题也很常见，解决方案是用LPPV和人工布点结合，不要把探针交给全自动布置。

HDRP这边最常遇到的是SSGI的闪烁。SSGI在低分辨率下采样会很稀疏，导致暗部区域的颗粒感和闪烁，处理办法是提高SSGI的采样率或者调整TAA的响应，但更重要的是控制SSGI启用的范围，不必要的地方不要开。HDRP的Reflection Probe实时刷新也是一个坑，用Script刷新时如果每帧都刷会导致严重的性能波动，正确的做法是间隔几帧刷新，或者在反射内容变化明显时才刷新。

UE4的Lumen也有它自己的怪脾气。Lumen在启用后，烘焙Lightmap的时间和内存使用会莫名变大，这是因为Lumen的Distance Field需要为整个场景生成网格距离场，大型场景的这个过程非常吃时间。解决办法是合理调整Distance Field Resolution Scale和动态生成的Mesh距离场的时间预算。另外Lumen对半透明物体和移动物体的支持不如静态物体完善，半透明窗帘后面没有Lumen的间接光溢出是常见的表现，需要美术在做半透明材质时心理有数。

6.3 实战案例复盘：一个室内场景在三套引擎里的GI调校记录

用一个具体案例来说明更有参照价值。一个约120平方米的室内公寓场景，包含客厅、卧室、走廊和一个卫生间，墙面以白色乳胶漆为主，地面是木地板，场景里有多个点光源模拟灯具照明。

URP烘焙调整记录：先用Progressive GPU烘焙，Bounces设为3，Lightmap Resolution设置为60，开启了Compression。跑完一版后，发现客厅和厨房的交界处有轻微的颜色渗漏，把Compression关闭后渗漏有所改善，但内存占用从约180MB升到了260MB，后来通过缩小Lightmap烘焙中无关物体的尺寸来规避。最终URP版本的室内暗部细节尚可，但颜色溢出几乎不可见，画面相对“干净”，也略“平”。

HDRP烘焙与实时混合调整记录：开启Directional Lightmap，Bounces设为4，Probe Volume密度设置为中档，同时开启SSGI和两盏实时Reflection Probe。首版效果比URP浓郁很多，木地板上的反射和环境色溢出都比较明显。但SSGI在低照度的走廊里出现了暗部闪烁，后来把SSGI采样率从半分辨率提升到全分辨率并配合TAA后明显改善。这个版本在同样分辨率下帧耗时比URP版本高约40%到60%，但视觉质量的提升非常直观。

UE4 Lumen调整记录：直接用Lumen作为全局光照，并开启DFAO补接触阴影。初始版本里，客厅的暖色调光源在全屋的蔓延感非常明显，表现力和画面的层次感都超过前两者。问题是材质球的Lumen采样率在近处有点偏高，导致移动镜头时局部闪烁，把Lumen的Screen Trace Resolution从Full降为Half后恢复正常，最终Lumen版本在RTX 2060级别显卡上能保持60帧左右。这个案例直观展示了三套方案在真实场景中的表现差异，也验证了项目中渐进式控制GI开销的思路是可行的。

7. 写在最后的个人建议：GI选型不止是技术问题

每次做渲染对比，最后都会回到同一个结论：技术选型只是实现手段，最终要服务于项目的类型、平台、美术风格和团队能力。URP的GI方案在移动端是务实之选，HDRP的GI方案是高端画质和性能之间的平衡器，而UE4的Lumen和光追GI代表了当前商用引擎在实时全局光照上的天花板。如果你正纠结三套引擎怎么选，我的建议很直接：先把项目目标和目标平台的性能预算写下来，再去跑一个包含核心场景的GI对比原型，最后用帧耗时和内存数据说话，而不是只看渲染出来的截图。

根据我个人在实际项目中的体会，全局光照系统是最能拉开“看起来像游戏”和“看起来像真实世界”差距的环节。烘焙和实时的混用、反射探针和Lumen的互补、SSGI和光追的取舍，这些都是需要反复实验的领域。这篇文章里记录的参数和经验都是我实践过的，你可以直接拿去参考，但最好的方式还是在自己的项目里跑起来，用真实数据调整出适合自己的方案。哪天你也在一个墙角的光晕或者地板的倒影里看到了突破性的质感提升，那就是GI选型成功的信号。