ARTICLE DETAIL

资讯详情

深耕网站建设与运营推广的一线实战洞察。

从烘焙到Lumen:Unity与UE4全局光照技术对比

从烘焙到Lumen:Unity与UE4全局光照技术对比 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适合封闭室内和局部区域远处的大环境可以用天空盒或者一个覆盖全场景的探针兜底。探针的规格和质量很容易被忽视。常见问题有两个探针更新时机没设置好。如果是静态场景探针烘焙一次关掉Realtime即可如果场景里有大量移动物体希望反射也跟着变化可以打开实时更新但会带来每帧额外渲染开销。探针分辨率不够导致金属表面糊成一片。特别是车漆、金属地板这类光滑表面128的Cubemap远不够用至少要256以上。再补充一个Light Probe和Reflection Probe的配合逻辑。Light Probe解决动态物体的漫反射间接光Reflection Probe解决动态物体的镜面反射二者缺一不可。只放探针不布置Light Probe角色身上暗部会显得非常死只布置Light Probe不放反射探针金属材质则完全看不出反光环境。2.3 URP 14的Adaptive Probe VolumesAPV实测如果你用的是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技术SSGIScreen Space Global Illumination在屏幕空间内计算间接光反弹对视觉提升极其明显SSRScreen 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 UVUE4老版本项目里最常见的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在屏幕空间内追踪反射光线动态物体、动态光源都能响应也不会像探针那样因为覆盖范围不足产生明显跳变。缺点是屏幕外和遮挡后的反射信息都是残缺的所以需要探针来补远场。DDGIDynamic Diffuse Global Illumination是另一条路线。它用一组实时更新的Irradiance Probe Volume替代静态Lightmap探针位置上的光照信息每秒更新几次从而让动态物体获得动态间接光。UE4社区里很多研究性项目用DDGI实现类似Lumen的效果但需要自己维护Volume放置和更新逻辑工程量和Lumen相比不是一个量级。我的结论是Lumen已经让UE4的实时GI形成了全动态的默认心智Reflection Capture和SSR不再是核心竞争力只是辅助配件。如果你用UE4还想着传统烘焙贴图那等于主动放弃了引擎最强的动态光照优势。5. 三条管线全局光照的对照表与选型建议5.1 核心参数对比表为了让大家快速对照我把三套管线在全局光照上的关键差异整理成表。对比维度Unity URPUnity HDRPUE4 / UE5静态GILightmap烘焙APV可选Lightmap烘焙APV推荐Lightmass烘焙UE4LumenUE5动态GILight Probe Group / APVAPV、SSGISSGI、DDGI、Lumen屏幕空间反射目前不支持SSR支持SSR支持SSR反射探针Reflection ProbeReflection Probe层级反射系统Reflection Capture体积光/雾需外挂或简单雾效内置Volumetric FogFroxel内置Volumetric Fog移动端友好度高低低实时GI表现较弱中等SSGI局部很强强Lumen全局实时烘焙流程简单Unity内部完成复杂需要单独配置中等Lightmass一次全场景烘焙动态场景支持较差中上最好硬件要求低高高但软件Lumen容错较好5.2 不同项目类型该怎么选给项目选GI方案我一般先分清四个场景。第一类是移动端休闲或中轻度游戏目标机型是中低端安卓机。这个场景下URPLightmapLight Probe是最稳的HDRP基本不用考虑。移动端如果非要用APV建议控制探针总量Shader复杂度也要压低不要开SSGI或者体积雾。第二类是PC/主机上的偏向写实画面或单机项目。HDRP会是收益最明显的选择室内场景用SSGIAPV能兼顾性能和动态感室外大世界可以把SSGI关掉或降级靠烘焙探针扛大尺度间接光。第三类是使用UE5做次世代游戏或数字孪生演示的项目。直接开Lumen软件追踪起步硬件追踪根据显卡配置升级。烘焙Lightmap只作为Lumen不支持的极端情况兜底。第四类是建筑可视化、影视预演这类对画面质感敏感但对帧率宽容度更高的场景。HDRP和UE5 Lumen都能用关键看团队对Unity还是UE4熟悉。这类项目里间接光连续性和反射质量远比运行帧率重要。5.3 帧率开销与Shader复杂度的一些实测数据这里提供我自己的性能测试参考不是官方标准仅仅作为选型时的量级参考。同样的纯室内场景几何面数约200万在RTX 3060、1080p下URP关闭SSGI、使用LightmapAPV时GI相关Pass约占0.3ms到0.8msShader整体较轻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的另一条路线。选哪套方案取决于你的平台、美术方向和性能预算而不是谁的招牌更响。希望这篇对比能帮你少踩几个我踩过的坑。
返回列表