1. 为什么UE5项目一开始就要做性能规划很多人拿到UE5之后的第一反应是赶紧把场景搭起来、把蓝图连起来、把角色跑起来等到打包出来发现帧率掉到个位数才开始翻文档找优化方案。这种“先做后优”的思路在UE4时代勉强还能撑一撑到了UE5尤其是开了Lumen和Nanite之后基本等于给自己挖坑。我见过太多项目在中期发现性能瓶颈回头去改渲染路径、改材质结构、改关卡组织方式工作量比重新做一个Demo还大。这篇笔记主要聊的是UE5性能优化的基础认知和项目设置层面的关键操作。它不涉及具体的材质节点优化或者蓝图逻辑重构而是聚焦在“项目创建那一刻就应该定下来的事情”。适合谁看如果你刚开始接触UE5或者已经做了一个原型但还没正式进入量产阶段那这些内容能帮你省下大量返工时间。如果你已经在做一个中大型项目也可以对照检查一下项目设置里有没有踩到一些默认值的坑。核心关键词就三个UE5、性能优化、项目设置。我会把每个设置项背后的逻辑讲清楚让你知道改什么、为什么改、不改会怎样。所有操作都基于UE5的默认模板和常见硬件环境不涉及特定平台的独占配置。2. 项目创建阶段的性能相关决策2.1 模板选择对性能的隐性影响打开UE5新建项目的时候你会看到一堆模板第一人称、第三人称、俯视角、载具、空白等等。很多人随手选一个第三人称就开始改觉得反正后面都能删。但模板之间的差异不只是“有没有角色蓝图”这么简单它们在渲染设置、默认关卡、后处理体积配置上都有区别。举个例子第三人称模板默认开启了Lumen全局光照和反射后处理体积里还开了Bloom、环境光遮蔽、屏幕空间反射等一堆效果。如果你做的是一个移动端项目或者风格化渲染的项目这些默认开启的功能会直接吃掉大量GPU预算。而空白模板虽然干净但需要你手动配置输入映射、游戏模式、默认Pawn等基础内容对新手不太友好。我的建议是先明确目标平台和渲染风格再选模板。做移动端或者Switch级别的项目选空白模板或者第三人称模板后立刻关掉Lumen和Nanite做PC高端项目第三人称模板可以保留大部分默认设置但后处理体积里的参数需要根据美术风格调整。2.2 项目设置里必须第一时间改的几项项目创建完成后先别急着往场景里拖东西。打开Edit - Project Settings有几个地方需要立刻确认。第一是默认RHI。在Platforms - Windows - Targeted RHIs里UE5默认用的是DirectX 12。DX12对Nanite和Lumen的支持最好但它的驱动开销比DX11高在一些老显卡上反而更慢。如果你的项目不用Nanite和Lumen可以切到DX11试试帧率可能会有明显提升。不过要注意DX11不支持虚拟阴影贴图等UE5新特性切之前想清楚。第二是着色器编译模式。在Engine - Rendering - Shader Compilation里有个Allow Shader Compilation on Worker Threads选项。默认是开的但在某些机器上会导致编辑器卡顿。如果你发现编辑器经常在后台编译着色器导致操作不流畅可以关掉它代价是打包时编译时间变长。第三是默认抗锯齿方法。UE5默认用TSRTemporal Super Resolution效果确实好但开销也不低。移动端或者低配PC可以考虑换成FXAA或者关掉用分辨率缩放来弥补画面损失。2.3 渲染管线的选择逻辑UE5提供了前向渲染和延迟渲染两条路径。默认是延迟渲染因为它支持更多高级效果。但延迟渲染的G-Buffer开销在移动端和低端硬件上是很大的负担。前向渲染在UE5里主要通过移动端渲染器实现PC上也可以强制开启。它的优势是带宽占用低、支持MSAA适合材质简单、光源数量少的场景。缺点是动态光源多了之后性能下降很快而且不支持一些延迟渲染才有的效果。怎么选一个简单的判断标准如果你的场景里动态光源超过8个或者需要用到SSR、SSAO这类屏幕空间效果用延迟渲染如果场景以静态光照为主、光源少、目标硬件性能有限前向渲染更合适。这个选择在项目中期改动的成本很高因为材质节点和光照构建方式都不一样。3. 渲染设置中的关键参数拆解3.1 Lumen的取舍与替代方案Lumen是UE5的标志性功能但它也是性能大户。在Project Settings - Rendering - Global Illumination里你可以选择Lumen、Screen Space GI或者None。Lumen的代价主要体现在两个方面GPU的追踪开销和CPU的Scene Capture开销。在复杂场景里Lumen的每帧追踪次数会随着屏幕分辨率和场景复杂度线性增长。我实测过一个中等复杂度的室内场景开Lumen之后GPU帧时间从8ms涨到了18ms直接翻倍。如果你的项目不需要动态全局光照比如场景光照是固定的、或者美术风格是风格化的完全可以关掉Lumen用烘焙光照贴图来替代。烘焙光照的质量在静态场景里不比Lumen差而且运行时开销几乎为零。UE5的Lightmass烘焙虽然慢但效果稳定适合中小型项目。如果一定要用Lumen至少把Lumen Scene Lighting的质量调低把Final Gather Quality从默认的1降到0.5再把Screen Traces的精度降一档。这些改动在视觉上损失不大但能省下不少GPU时间。3.2 Nanite的适用边界Nanite是另一个UE5的招牌功能它允许你直接导入高面数模型而不用手动做LOD。但Nanite不是万能的它有自己的适用边界。首先Nanite只对静态网格体生效骨骼网格体、粒子、地形都不支持。其次Nanite的裁剪和光栅化有自己的开销在面数低于一定阈值的时候传统LOD反而更快。根据Epic的文档大概在几万面以下的模型用Nanite的收益就不明显了。更重要的是Nanite对材质复杂度很敏感。如果一个模型用了很多不同的材质IDNanite的材质评估开销会急剧上升。所以即使用了Nanite也要尽量合并材质、减少材质槽数量。在项目设置里Nanite的开关在Engine - Rendering - Nanite。如果你确定不用直接关掉可以省下一些内存和编译时间。如果要用记得在打包设置里确认目标平台支持Nanite移动端目前对Nanite的支持还很有限。3.3 虚拟阴影贴图的性能特征虚拟阴影贴图VSM是UE5默认的阴影方案它比传统的CSM阴影质量更高但开销也更大。VSM的核心问题是它需要为每个光源渲染一张虚拟阴影图光源越多开销越大。在项目设置里Engine - Rendering - Shadows - Shadow Map Method可以切换VSM和CSM。如果你的场景里动态光源很多比如有很多点光源和聚光灯VSM的开销会非常可观。这时候可以考虑切回CSM或者限制动态光源的数量用静态光照来补。还有一个容易忽略的点VSM对移动端的支持很差。移动端项目基本都要用CSM或者更简单的阴影方案。在项目设置里确认Mobile - Shadows里的选项别让默认值坑了你。4. 项目设置中的性能相关项实操4.1 打包设置里的性能陷阱打开Project Settings - Packaging有几个选项直接影响运行时性能。第一个是Use Pak File。默认是开的把资源打包成一个pak文件。这对加载速度有好处但在某些平台上会导致内存占用上升因为pak文件的索引需要常驻内存。如果项目资源量不大可以关掉试试。第二个是Compress Content。默认开启压缩能减小包体但运行时解压需要CPU时间。对于CPU瓶颈明显的项目可以关掉压缩用空间换时间。第三个是Share Material Shader Code。这个选项影响着色器代码的打包方式。开启后多个材质共享着色器代码能减小包体但可能导致运行时需要重新编译着色器。建议保持默认开启除非你发现运行时有明显的着色器编译卡顿。4.2 平台相关的渲染设置在Project Settings - Platforms下面每个目标平台都有自己的渲染设置。以Windows为例Windows - Rendering里有几个关键项。Targeted RHIs前面说过了这里补充一点如果你同时勾选了DX11和DX12打包出来的可执行文件会更大而且启动时需要检测硬件支持哪个版本增加启动时间。建议只勾选目标硬件确定支持的版本。Use Forward Shading这个选项在移动端默认是开的PC端默认关闭。如果你的PC项目确定不用延迟渲染特性可以勾上它能省下G-Buffer的带宽和内存。还有一个Occlusion Query相关的设置在Engine - Rendering - Occlusion Culling里。UE5默认用硬件遮挡查询但在某些驱动上会有延迟。如果发现物体弹出Pop-in严重可以试试关掉硬件遮挡查询用软件遮挡或者干脆不用。4.3 内存与流送设置Project Settings - Engine - Streaming里控制着纹理流送和关卡流送的行为。纹理流送池的大小直接影响纹理加载的流畅度。默认值是根据平台自动计算的但在内存紧张的设备上可能需要手动调小。调太小会导致纹理频繁加载卸载出现模糊调太大则挤占其他系统的内存。关卡流送在开放世界项目里很关键。Level Streaming里的Async Loading Thread选项可以控制关卡加载是否在独立线程进行。开启后能减少主线程卡顿但会增加内存峰值。移动端建议开启PC端看情况。还有一个容易忽略的Texture Streaming的Pool Size在移动端默认很小如果项目里有很多高分辨率纹理需要手动调大否则会出现纹理一直模糊的情况。5. 常见性能问题与排查思路5.1 编辑器卡顿与运行时卡顿的区分很多人分不清“编辑器里卡”和“打包后卡”。编辑器卡顿通常是因为着色器编译、资产加载、蓝图编译这些编辑器特有的开销。运行时卡顿则是渲染、逻辑、物理这些实际游戏循环的问题。排查方法很简单用Stat命令。在编辑器里按~打开控制台输入Stat Unit看帧时间分布。如果Game线程时间高说明逻辑或物理有问题Draw线程时间高说明渲染提交有问题GPU时间高说明渲染本身有问题。编辑器里还可以用Stat StartFile和Stat StopFile来录制性能数据然后用Unreal Insights打开分析。这个工具能精确到每个函数的耗时是定位性能问题的利器。5.2 默认设置导致的典型性能问题我整理了一个常见问题速查表都是项目设置层面能解决的问题问题现象可能原因检查位置解决方向打包后帧率远低于编辑器打包用了不同的渲染路径Project Settings - Platforms确认RHI和渲染设置一致移动端发热严重Lumen或VSM在移动端被强制开启Project Settings - Mobile关闭高级光照特性纹理一直模糊纹理流送池太小Project Settings - Streaming调大Pool Size启动时间过长着色器编译或Pak文件索引Project Settings - Packaging调整压缩和Pak设置动态光源多了就掉帧VSM或延迟渲染开销Project Settings - Rendering限制光源数量或切CSM场景切换卡顿关卡流送同步加载Project Settings - Streaming开启异步加载线程5.3 实操心得与避坑建议第一个坑不要迷信默认值。UE5的默认设置是面向“展示效果”的不是面向“运行性能”的。Epic在默认模板里把能开的特效都开了是为了让你第一眼看到惊艳的画面。但实际项目里这些默认值往往需要根据目标硬件大幅调整。第二个坑项目中期改渲染路径的成本极高。延迟渲染和前向渲染的材质节点不兼容Lumen和烘焙光照的工作流完全不同。如果项目做了一半才发现选错了路径基本等于重做。所以项目设置一定要在原型阶段就定下来。第三个坑移动端和PC端的设置要分开管理。UE5支持为不同平台配置不同的设置但很多人图省事只用一套。结果就是PC上跑得好好的移动端直接崩。建议在Project Settings - Platforms里为每个目标平台单独调参用Device Profiles来管理不同档次的设备。第四个坑性能优化不是“后期工作”。我见过太多团队把性能优化放在最后一个月结果发现根本来不及。正确的做法是每个里程碑都做性能验收在项目设置层面就把该关的关掉、该调的调好后面只需要关注内容层面的优化。6. 从项目设置延伸到内容制作的性能意识项目设置只是性能优化的第一步它决定了你的“性能预算”上限。但真正吃掉性能的还是场景里的内容模型面数、材质复杂度、光源数量、蓝图逻辑、粒子效果等等。举个例子即使你在项目设置里关掉了Lumen如果场景里有几百个动态点光源延迟渲染的G-Buffer和阴影开销依然会爆炸。即使你用了Nanite如果每个模型都有十几个材质槽材质评估的开销也会让GPU吃不消。所以项目设置和内容制作是互相制约的关系。项目设置决定了你能用什么特性内容制作决定了你用这些特性用得好不好。我的建议是在项目设置阶段就定好性能预算比如“GPU帧时间不超过16ms”、“Draw Call不超过2000”、“动态光源不超过20个”然后把这个预算传达给所有内容制作人员让大家在制作过程中就有性能意识。还有一个实操技巧用Scalability设置来管理不同档次的画质。UE5的Scalability系统允许你为低、中、高、极高四档画质分别配置渲染参数。在项目设置里把Scalability的默认值调好然后在游戏里根据硬件自动切换。这样一套内容可以适配多种硬件不用为每个平台单独做版本。最后分享一个我自己的习惯每做完一个功能模块就用Stat Unit和Stat GPU跑一遍记录帧时间变化。如果某个模块导致帧时间明显上升立刻排查原因不要等到最后一起算账。这个习惯帮我避免了很多次“后期优化地狱”。性能优化这件事说到底就是在正确的时间做正确的决策。项目设置阶段的决策成本最低、收益最高但偏偏最容易被忽略。希望这篇笔记能帮你在这个阶段少走一些弯路。