说实话写这篇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服务的是手机和低端PCHDRP服务的是高端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或1024PC可以到2048。Compression移动端保持Normal QualityPC可以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方案是SSGIScreen 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 ModeHDRP的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的毛病。ILCIndirect Lighting Cache和SSGIUE4早期通过引擎自带的 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烘焙GIUnity HDRPSSGI烘焙UE4Lumen间接光实时性无烘焙固定屏幕内实时屏幕外靠兜底完全实时含屏幕外动态物体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里这两者会干扰GIUE4里体积雾也会污染Lumen追踪。全关掉再看效果定位问题更干净。调整曝光。很多所谓暗部有问题其实是曝光设置错了。暗部不是死黑是曝光值压得太低。你先试自动曝光把EV调到合理范围再说。全局光照是渲染里唯一需要“品”的部分。URP烘焙的光是“定妆照”HDRP的SSGI是“半实时半离线”UE4的Lumen是“活的光”。选哪一种和你团队的硬件预算、项目形态、美术产能都有关系不存在一个“永远正确的答案”。我个人的习惯是偏移动端项目一律烘焙但会花足够时间调Lightmap和ProbePC端项目优先用Lumen因为没有明显更好的选择如果发现硬件撑不住再降级到HDRP的SSGI加烘焙混合方案。总之不用太纠结“哪个引擎最强”而是要问“我的项目在哪一档最需要哪种光照手感”。这块内容还能往下拆比如Lumen和HDRP在建筑可视化里的具体表现、URP烘焙在开放世界里的分块策略这些我们之后单独开篇聊。 
长河君 · 2026/9/30 5:16:15 · 阅读 1.2k 全局光照技术对比：Unity URP/HDRP与UE4 Lumen的实时GI方案解析
说实话写这篇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服务的是手机和低端PCHDRP服务的是高端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或1024PC可以到2048。Compression移动端保持Normal QualityPC可以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方案是SSGIScreen 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 ModeHDRP的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的毛病。ILCIndirect Lighting Cache和SSGIUE4早期通过引擎自带的 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烘焙GIUnity HDRPSSGI烘焙UE4Lumen间接光实时性无烘焙固定屏幕内实时屏幕外靠兜底完全实时含屏幕外动态物体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里这两者会干扰GIUE4里体积雾也会污染Lumen追踪。全关掉再看效果定位问题更干净。调整曝光。很多所谓暗部有问题其实是曝光设置错了。暗部不是死黑是曝光值压得太低。你先试自动曝光把EV调到合理范围再说。全局光照是渲染里唯一需要“品”的部分。URP烘焙的光是“定妆照”HDRP的SSGI是“半实时半离线”UE4的Lumen是“活的光”。选哪一种和你团队的硬件预算、项目形态、美术产能都有关系不存在一个“永远正确的答案”。我个人的习惯是偏移动端项目一律烘焙但会花足够时间调Lightmap和ProbePC端项目优先用Lumen因为没有明显更好的选择如果发现硬件撑不住再降级到HDRP的SSGI加烘焙混合方案。总之不用太纠结“哪个引擎最强”而是要问“我的项目在哪一档最需要哪种光照手感”。这块内容还能往下拆比如Lumen和HDRP在建筑可视化里的具体表现、URP烘焙在开放世界里的分块策略这些我们之后单独开篇聊。