1. 为什么我要花两周时间啃 PhysX 和 Omniverse 的源码先说结论如果你只是拿 PhysX 当黑盒调 API那你永远搞不清楚为什么两个看起来一样的刚体场景一个稳如磐石另一个跑十分钟就炸开。我在一个数字孪生项目里被这个问题折磨了整整一周最后逼着自己把 PhysX 5.x 的源码拉下来通读了一遍顺带把 Omniverse 里物理相关的扩展模块也翻了个底朝天。这篇东西就是那两周的产物不是官方文档的翻译是我自己踩坑踩出来的理解。PhysX 是什么一句话NVIDIA 家的实时物理仿真 SDK负责算刚体、柔体、布料、粒子、车辆这些玩意儿在虚拟世界里怎么动。Omniverse 是什么是 NVIDIA 搭的一个基于 USDUniversal Scene Description的实时协作平台物理仿真在里面是核心能力之一底层跑的就是 PhysX。这两个东西的关系你可以理解成 Omniverse 是餐厅PhysX 是后厨那口锅——你在前台点菜拖拽场景、调参数真正决定菜好不好吃的是后厨怎么炒。这篇文章适合谁看三类人第一类是做机器人仿真、自动驾驶场景构建、工业数字孪生的工程师你们大概率已经在用 Isaac Sim 或者 Omniverse 了但遇到物理行为不符合预期时不知道怎么排查第二类是想从 MuJoCo、Bullet 迁移过来的想知道 PhysX 的架构到底和它们有什么本质区别第三类是纯粹对物理引擎底层实现感兴趣的技术人想看看工业级代码是怎么组织的。不管你是哪类我尽量把话说白复杂的数学推导我会跳过但关键的架构决策和源码里的设计意图我会掰开揉碎讲。需要提前说明的是PhysX 的完整源码在 GitHub 上以 BSD-3 协议开源Omniverse 的物理扩展部分比如omni.physx也有公开的接口和部分源码可查。我评测用的版本是 PhysX 5.3 和 Omniverse Kit 105 对应的物理扩展不同版本之间 API 有差异我会在关键地方标注。2. PhysX 架构全景从 SDK 分层到求解器内核2.1 三层架构到底分了什么PhysX 的代码结构乍一看很乱但如果你按用户接口层 → 场景管理层 → 底层求解器这个思路去切立刻就清晰了。最上面是PxPhysics、PxScene、PxRigidDynamic这些你天天调的类它们本质上是门面Facade真正干活的不在这里。中间层是Sc::Scene、Sc::BodyCore、Sc::ShapeCore这些负责场景图管理、对象生命周期、脏标记传播。最底下才是DyDynamics和SqScene Query这些求解器实现。为什么要这么分我一开始也觉得是多此一举直到我改了一个参数发现整个场景重建了才明白。门面层的对象是胖的带大量用户可见的属性和回调而Sc层的 Core 对象是瘦的只存求解器真正需要的数据。当你调用setMass()时门面层改的是自己的缓存然后通过脏标记通知Sc层Sc层再决定要不要同步到Dy层。这个设计的好处是如果你在一帧内改了十次质量只有最后一次会真正传到求解器前九次都是空操作。这在大型场景里能省下大量无效计算。注意PhysX 的脏标记系统不是万能的。有些属性比如改变 Shape 的几何类型会触发完整的重新创建而不是增量更新。我在一个场景里把 Box 换成 Convex Mesh结果整个 Actor 被重建之前绑定的关节全部失效。这个坑花了我半天才定位到。2.2 求解器的核心TGS 与 PGS 的取舍PhysX 4.0 之后默认用的是 TGSTemporal Gauss-Seidel求解器之前是 PGSProjected Gauss-Seidel。这两个的区别用大白话说PGS 是一步到位式地迭代求解约束TGS 是分步走式地把时间步再细分。TGS 的好处是收敛更快尤其是在高刚度约束比如一堆箱子堆叠场景下同样的迭代次数能得到更稳定的结果。源码里Dy::SolverCore这个类是整个求解器的心脏。它维护了一个ConstraintWriteBack数组和一个SolverBody数组每次solve()调用就是在这两个数组上做迭代。我实测下来TGS 在 4 个子步substep下的表现大致相当于 PGS 在 8 到 10 次迭代下的稳定性但 CPU 开销只有后者的六成左右。这个数据不是官方给的是我用PxScene::getSimulationStatistics()在同一个场景下跑出来的。但 TGS 不是没有代价。它的子步机制意味着每个子步都要重新计算碰撞检测的接触点如果你的场景里动态物体特别多碰撞检测的开销会线性增长。我在一个 2000 个刚体的场景里对比过TGS 开 4 子步比 PGS 开 8 迭代慢了大约 35%但稳定性提升明显——PGS 下已经散架的堆叠TGS 下还能保持。2.3 碰撞检测的 Broad Phase 与 Narrow PhasePhysX 的碰撞检测分两阶段这个大家都知道但源码里的实现细节决定了你的场景能跑多快。Broad Phase 用的是 SAPSweep and Prune的变种具体在Sq::BroadPhase里。它维护了一个沿三个轴排序的 AABB 列表每帧只更新移动过的物体然后做区间重叠测试。这个只更新移动物体的优化很关键——如果你的场景里大部分物体是静态的Broad Phase 的开销几乎可以忽略。Narrow Phase 才是真正吃 CPU 的地方。PhysX 用的是基于 SATSeparating Axis Theorem和 GJK 的混合方案具体在Sq::NarrowPhase和GuGeometry模块里。Box-Box 用 SATConvex-Convex 用 GJKEPAMesh-Mesh 用专门的 BVH 遍历。我翻源码时发现一个有意思的细节PhysX 对 Box 做了特殊优化因为 Box 是最常见的碰撞体它的 SAT 实现里硬编码了 15 个分离轴的测试顺序先测最可能分离的轴提前退出。这个优化让 Box-Box 的检测速度比通用 Convex-Convex 快了将近三倍。实操心得如果你的场景里能用 Box 就用 Box别为了好看换成 Convex Mesh。我见过一个项目把所有的货架都做成 Convex Mesh结果碰撞检测开销是 Box 版本的 4 倍多帧率直接掉了一半。3. Omniverse 物理扩展PhysX 在 USD 世界里的落地方式3.1 USD 场景描述与物理属性的绑定Omniverse 用 USD 来描述场景物理属性是通过PhysicsSchema这套 Schema 挂到 Prim 上的。比如一个刚体它的 USD 描述里会有PhysicsRigidBodyAPI、PhysicsCollisionAPI、PhysicsMassAPI这些。omni.physx扩展的工作就是把这些 USD 属性翻译成 PhysX 的PxRigidDynamic和PxShape。这个翻译过程不是一对一的。USD 是声明式的你可以在任意时刻改任意属性PhysX 是命令式的很多属性一旦创建就不能改。omni.physx在中间做了一层缓存和脏标记只有真正需要同步的时候才调用 PhysX 的 API。我在源码里看到PhysXScene这个类维护了一个_usdToPhysX的映射表每次 USD 有变化时它会对比新旧值只把差异部分推给 PhysX。这里有个坑USD 的PhysicsMassAPI里可以设mass也可以设density但 PhysX 的PxRigidBody只认质量。如果你同时设了两个omni.physx的行为是 density 优先mass 被忽略。这个逻辑在文档里没写是我读omni.physx的 Python 绑定源码时发现的。3.2 物理场景的更新循环Omniverse 的物理更新不是简单的scene-simulate()然后fetchResults()。它有一套自己的调度机制在omni.physx的PhysXScene::update()里。这个函数会做几件事首先处理 USD 的变更通知把新增的 Prim 转成 PhysX 对象把删除的 Prim 对应的 PhysX 对象销毁然后处理属性变更更新质量、速度、约束参数最后才调用 PhysX 的仿真接口。这个顺序很重要。如果你在 USD 里改了一个物体的质量然后立刻读它的速度你读到的可能是旧值因为变更还没同步到 PhysX。我在一个脚本里就犯过这个错改完质量马上算动量结果对不上。正确的做法是等一帧或者手动调用omni.physx.get_physx_interface().update()强制同步。注意Omniverse 的物理更新和渲染更新是解耦的。物理可以跑 60Hz渲染可以跑 30Hz中间通过插值来平滑。这个机制在omni.physx的PhysXScene::update()里通过substep参数控制。如果你发现物体运动有抖动先检查物理帧率和渲染帧率是不是匹配。3.3 与 Isaac Sim 的关系Isaac Sim 是 Omniverse 上专门做机器人仿真的应用它的物理部分完全基于omni.physx但加了很多机器人特有的扩展比如关节驱动、传感器仿真、抓取物理。源码里isaac.sim的物理扩展会覆盖一部分omni.physx的默认行为比如关节的求解器参数、摩擦模型的选择。我对比过 Isaac Sim 和原生 Omniverse 的物理表现同样的场景Isaac Sim 里的关节更硬因为它的默认关节刚度更高求解器迭代次数也更多。这个差异在isaac.sim的配置里可以调但如果你不知道这个默认值的存在从 Omniverse 迁移到 Isaac Sim 时会觉得怎么变了个引擎。4. 源码级实操从零搭建一个可调试的 PhysX 场景4.1 环境准备与编译我用的环境是 Ubuntu 22.04PhysX 5.3 源码从 GitHub 拉下来CMake 构建。这里有个坑PhysX 的 CMake 默认会编译所有平台的所有配置在 Linux 上会尝试编译 Windows 和 Mac 的代码导致一堆莫名其妙的错误。正确的做法是在 CMake 里指定PX_BUILDSNIPPETSON和PX_BUILDPVDRUNTIMEOFF只编译你需要的部分。编译命令大概是这样git clone https://github.com/NVIDIA-Omniverse/PhysX.git cd PhysX/physx ./generate_projects.sh linux cd compiler/linux-release make -j$(nproc)编译完成后你会得到libPhysXCore.so、libPhysXCommon.so这些库。但如果你想调试还需要把PX_DEBUG打开重新编译一遍 debug 版本。debug 版本会慢很多但能让你在 gdb 里看到完整的调用栈。实操心得PhysX 的 debug 版本会启用大量的断言检查有些断言在 release 下是关闭的。我遇到过一个场景在 release 下正常debug 下直接断言失败原因是我的 Shape 的几何数据有 NaN。这个 bug 在 release 下被静默忽略了但会导致求解器输出垃圾数据。所以如果你遇到物理行为诡异先切 debug 版本跑一遍。4.2 最小可运行场景的搭建一个最小的 PhysX 场景需要这些步骤创建PxFoundation、PxPhysics、PxCooking、PxScene然后往场景里加 Actor。我写了一个最简版本大概 50 行代码#include PxPhysicsAPI.h using namespace physx; int main() { PxDefaultAllocator allocator; PxDefaultErrorCallback errorCallback; PxFoundation* foundation PxCreateFoundation(PX_PHYSICS_VERSION, allocator, errorCallback); PxPhysics* physics PxCreatePhysics(PX_PHYSICS_VERSION, *foundation, PxTolerancesScale()); PxSceneDesc sceneDesc(physics-getTolerancesScale()); sceneDesc.gravity PxVec3(0.0f, -9.81f, 0.0f); sceneDesc.cpuDispatcher PxDefaultCpuDispatcherCreate(4); sceneDesc.filterShader PxDefaultSimulationFilterShader; PxScene* scene physics-createScene(sceneDesc); // 地面 PxRigidStatic* ground physics-createRigidStatic(PxTransform(PxVec3(0, 0, 0))); PxShape* groundShape physics-createShape(PxPlaneGeometry(), *physics-createMaterial(0.5f, 0.5f, 0.1f)); ground-attachShape(*groundShape); scene-addActor(*ground); // 动态盒子 PxRigidDynamic* box physics-createRigidDynamic(PxTransform(PxVec3(0, 5, 0))); PxShape* boxShape physics-createShape(PxBoxGeometry(0.5f, 0.5f, 0.5f), *physics-createMaterial(0.5f, 0.5f, 0.1f)); box-attachShape(*boxShape); PxRigidBodyExt::updateMassAndInertia(*box, 1.0f); scene-addActor(*box); // 仿真循环 for (int i 0; i 1000; i) { scene-simulate(1.0f / 60.0f); scene-fetchResults(true); PxTransform pose box-getGlobalPose(); printf(Frame %d: y %f\n, i, pose.p.y); } scene-release(); physics-release(); foundation-release(); return 0; }这段代码跑起来后你会看到盒子从 y5 自由落体大约 1 秒后落到地面。但如果你仔细看输出会发现盒子落地后 y 值不是精确的 0.5盒子半高而是 0.499 或者 0.501 左右。这是求解器的穿透容差contact offset导致的PhysX 默认允许一定程度的穿透避免抖动。这个容差在PxShape::setContactOffset()里可以调但调太小会导致接触不稳定调太大又会让物体看起来悬空。4.3 参数调优的量化方法PhysX 的参数很多但真正影响稳定性的就那么几个solverIterationCount、solverVelocityIterationCount、contactOffset、restOffset、bounceThreshold。我一般用二分法来调先设一个保守值比如迭代 8 次然后逐步降低直到出现可见的不稳定再回退一步。具体来说solverIterationCount控制位置约束的迭代次数solverVelocityIterationCount控制速度约束的迭代次数。前者影响穿透深度后者影响反弹和摩擦。我实测下来对于一般的堆叠场景位置迭代 4 次、速度迭代 1 次就够用了对于高刚度关节比如机械臂位置迭代要 8 次以上。contactOffset和restOffset的关系容易搞混。contactOffset是开始检测接触的距离restOffset是接触后保持的距离。PhysX 默认contactOffset是 0.02相对于物体尺寸restOffset是 0。如果你把restOffset设成负值物体会互相嵌入这在某些场景下有用比如模拟软接触但大多数时候应该保持 0。注意contactOffset不能小于restOffset否则 PhysX 会断言失败。我在一个项目里把contactOffset设成 0.001restOffset忘了改结果 debug 版本直接崩了。5. 常见问题与排查技巧实录5.1 物体抖动、穿透、爆炸的排查路径物理仿真出问题症状无非三种抖动、穿透、爆炸。我整理了一个排查表按优先级排序症状可能原因排查方法解决方案静止物体抖动接触容差太小打印contactOffset和restOffset增大contactOffset到 0.01~0.02高速物体穿透连续碰撞检测未开检查PxRigidBodyFlag::eENABLE_CCD开启 CCD或减小时间步堆叠物体爆炸迭代次数不足打印solverIterationCount增加到 8~16或开 TGS 子步关节连接处分离关节刚度太低检查关节的stiffness和damping提高刚度或增加求解器迭代整体场景漂移重力方向或尺度不对检查PxTolerancesScale确保尺度与场景匹配这个表是我从多次踩坑中总结的但实际情况往往更复杂。比如我遇到过一个场景物体既不抖也不穿但就是慢慢往一个方向漂。查了半天发现是PxTolerancesScale的length设成了 1.0而我的场景是以毫米为单位的导致求解器的容差判断全部错位。把length改成 0.001 后问题消失。5.2 Omniverse 特有的坑Omniverse 里的物理问题和原生 PhysX 不太一样因为多了一层 USD 的抽象。最常见的坑是改了属性没生效原因通常是 USD 的变更没有触发 PhysX 的同步。omni.physx有一个_needsUpdate标志只有这个标志为 true 时才会同步。如果你在 Python 里直接改 USD 属性这个标志可能不会自动置位。解决办法是手动调用omni.physx.get_physx_interface().update()或者用omni.usd.get_context().get_stage()的变更通知机制。我在一个脚本里用Usd.Attribute.Set()改质量然后立刻读速度结果读到的是旧值。后来改成用omni.physx提供的set_mass()接口问题就没了。另一个坑是物理场景不更新。Omniverse 的物理更新依赖于omni.physx的PhysXScene被正确注册到更新循环里。如果你在扩展里手动创建了PhysXScene但没注册它就不会自动更新。这个在omni.physx的IPhysxScene接口文档里有写但很容易忽略。5.3 性能瓶颈的定位方法PhysX 自带性能分析工具在PxScene::getSimulationStatistics()里可以拿到各个阶段的时间。我一般会打印这几个数据nbBroadPhaseAdds、nbBroadPhaseRemoves、nbDiscreteContactPairs、nbActiveConstraints。如果nbDiscreteContactPairs特别大比如超过 10 万说明 Narrow Phase 是瓶颈需要减少碰撞体数量或者用简化碰撞体。如果nbActiveConstraints大说明求解器是瓶颈需要减少约束数量或者降低迭代次数。Omniverse 里可以用omni.physx的 profiling 工具在Window Profiling里打开。它会显示物理更新的各个子阶段耗时包括 USD 同步、Broad Phase、Narrow Phase、求解器。我实测下来USD 同步在大型场景里能占到 20% 到 30% 的时间这个开销在原生 PhysX 里是没有的。实操心得如果你的 Omniverse 场景物理很慢先看 USD 同步的时间。如果这个时间很长说明你的场景里 Prim 太多或者变更太频繁。解决办法是合并 Prim或者用omni.physx的批量接口来减少变更通知的次数。6. 从源码看 PhysX 与 MuJoCo、Bullet 的本质差异6.1 求解器哲学的差异MuJoCo 的求解器是为最优控制设计的它的核心是软约束允许约束有一定的违反量通过代价函数来平衡。PhysX 的求解器是为实时游戏和仿真设计的它的核心是硬约束尽量满足约束但允许一定的穿透。这个哲学差异导致 MuJoCo 在接触丰富的场景下更稳定但计算量更大PhysX 在大量刚体的场景下更快但接触精度稍差。Bullet 的求解器介于两者之间它用的是 Sequential Impulse 方法和 PhysX 的 PGS 类似但实现细节不同。Bullet 的接触缓存机制比 PhysX 简单导致在复杂场景下稳定性不如 PhysX。我对比过同样的堆叠场景Bullet 在 100 个盒子时开始抖动PhysX 能撑到 300 个。6.2 源码组织方式的差异MuJoCo 的源码非常紧凑核心求解器在engine_core_smooth.c和engine_solver.c里总共几千行。PhysX 的源码庞大得多physx目录下有source、include、compiler等多个子目录核心求解器在source/physx/src和source/physx/solver里。Bullet 的源码在src/BulletDynamics和src/BulletCollision里结构比较清晰。从源码可读性来说MuJoCo 最好读因为它的代码量小逻辑集中。PhysX 最难读因为它的抽象层多而且有大量的模板和宏。Bullet 居中。但 PhysX 的代码质量最高注释详细命名规范而且有大量的单元测试。6.3 对开发者的实际影响如果你是从 MuJoCo 迁移到 PhysX最大的不适应是参数变多了。MuJoCo 的接触参数就那么几个PhysX 有一堆。但 PhysX 的默认值通常够用除非你的场景特别极端。如果你是从 Bullet 迁移到 PhysX最大的不适应是API 变复杂了但换来的是更好的稳定性和性能。我在一个机器人抓取项目里同时用了 MuJoCo 和 PhysXMuJoCo 的抓取更稳定但 PhysX 的渲染和场景管理更方便。最后的选择是用 MuJoCo 做控制算法的验证用 PhysX 做最终的仿真和可视化。这个组合在实际项目中很常见。7. 企业级源码尽调的关注点7.1 许可证与合规性PhysX 的许可证是 BSD-3这意味着你可以自由使用、修改、分发只要保留版权声明。但要注意PhysX 的某些部分可能依赖 NVIDIA 的专有库比如 GPU 加速的PxGpuDispatcher需要 CUDA。如果你要在商业产品里用 GPU 加速需要确认 CUDA 的许可证是否兼容。Omniverse 的许可证更复杂它的核心是免费的但某些扩展和企业功能需要订阅。omni.physx本身是免费的但如果你用了 Isaac Sim 的某些高级功能可能需要额外的许可证。我在尽调时会把所有依赖的许可证列出来逐个确认。7.2 代码质量与维护性PhysX 的代码质量在开源物理引擎里算顶级的。它的命名规范统一注释覆盖率高而且有完整的单元测试。我翻了一遍physx/source下的代码没发现明显的代码异味。但它的抽象层确实多新手读起来会晕。Omniverse 的物理扩展代码质量参差不齐omni.physx的核心部分写得不错但一些边缘扩展的代码比较随意。我在omni.physx的 Python 绑定里发现过几个拼写错误和未处理的异常虽然不影响功能但说明维护不够细致。7.3 社区与支持PhysX 的社区活跃度一般GitHub 上的 issue 响应速度不快但 NVIDIA 的开发者论坛比较活跃。Omniverse 的社区更活跃因为它是 NVIDIA 的重点产品有专门的开发者关系和文档团队。如果你遇到问题Omniverse 的论坛通常能更快得到回复。实操心得如果你要在企业项目里用 PhysX 或 Omniverse建议先做一个概念验证PoC把关键场景跑一遍确认性能和稳定性满足要求。我在一个项目里直接上了 Omniverse结果发现它的物理更新在大型场景下比预期慢后来不得不做了大量优化。如果先做 PoC这个坑可以提前发现。8. 我个人的一些零散经验源码读多了会发现PhysX 的很多设计决策是历史遗留和性能妥协的产物。比如它的PxScene为什么不是线程安全的因为加锁的开销在实时仿真里不可接受。为什么它的 API 这么啰嗦因为 C 的 ABI 兼容性要求。这些决策在文档里不会写但读源码时能感受到。Omniverse 的物理扩展还在快速迭代我评测的版本和半年前相比已经变了不少。如果你要基于它做长期项目建议锁定版本不要盲目追新。我在一个项目里用了最新的 Kit 版本结果发现物理 API 变了之前的代码全部要改。最后说一个调试技巧如果你怀疑物理行为不对先把场景简化到最小可复现的程度。我遇到过一个 bug在一个 500 个物体的场景里怎么都查不出来后来把场景删到只剩两个物体问题立刻暴露了——是一个 Shape 的几何数据有 NaN。这个技巧听起来简单但实际做的时候很多人舍不得删总觉得再查查就能找到。相信我删到最小问题会自己跳出来。