虚幻引擎工程师宣布“大搜索”以消除UE游戏的口吃，给开发者一些提示

　　最近在佛罗里达州奥兰多举行的2025年虚幻节日期间 ，高级虚幻引擎软件工程师Ari arnbjrnsson发表了一篇完全致力于PC游戏玩家的噩梦:口吃的演讲 。

　　在过去的几年里
，我们不得不多次报告新发布的虚幻引擎游戏(但不仅仅是它们，公平地说 ，其他引擎也受到影响)在PC上受到口吃和故障的困扰
。与此同时
，我们问自己:Epic对此做了什么？

　　这基本上是前面提到的演讲的主要焦点，以及对开发人员的最佳实践建议 ，该演讲的标题很恰当
，叫做“伟大的搭便车旅行”，Ari arnbjrnsson穿着猎巫人的服装 ，鼓励其他开发人员“杀死搭便车者 ”。

　　arnbjrnsson确定了结结巴巴的七个主要原因 。第一个，水平流
，实际上更多的是一个类别，包括一系列与加载或卸载游戏世界部分相关的问题
。根据虚幻引擎工程师的说法 ，一个常见的原因是静态几何图形的静态网格角色的误用。通常
，艺术家和关卡设计师会引入许多静态的网格角色，如桌子 、书籍
、餐具等 ， 这对小游戏来说没问题
，但对大型或AAA级的世界来说可能是灾难性的，因为它们会带来开销 ，需要内存负载
，并且必须被垃圾收集器扫描 。

　　arnbjrnsson建议使用实例化静态网格(ISMs)或分层实例化静态网格(HISMs)
。还可以部署打包级别的演员功能，将许多静态网格组合成更少的演员 ，从而减少开销。工程师然后切换到Epic正在做什么来改善级别流故障
， 例如实验性的虚幻引擎5.5单元转换器功能，该功能在运行时将静态网格演员转换为实例化网格 ，以及虚幻引擎5.6引入的实验性流性能改进 。默认情况下，实验功能不会打开
，但一旦准备就绪，就会打开。

　　第二个原因实际上是物理 ，因为内容团队往往不会为他们优化
。Nanite和虚幻引擎5的引入让开发人员相信他们可以简单地在他们的世界中加入复杂的网格
，他们会神奇地工作而不会出现问题，但事实并非如此。应该尽可能使用简单的碰撞形状 ，而不是复杂的物理形状
，顺序如下:球体(最快)、胶囊 、盒子和(最后) 凸多边形 。甚至不能与之互动的远距离物体应该被完全禁用
。Chaos Visual Debugger可以进一步帮助分析由物理引起的性能问题。

　　关于Epic在这方面正在进行的工作，arnbjrnsson指出了虚幻引擎5.5/5.6中可用的异步物理初始化 ，这也仍然是实验性的 。这减轻了游戏线程的物理计算负担
， 但是工程师建议暂时不要使用它
。他还警告说，这可能会适得其反 ，因为它似乎可以解决问题
，直到物理场景发展到问题变得更糟的地步。管理一个物理场景应该有多大仍然是开发人员的首要任务 。Epic还通过更好的多线程和其他优化不断改进混沌物理学
。

　　然后是演员繁殖障碍:具有许多组件(骨骼网格
、动画)如角色的复杂演员可能需要几毫秒才能繁殖，导致明显的帧丢失 ，特别是如果许多演员同时繁殖。建议包括限制每帧产生的演员数量，延迟骨骼动画等组件的初始化以在产生后异步运行
，尽可能将演员集中在一起而不是破坏和创建，以及重用隐藏的演员 。

　　arnbjrnsson表示 ，一些开发人员要求Epic将演员池作为标准的虚幻引擎功能来实现
。虽然这正在研究中
，但实际上很难实现，因为他们必须为每个行业的每个项目支持每个演员类型(虚幻引擎现在不仅仅被游戏开发者使用)。目前 ，开发人员应该为每个参与者类型构建定制的池 。

　　第四个可能是PC游戏中最常见的口吃实例:流水线状态对象(PSO)编译。像DirectX12、Vulkan和Metal这样的现代低级API在渲染之前需要完全编译的着色器
。这对于控制台来说不是问题
，因为它们都有相同的硬件配置。然而，在PC和移动设备上运送所有编译的排列是不可能的 ， 并且动态编译着色器不可避免地会导致问题 。游戏一直试图使用捆绑PSO缓存进行预编译
，但这并不完美，也很困难 ，尤其是对于开放世界或程序性内容
。

　　PSO预缓存是虚幻引擎5.3中引入的
，应该经常使用，但它本身是不够的。arnbjrnsson敦促开发人员准备自己的PSO编译策略 ，并使用他创建的PSO Cache Buster插件(可以在这里下载)来描述他们的游戏 。Epic仍在努力进一步改进PSO预缓存
。他们现在已经捕获了主要虚幻引擎样本项目和堡垒之夜的所有代码路径。

　　第五个原因是垃圾收集障碍 。当有太多未使用的UObject实例时，就会发生这种情况
，导致垃圾收集器花费太长时间，并引起口吃
。因此 ，开发人员应该努力保持UObject计数的可管理性
，并有策略地调度GC以避免意外高峰。Epic的工程师们正在研究目前处于试验阶段的增量可达性分析特性，以将垃圾收集器的工作分散到多个帧上 ， 以及关注未来客户端构建的多线程安全增量GC 。

　　第六种称为同步加载障碍
，当阻塞(同步)资产加载使游戏线程停滞直到资产完成加载时，就会发生这种情况 ，从而导致非常长的障碍
。在任何情况下都不允许这样做——只能使用异步加载。资产验证器(像arnbjrnsson的CommonValidators)可以捕捉阻塞负载的使用
，一些工作室甚至直接从蓝图中删除了阻塞负载节点 。就其本身而言， Epic正在虚幻引擎中添加警告和工具 ，以通知用户有关阻塞负载的信息。尽管如此
，如果有人偷偷通过，UE5.4/5.5引入了部分刷新异步队列的能力 ，以减少故障影响
。

　　最后但并非最不重要的一点是，由于开发人员在蓝图或内容脚本中做了太多的工作
，如太多的计时器 、太多的刻度更新
、臃肿的序列或音频/骨骼动画制作人员使系统过载，导致了蓝图和内容的问题。开发人员方面的修正例子包括伪造或简化远处的物体 ，关闭不必要的滴答和计时器 。就其本身而言
， Unreal Engine maker继续扩展Unreal Insights工具，使其具有更好的可用性和功能 ，如区域标记和屏幕截图
，使开发人员更容易可视化和优化性能
。

　　在结束语中，arnbjrnsson提醒所有游戏开发者 ，尽管硬件和软件取得了许多进步
，但游戏开发仍然有局限性。因此，努力的优化工作和巧妙的“伪装
”对于获得最佳结果仍然是非常必要的 。希望这次谈话能让开发者们看到这个猖獗的问题 ，让我们的游戏体验更加流畅
。