UE5 里自带的那套 Chaos 物理引擎，从诞生那天起就把“并行”写进了基因。不管你是做开放世界、大规模破碎、高密度物理交互，还是单纯想让 NPC 堆叠和载具碰撞别再拖后腿，如果不理解它的并行调度方式，迟早会在 Profile 里看到一堆线程空闲、而物理时间稳居榜首的诡异画面。
这篇文章就针对“UE5 物理引擎解析-并行优化”展开。我会从 Chaos 的架构背景、隔离岛模型、碰撞与求解的并行策略，一直聊到工程配置、性能分析和实战踩坑。适合那些已经开始用 UE5、想在项目里认真做物理调优的开发者，也适合刚接触 Chaos、想搞清楚它和传统物理引擎在工作方式上到底差在哪的新手。读完你至少能看懂物理相关参数在干什么、瓶颈从哪里看起、以及怎么用最小的配置代价换回可观帧数。
1. 从单线程到多线程协作：Chaos 并行架构的设计基调
1.1 为什么 UE5 要换掉旧物理核心
在 UE5 之前的很长一段时间里，引擎里的刚体物理是靠外部物理中间件撑起来的。那个时代的方案确实成熟稳定，开了几个基础碰撞就能跑，但问题也很明显：它是一个相对封闭的体系，引擎只能以“黑盒”的方式调用它，想扩展布料、破碎、流体的统一物理模型非常吃力。
Chaos 这套体系不一样。它把刚体、布料、破碎、甚至部分流体和粒子效果的模拟都统一到一套架构下。刚体破碎时产生的碎块还是刚体，碎块上再挂一层布料效果，引擎内部可以共享同一套约束求解和空间加速结构，不需要在不同物理系统中做数据转换。这种统一，也自然让并行调度成了一个跨模块的基础设施问题，而不是某个子系统的补丁。
我在实际项目里最深的感觉是，换到 Chaos 后，物理世界的“数据归属”清晰了不少。同一个世界里的物体、场、约束、碰撞数据，都走同一套管理和迭代路径，做断点调试和性能分析时不用反复猜测某个参数到底作用在哪个子系统上。
1.2 物理并行要解决的三组核心矛盾
并行优化的本质不是“开多线程”这么简单，而是要处理三组绕不开的矛盾：模拟正确性、实时性、以及多线程引入的额外开销。
第一组矛盾是模拟步进的依赖关系。一个刚体下一帧的运动状态，依赖它当前受到的接触力和约束力，而接触力又依赖其他物体的位置，这就是所谓的“数据依赖链”。如果所有物体都依赖彼此，那没法并行；好在物理世界里大量物体之间其实没有直接联系，这就有了可并行的空间。
第二组矛盾是实时性与计算精度的权衡。物理求解通常是迭代过程，迭代次数越多越稳，但每多一次迭代都是开销。并行虽然能摊薄计算量，但如果并行引入的同步次数过多，线程之间的等待和缓存同步又会吃掉收益。
第三组矛盾是任务粒度。一个物体模拟得太细，任务调度本身的开销会比计算还大；一个任务颗粒太粗，线程又喂不饱。后文要聊的“隔离岛”模型，核心就是在解决这个问题。
1.3 并行物理的适用边界
并不是所有项目都该无脑开启每一层并行。比如一个同时在线物体数量很少的俯视策略游戏，物理负载本来就很轻，此时开多线程反而要承担线程调度和同步的固定开销。又比如移动端，CPU 核心数量少、单核性能弱，盲目套用 PC 的并行参数可能更糟。
从我的经验看，以下这些场景从并行优化中获益最明显：大世界场景中散落大量静态碰撞物和角色、带有破碎的大规模场景破坏、车辆或布娃娃极多的战斗场面、以及需要模拟成百上千个小刚体的丢掷物或碎片系统。如果你的项目里物理角色平均不超过几十个，那这篇文章里的大部分“性能调优”内容可以当作知识储备，不必急着全上。
2. 隔离岛模型：Chaos 怎么把物理世界切块
2.1 接触图与约束依赖的建模
物理引擎里判断两个物体能不能并行求解，不是看它们在空间上隔了多远，而是看它们之间有没有“联系”。这个联系通常指接触约束、关节约束、或是作用在同一组物体上的场力。把所有具有直接或间接依赖关系的物体连成一张图，这张图就是“约束图”。
Chaos 会把约束图拆成一个个没有互相依赖的连通分量，也就是隔离岛。同一个岛内的物体需要一起解算，不同岛之间的物体彼此不影响，可以交给不同线程并行处理。
你可以把岛想象成互不相连的积木城堡，每个城堡里的人可以各干各的，只有城堡内部的人需要互相配合。物理引擎每帧都会根据当前的碰撞和约束关系，动态重新组织这些岛，因为物体之间的接触关系每帧都在变。
2.2 TaskGraph 与持久线程：并行任务怎么被消费
有了岛之后，下一步是把这些“可以并行的工作”塞给 CPU 的多个核心。UE5 的底层并行调度主要靠 TaskGraph 体系。这个框架有点像一个工厂里的派单系统：任务被描述成一个个带依赖关系的节点，调度器负责把它们分配给工作线程，同时保证某个任务依赖的前置任务已经完成。
Chaos 在 TaskGraph 上有一套自己的任务模型，而且当物理负载比较重的平台或项目里，引擎会保持一定数量的持久工作线程来专门消费物理任务，减少线程反复创建销毁带来的开销。这不等于说物理任务永远固定在某个线程上，而是说在物理负载稳定上升时，线程池能更快进入满载状态。
我在项目里观察过 TaskGraph 的线程活动。物理负载升高时，工作线程的数量会跟着上来；负载下降时，线程使用率也会回落。这套机制不是简单的“开 N 个线程跑死循环”，而是动态响应式的，因此配置线程数时不需要像早期游戏引擎那样手动精确控制每一个物理线程。
2.3 并不是岛越小越好：任务粒度的取舍哲学
并行优化的一个反直觉之处在于：单纯把物理世界切得越碎，不一定越快。因为切碎后，每个小任务都要经过一次线程调度的分配与唤醒，如果任务本身只需要几十微秒就执行完，调度开销反而可能占到一半以上。
Chaos 的做法是对岛做粒度合并。一些很小、互相又不冲突的岛，会被聚合到同一个并行任务里处理，避免调度器被海量细碎任务淹死。这个聚合阈值是动态判断的，考虑因素包括岛内物体数量、预期计算量、当前系统负载等。
（基于常见的工程实践补充一下：中小型项目通常不需要修改这个阈值，引擎的自动调节在多数场景下已经够用。只有在极端场景——比如同时出现上万个相互独立的小刚体——才值得去手动观察和调整，而且要先确认瓶颈确实在任务调度，而不是在渲染或碰撞查询上。）
3. 逐段拆解碰撞与求解：每个环节的并行策略
3.1 BroadPhase 与 NarrowPhase：先把“可能碰”的找出来，再精确算
物理模拟一帧可以粗略分为三个阶段：BroadPhase 粗略碰撞筛选、NarrowPhase 精细碰撞检测、约束求解与位置修正。
BroadPhase 的任务是快速过滤出“有可能碰撞”的物体对，它不需要精确计算，而是用包围盒粗筛。Chaos 在这个阶段同样支持并行，它会根据空间分布把物体对列表拆成多个子区间分别处理。因为包围盒测试本身计算量小、数据依赖少，非常适合多线程并行。
NarrowPhase 则是把候选对拿出来做真正的碰撞检测，比如凸多边形之间的相交计算、接触点生成等。这一步看似是逐对进行的，但不同物体对之间的计算互不影响，所以天然的并行度很高。Chaos 会把不同岛中包含的碰撞对分发到不同工作线程上处理，而这个阶段往往也是物理耗时的大头之一。
节点上要提醒的是，NarrowPhase 并行时接触点生成的顺序是不确定的，这会导致后续约束求解在浮点精度上产生细小的顺序差异。差异未必肉眼可见，但在追求确定性回放或联机同步时，这是必须正视的问题，后面第 6 节会专门展开。
3.2 约束求解器：为什么迭代法更适合并行
当一个岛内的多个物体通过接触约束互相堆叠时，引擎需要解一个约束方程组来确定每个物体的修正量和速度变化。传统思路是直接求解一个耦合的大矩阵，这在数学上精确，但时间复杂度高，而且对大岛几乎无法并行化。
Chaos 使用的迭代求解思路更接近“反复修正”：每轮迭代里，依次处理岛内的每个约束，根据当前状态算出物体需要调整的量，应用到物体上，然后进入下一轮迭代。多轮迭代之后，整体状态会收敛到一个稳定的支撑状态，视觉上表现为物体堆叠稳定、不会明显抖穿。
这种迭代法天生对并行友好。岛内的约束可以按一定的策略分到不同线程上先行处理，虽然同一约束两端的物体不能完全无关，但不同区域的约束往往可以同时推进。UE5 的 Chaos 在这一层采取的策略，本质上是结合了岛并行和图内分层并行，让一个比较大的岛也能被多个线程协作解算。
需要注意，增大迭代次数会让堆叠更稳定，但代价是线性增长的物理耗时。在并行优化中，时间预算比单纯的“稳定”更重要：与其无脑加迭代，不如先确认当前瓶颈在求解阶段还是碰撞阶段，再决定是加迭代还是优化布防。
3.3 异步物理场景与 GPU 物理的边界
除了把模拟过程本身并行化，UE5 还提供了一种更高层的“并行方式”：异步物理场景。简单说，开启异步场景后，物理模拟可以在游戏线程帧更新之前或之后异步运行，物理结果可以落后渲染一小段，避免物理计算阻塞游戏逻辑。
异步场景的收益在于：当物理耗时偶尔超过一帧预算时，它能让游戏逻辑和渲染先走，物理在后台慢慢追赶，从而实现一种“削峰填谷”的帧率稳定效果。但它会引入输入延迟和命中检测的时序问题，并不是所有项目都适合直接开启。
GPU 物理则是一个经常被误解的概念。Chaos 本身的刚体模拟主要跑在 CPU 上，GPU 的强项是大量并行简单计算，常用于粒子系统或特定视觉效果。所以不要把“并行优化”直接等同于“掏出 GPU 跑物理”。实际项目里最先该压榨的，永远是 CPU 侧的空间划分、碰撞对处理、岛调度和线程利用率。
4. 工程实战：并行优化参数清单与配置建议
4.1 项目设置里的关键开关
物理相关的项目设置分散在 Project Settings 的 Physics 分类下，左侧搜索框输入 Physics 就能看到全部条目。下列是我每次做物理优化时一定会关注的几项。
| 参数 | 作用与建议 |
|---|---|
| Max Physics Delta Time | 限制一帧内物理模拟的最大时间增量，建议给一个有限值，比如 1/15 秒左右，防止“死亡螺旋” |
| Max Substeps | 一帧内最多可拆分的物理子步数，堆叠场景可以适度调大，但一般从默认值先测 |
| Use Async Scene | 异步物理场景总开关，帧率不稳或物理耗时普遍偏高时可尝试开启并观察时序 |
| CCD | 连续碰撞检测，高速物体必须开启，但开启后碰撞对计算量倍增，别全局滥用 |
| Deterministic Mode | 确定模式开关，需要复现物理行为时打开，但可能需要限制并行度以换确定性 |
| Physics Thread Mode | 设置物理线程与游戏线程的同步或异步关系，异步模式下重叠度更高 |
这些参数不是独立生效的，它们会互相影响。比如你把 Max Substeps 调大，同时又把 PhysX 固定步长调得很小，就可能让一帧里出现非常多次子步，物理耗时成倍增长。调参时最好一帧一帧跑 Profile，而不是一次性全部调完。
4.2 运行时统计与动态调试方法
打包版本里一般看不到编辑器里的物理调试信息，所以我在实际调优中会习惯用控制台命令留下关键性能数据。常用思路是打开 stat 组统计面板，逐项查看物理耗时占比。stat physics、stat chaos 这类命令会显示物理总耗时、碰撞检测耗时、约束求解耗时等分项。
不过 stat 面板只能看“值”，看不出“线程到底有没有吃饱”。要想看并行效果，最好的办法是用 Unreal Insights 抓一次带 CPU 时间线的会话。从时间线上可以看到物理任务在多个线程上的分布，几个线程同时跑物理任务，还是物理任务挤在同一个线程上串行排队，一目了然。
我在项目里通常的做法是：先开 stat chaos 看整体物理耗时，再用 Insights 抓详细任务分布。如果物理耗时高、但线程分布均匀，说明负载确实高，考虑减迭代或减物体；如果物理耗时高、但只有单线程在跑，说明并行度没吃满，这种时候调参数往往事半功倍。
4.3 PC 与移动端的差异化调参
PC 平台的 CPU 核心数和单核性能都比较充裕，可以更大胆地开启异步物理场景、增加子步数，甚至允许物理任务使用更多的工作线程。移动端则相反，核心数少，而且多线程调度本身会带来额外的功耗和发热。
我见过不少团队把 PC 上调试好的物理参数直接搬到移动设备上，结果帧率直接砍半。移动端常用的压缩手法是：缩小物理增量时间的上限，减少子步数，强制关闭一些不必要的 CCD，以及降低可破碎物体的最大数量。这本质上是把“计算精度”换成“稳定帧率”。
另外，移动端物理耗时高不要总是归咎于引擎物理求解本身，很多瓶颈其实是复杂碰撞体数量太多。对方的 Mesh 碰撞体往往比几个简单的 Box 组合更贵。做移动端优化时，优先用胶囊体、盒体替代 Mesh 碰撞，往往比改并行参数更有效。
5. 性能分析：怎么证明你的并行优化真的有效
5.1 先建立性能基线，再做对比实验
任何优化都应该以数据为起点。我会在项目里固定一个压力场景，比如一场有大量敌人倒下并产生碎片堆叠的战斗，录制一段固定操作路径，然后记录每一帧的物理耗时和总帧耗时作为基线。之后每次改参数，都跑同样的路径对比，避免“手感”被场景随机性误导。
注意基线场景要尽量覆盖物理压力的峰值，而不是平均负载。因为在并行优化中，决定帧率天花的往往是那几帧物理特别重的峰值，而不是平稳时期的表现。如果一个场景只有少量物理物体，优化前后的差距可能微乎其微，甚至因为线程调度变得更差。
建立好基线后，我一般会先做一整套“控制变量”测试：只改 Max Substeps、只改异步场景、只改碰撞体复杂度。每组测试后记录分项耗时，不要同时改多个变量，否则出了问题很难判断是哪一项引起的。
5.2 重点关注的几个指标
物理优化的核心指标不是某一个数字，而是一组组合。
物理总耗时是第一指标，但它需要拆解到子阶段。比如碰撞检测占了 60%，那就没必要花太多时间研究约束求解的迭代次数；反之如果求解占了 70%，则应该优先调整岛的并行度与迭代收敛性。
线程利用率同样关键。理想情况下，物理任务应该分散到多个工作线程上，而不是全部挤在一个线程里。线程利用率低通常意味着岛粒度不合理或存在全局锁串行点。还有一种情况是物理负载本身只有 2 毫秒，即使全部串行也不值得优化，这时应该把精力放到其他系统。
还有一个容易忽略的指标是“物理任务调度次数”。如果一帧里产生了成千上万个细小的物理任务，调度器本身的开销会变得不可忽视。观察 Insights 里的任务数量和平均任务时长，如果平均任务只有几十微秒，非常可能是任务切得太碎了。
5.3 从瓶颈数据反推优化方向
我之前跟进过某个战斗项目，物理耗时一直徘徊在 12 毫秒上下，最高冲到 20 毫秒。一开始团队怀疑是约束迭代不够，把迭代次数翻倍，结果耗时更高。后来打开 stat chaos 看分项，发现超过了 70% 的耗时在碰撞检测阶段，尤其是各种大型角色的 Mesh 碰撞体之间的窄相检测。
找到瓶颈后，大家把大量普通角色的碰撞体从 Mesh 简化成胶囊体，只保留必须精细的 Boss 用原始 Mesh，同时开启 CCD 但限定作用范围。物理耗时一下降到了 6 到 7 毫秒，而视觉表现几乎没有退化。这个例子说明，并行参数只是工具，瓶颈定位才是优化真正的起点。
如果你在项目里也遇到物理耗时高、线程吃不满，不要急着开异步场景或多加线程，先分清楚耗时到底花在哪，再决定是减碰撞复杂度、整理岛粒度、还是调迭代策略。方向错了，参数越调越糟。
6. 踩坑实录：并行物理的常见问题与排查思路
6.1 并行引入的“非确定性”问题
并行执行带来的一个典型副作用是结果不再每一次都完全一致。物理模拟依赖浮点计算，不同线程对计算顺序的微小重排，可能在后期造成可见的差异。典型表现是：两次运行相同场景，某个碎块落地的位置稍有偏差。
对于单机玩法来说，这种差异通常无伤大雅；但做联机同步、回放系统或者需要严格复现 Bug 的时候，这就是大事。UE5 提供了 Deterministic Mode，开启后引擎会尽可能约束并行调度顺序，以换取可复现的结果。代价是并行度可能下降，物理性能会部分牺牲。
我给这种项目的建议是：尽量在开发阶段保持对确定性的关注，不要到联机测试阶段才发现物理表现不一致。有些团队以为所有物理差异都来自网络同步，实际却是本地并行调度顺序不同导致的模拟分支发散，排查起来极其痛苦。
6.2 物理与游戏线程抢时间片导致卡顿
异步物理场景不是万能的。开启后物理模拟与游戏线程重叠进行，如果物理负载太高，它仍然会抢占系统资源，反而让游戏线程的响应变慢。最典型的表现是手柄输入响应偶尔延迟、镜头跟随有一点“粘滞感”，但帧数统计却看起来正常。
排查这种问题，我会先看 Insights 里物理任务与游戏线程的时间重叠度。如果两者在同一段时间内都在运行，并且物理任务持续超过 4 毫秒，那就说明异步并没有解决问题，只是把卡顿从“画面掉帧”变成了“手感变重”。这种时候更需要做减法：减少物体数量、减少子步、简化碰撞体，而不是继续加并行度。
另一个常见的坑是碰撞查询和物理模拟互相抢占。射线检测、形状扫描如果每帧大量执行，它们同样会占用物理场景的访问资源。在并行场景下，不当的查询可能让物理场景被迫等待查询完成，形成隐性的串行点。建议把大量查询集中到特定阶段，或者用缓存结果代替每帧全量检测。
6.3 小物件数量多反而更卡：调度开销的隐藏成本
有些项目里，场景中散落着成千上万个非常小的刚体碎块，它们几乎不互相碰撞，也几乎不产生有意义的约束。这种场景在物理模拟计算量上并不大，但每帧都要参与 BroadPhase 和岛管理，任务数量繁多，可能导致调度开销反而超过实际模拟开销。
我处理过类似的碎片场景，瓶颈不在求解，而在检索和任务分配。解决办法不是简单减少碎片数量，而是对碎片做分层管理：远处的碎片直接进入休眠状态，近处的碎片才参与完整模拟；或者用“合并为一个整体”的方式处理那些不参与交互的静态碎片，让物理引擎只对真正需要动态模拟的物体保持关注。
UE5 的物理休眠系统对此有帮助，但默认参数不一定适合所有项目。如果你发现场景里大量小刚体长期处于静止状态却仍在消耗 CPU，检查一下它们的休眠阈值，适当调高阈值，让更多小物体更快进入睡眠，往往能显著降低空转成本。
6.4 实战小结：一条适合多数项目的调优路线
踩过不少坑之后，我现在做 UE5 物理并行优化，基本按这样一条路线走：先开 stat chaos 与 Insights 建立基线，观察物理各阶段耗时占比；然后根据瓶颈所在做一次减法，比如简化碰撞体、优化休眠策略、限制子步数；之后才考虑开启异步物理场景，并观察线程利用率和输入延迟；最后，如果还需要追求确定性，才去考虑确定性模式和并行度的平衡。
这条路线不是银弹，但它能避免“一上来就开一堆并行开关”的常见误区。物理引擎做得再好，也要建立在正确的瓶颈判断上，并行优化本质上是在缩短物理时间预算，而不是帮你凭空增加算力。
我个人实际使用中还有一个体会：物理调优的很多结论是场景相关的，换一个玩法、换一批关卡设计，参数可能就要重新测。所以与其追求一套“万能配置”，不如把性能分析的习惯固化到研发流程里，每次物理相关改动都顺手跑一次 Profile，才能真正让并行优化从“玄学”变成日常工程的一部分。
