UE和Unity同场景下的性能优化，如何降低CPU和GPU占用？

Development Asset Creation
, ,
1
  1. HMI场景均采用静态光照的情况下，UE可以关闭哪些设置或采用哪些优化手段，在HMI移动平台（安卓或Linux）降低CPU占用，缩小与Unity同场景在移动平台的性能差异
  2. HMI场景采用静态光照+部分动态光照(方向光或1-2个点光源)的情况下，UE可以关闭哪些设置或采用优化手段，在HMI移动平台（安卓或Linux）降低CPU占用，缩小与Unity同场景在移动平台的性能差异

<br/>

2

测试分析结论：（结论如有误区，还请指正或解答）

  1. 同元素场景不做特殊处理，UE相比Unity在画面质感上更优
  2. UE引擎自带的工具链更全，方便场景的调整（例如模型和光源），调试工具直观：例如控制台面板、UnrealInsight等
  3. 复杂场景下，UE的场景DrawCall数据比Unity少，但是CPU占用相比Unity要高
  4. UE需要裁剪部分管线设置，可以缩小与Unity的性能差距（//TODO，待Epic提供建议，参考EPIC提供的优化设置方法，再做对比）
  5. 车机上同场景，UE5的CPU占用低于Unity，性能占用需要基于目标设备会有差异（分析：Unity的主线程逻辑（如物理或脚本）未能充分利用多核，而UE的并行化设计在8255上更高效。）
  6. 复杂场景下，UE的剔除实现比Unity更优秀

第3点分析分析：

UE的DrawCall优势

  • 自动批处理更激进：
  • UE默认启用Instanced Static Mesh（ISM）和Hierarchical LOD（HLOD），在复杂场景中会自动合并相同材质的静态网格体，显著减少DrawCall数量。例如，一片树林可能被合并为几个Instanced DrawCall。
  • 更高效的剔除系统：
  • UE的occlusion culling和distance culling在复杂场景中更精准，避免提交不可见物体的DrawCall。

Unity的DrawCall劣势

  • 动态合批限制严格：
  • Unity的Dynamic Batching仅适用于小网格（顶点数≤300），而SRP Batcher需要Shader兼容性，复杂场景中可能失效。

UE的DrawCall数量更低，但这是通过更复杂的CPU端预处理（如HLOD生成、剔除计算）实现的。

第6点分析：

室内场景UE的GPU开销比Unity低，

室外场景下，剔除起作用的范围小，UEGPU开销都大幅上升。

同时UE的材质没有做无方向光光源时的优化，有无方向光GPU差别不大。Unity做了这个优化，场景中无方向光时，GPU开销更低。

UE的PBR材质实现相比Unity更复杂，所以有方向光的室外场景，UE的GPU开销更高

[Image Removed]

3

您好，首先需要明确一下，在效果接近的情况下对比性能才有意义。

针对线下讨论中提供的测试工程，我们做了一点尝试，可以在不降低帧率的情况下减少CPU占用

  1. 使用 -nothreading，使用单线程
  2. 在Gamethread等待帧率锁时，使用FPlatformProcess::SleepNoStats(0.001)替换 SleepNoStats(0); （安卓下sleeptime为0走的是sched_yield）
  3. 在event线程while循环中加入FPlatformProcess::SleepNoStats(0.001)，释放cpu时间

另外就是一些常规的操作：降低分辨率、降低帧率、mesh lod等等