PhysX/Chaos引擎：游戏物理世界的两大施工天团

可视化演示

展示PhysX与Chaos物理引擎的刚体碰撞求解、破坏体系统与GPU并行加速对比。切换模式查看不同物理模拟，拖动滑块调节模拟参数。

引擎概览：两支队伍的身世

假设你要建一座虚拟都市，工地上有无数箱体、车辆、墙体需要“守规矩”——该落的落、该停的停、该碎的碎，这需要一支施工队来维护物理规则。第一支队伍叫 PhysX，是英伟达旗下的老牌精工队，出道二十余年，Unity、UE4 和无数自研引擎都找它干活，是游戏物理界公认的“老师傅”。第二支队伍叫 Chaos，是 Epic 自己养的新锐拆迁队，总部就设在 UE5 公司楼下，只服务一家客户。

老师傅和新锐队解决的是同一个问题：如何实时模拟物体运动。所谓“物理引擎”，就是负责碰撞、重力、约束等计算的软件模块。区别在于出身与取舍——PhysX 追求“到处都能用、稳定可靠”，Chaos 追求“与 UE5 深度咬合、把破坏场面做到极致”。PhysX 的前身来自 Ageia 公司（2008 年被 NVIDIA 收购），而 Epic 从 2018 年起在 UE4 中逐步用 Chaos 做试验性替代，到 UE5 时代正式转正为默认物理后端。2021 年《堡垒之夜》第二章第八赛季，整个岛屿在玩家眼前碎裂，正是 Chaos 破坏系统的成名战。

物理引擎并不跟渲染帧率走，而是按固定小步长推进，保证不同帧率下模拟结果一致：

选队伍之前先认人——PhysX 是“多面手老师傅”，Chaos 是“家门口的新锐”。接下来我们走进两者的“搬运调度组”（刚体求解器），看看它们怎么让箱子不乱飞。

刚体求解器：搬运调度组

施工队里最忙的是“搬运调度组”。工地上有大量刚体——不会形变的箱子、车身、墙体碎片。调度组的任务：让这些箱子在重力中下落、与地面接触、互相堆叠而不穿透、不抖动。游戏里几百个箱子叠罗汉的镜头，都要靠求解器在几毫秒内算完。

刚体运动分两步：积分（按速度更新位置）与约束求解（让接触点满足“不穿透、有摩擦”）。约束越多越难同时满足——比如一摞箱子每个接触点都要求不穿模，牵一发动全身。求解器于是用迭代法反复修正每个接触点的冲量。PhysX 使用 PGS（投影高斯-赛德尔）迭代冲量求解器，每个接触点按下面这个公式算出修正冲量，反复迭代 4~8 次收敛到“看起来自然”即可；Chaos 同样采用迭代式求解，但约束系统更通用，统一处理关节、碰撞与破坏后的新接触。

两个物体碰撞瞬间要施加的冲量大小，是物理引擎公式库里的“镇店之宝”：

简单说，调度组不追求“一次性算准”，而是快速多轮微调——像给歪斜的箱子堆轻轻推几下，直到大体稳住。老师傅和新锐队的推法不同，但目标是同一个：稳、快、不掉帧。

碰撞检测：防碰雷达

搬运箱子的吊车要装“防碰雷达”：先远远扫一圈，发现可能相撞的箱子，再仔细量一下是否真碰上了。物理引擎的碰撞检测也分两步走——粗检测和精检测。粗检测（Broadphase）把所有物体罩上一个长方体包围盒（AABB），用排序扫描或包围盒树快速剔除“离得老远”的组合；精检测（Narrowphase）对留下的候选对用 GJK（算凸体间距离）或 SAT（分离轴定理）精确判断，得到接触点、法线和穿透深度。

碰撞检测有一个经典坑：“隧道效应”。子弹、薄板这类又小又快的物体，一帧里移动的距离可能超过自身厚度，前后两帧都没有接触记录，直接穿墙。解决办法是连续碰撞检测（CCD）——沿运动路径细分子步；或者干脆限制单帧最大位移。工程上把这个约束写成：

所以工程上要么给子弹限速，要么给薄物体开 CCD“特权通道”，在移动路径上连续采样。两支施工队的防碰雷达原理相通，差别在加速结构和容差调优。

破坏体系统：拆迁爆破组

施工队里最吸引眼球的是“拆迁爆破组”：一面十几米长的墙要被炸成一地碎渣。如果真把墙切成几万块砖去实时模拟，任何 CPU 都扛不住。爆破组的思路是“先切成大块，坏到哪一步碎到哪一步”。Chaos 的破坏体系把 3D 网格转成“几何集合资产”（Geometry Collection），自动按 Voronoi 剖分或体素化切成碎块；碎块之间用“粘结”相连，只有受到足够冲击力、累计损伤超过阈值时，粘结才断开，生成真正独立的刚体碎片。

碎片还可以再“聚类”组合成大块——远处一撞掉大块，近处才细化到小块。配合 Fields 场（冲击波、爆炸力、风力）与 LOD 策略（远距离碎块合并或隐藏），大规模破坏才真正可行。《堡垒之夜》整岛碎裂，就是这种“分层破碎”的极致体现。碎块数量与切分尺寸的关系很直观：

爆破组的关键词是“分层”与“分级”——像摄影师先拍大景再拍特写，引擎先保证远处不卡，再为镜头前的碎块燃烧算力。

GPU 加速：并联吊车

一个工人搬一百个箱子很慢，派一百个工人同时搬就快得多。GPU 就是拥有上千个小工人的“并联吊车集群”。但调用这堆工人需要指挥开销：数据要先打包送过去，算完还要搬回来。PhysX 是游戏物理界最早拥抱 GPU 的引擎之一：基于 CUDA 的刚体加速把成千上万个粒子、碎片的模拟摊给上千个流处理器，特别适合大量、同构、相互影响较小的场景；缺点是需要 NVIDIA 显卡，且 CPU 与 GPU 之间的数据拷贝会吃掉一部分收益。

Chaos 的策略更“克制”：刚体物理以 CPU 多线程为主，GPU 计算优先投入到 Niagara 粒子系统。UE5 的大规模破坏更多靠 CPU 多线程加聪明的 LOD 实现。为什么不能无脑加工人？因为任何任务里总有“必须一个人接着一个人干”的串行环节，它决定了加速的极限，这就是 Amdahl 定律：

并联吊车不是越多越好：串行的“指挥调度”无法并行，显卡总线带宽也有限。GPU 加速是“特定场景的利器”，不是万能钥匙。

Chaos 与 UE5：深度绑定

新锐队最独特的地方：总部直接设在甲方公司里。Chaos 是 Epic 为 UE5 从零写的物理后端，从网格导入、碎裂到渲染回读全程走自家流程，不需要第三方翻译官。架构上，Chaos 采用解耦的任务图设计：粗检测、精检测、约束求解、断裂事件被拆成可以按依赖关系调度的任务，多核 CPU 可以并行推进。

它自定义了“中间层”加速结构（对应 PhysX 的 Broadphase），把 AABB 与 BVH 混合使用，并统一约束接口，让关节、碰撞、破坏后的新接触共用一套求解器。在引擎集成层面，Geometry Collection 可以直接吃 Houdini 的 Voronoi 碎裂结果；Fields 场让策划在编辑器里拖一个冲击波就能驱动成片碎片飞出。整个模拟管线可以按阶段拆开看：

对 Epic 而言，与其长期租别人的施工队，不如把队伍养在自己楼下——调度、协同、定制都握在自己手里。这也是 UE5 开发者默认选择 Chaos 的根本原因。

工程实践：开工决策

回到你的虚拟城市项目：选哪支队伍？不是名气大就好，要看活的性质。要跨引擎、要对接 NVIDIA 生态（Isaac 机器人仿真、Omniverse），选 PhysX；只做 UE5、要大场面破坏，直接选 Chaos。无论选谁，开工前必须算“性能预算”：物理模拟通常占帧预算的 10%~20%。以 60fps 为例，一帧 16.67ms，物理只有 2~3ms 可花，超出预算的后果是掉帧、输入延迟和玩家投诉。

调试工具方面，PhysX 配 PVD（PhysX Visual Debugger）可视化查看碰撞体；Chaos 则用 UE5 内建可视化调试，直接显示碰撞形状、约束与应力。跨平台时，移动端应减少碎块数量、降低迭代次数；PC/主机可以更放开。预算公式很朴素：

工程选型很像装修选队伍：看口碑、看项目、看预算，最后还要看师傅会不会用。理解引擎差异的工程师，才能在物理世界里既做出漂亮场面，又不让帧率翻车。

AI 应用场景

Python 演示

# -*- coding: utf-8 -*-"""2D 刚体脉冲求解与墙体碎裂演示：对应 PhysX/Chaos 的刚体求解与破坏体系统""" GRAVITY = 9.8RESTITUTION = 0.35DT = 0.02  class Brick:    def __init__(self, x, y, size=36):        self.x = x        self.y = y        self.size = size        self.mass = 1.0        self.vx = 0.0        self.vy = 0.0        self.alive = True        self.hit_count = 0     def apply_hit(self):        self.hit_count += 1        if self.hit_count >= 2:            self.alive = False  class Projectile:    def __init__(self, x, y, r=14):        self.x = x        self.y = y        self.r = r        self.mass = 3.0        self.vx = 42.0        self.vy = 0.0  def build_wall(cols=8, rows=4):    wall = []    for r in range(rows):        for c in range(cols):            wall.append(Brick(30 + c * 42, 90 + r * 38))    return wall  def solve_impulse(ball, brick):    """两圆近似碰撞：沿法向施加脉冲，对应碰撞脉冲公式"""    if not brick.alive:        return    dx = ball.x - brick.x    dy = ball.y - brick.y    dist = (dx * dx + dy * dy) ** 0.5    bound = ball.r + brick.size * 0.5    if dist >= bound or dist < 1e-9:        return    nx, ny = dx / dist, dy / dist    rel_n = (ball.vx - brick.vx) * nx + (ball.vy - brick.vy) * ny    if rel_n >= 0:        return    j = (1 + RESTITUTION) * (-rel_n) / (1.0 / ball.mass + 1.0 / brick.mass)    ball.vx += -j * nx / ball.mass    ball.vy += -j * ny / ball.mass    brick.vx += j * nx / brick.mass    brick.vy += j * ny / brick.mass    brick.apply_hit()  def simulate(wall, ball, steps=500):    for _ in range(steps):        ball.vy += GRAVITY * DT        ball.x += ball.vx * DT        ball.y += ball.vy * DT        if ball.y + ball.r >= 300:            ball.y = 300 - ball.r            ball.vy *= -0.4        for b in wall:            solve_impulse(ball, b)            if not b.alive:                b.vy += GRAVITY * DT                b.y += b.vy * DT                if b.y + b.size * 0.5 >= 300:                    b.y = 300 - b.size * 0.5                    b.vy = 0.0  def main():    wall = build_wall()    ball = Projectile(40, 200)    simulate(wall, ball)    alive = sum(1 for b in wall if b.alive)    print("剩余未破坏砖块: %d / %d" % (alive, len(wall)))  if __name__ == "__main__":    main()

1. class Brick:每块墙砖就是一个刚体，拥有位置、速度、质量与存活状态。
2. def solve_impulse(ball, brick):碰撞脉冲求解器，对应正文中的接触冲量公式。
3. j = (1 + RESTITUTION) * (-rel_n) / (1.0 / ball.mass + 1.0 / brick.mass)直接实现脉冲公式：恢复系数缩放接近速度，再除以等效质量倒数之和。
4. brick.apply_hit()每次碰撞给砖块累计一次损伤，被打中两次就“断开粘结”成为碎片。
5. if b.y + b.size * 0.5 >= 300:简单地面碰撞，让碎片落地后停下，避免无限下落。

常见误区

面试题