物理引擎里的碰撞检测，平时跑起来好像没什么存在感，但一到高速物体就原形毕露。我在一个互动Demo里做过一根高速飞行的箭矢，明明碰撞体都配置好了，结果箭矢直接从薄墙里穿过去，像幽灵一样。调试了两天才意识到，问题不在配置，而是固定步长的离散碰撞检测根本扛不住高速运动。后来重翻 PhysX 3.4 文档里的 Advanced Collision Detection 章节，才把这套机制真正理顺。这篇文章就把我基于那章文档的笔记、实际调参经验和踩过的坑整理出来，尤其是连续碰撞检测（CCD）、场景查询、接触偏移这类词到底是什么意思、怎么用，适合正在用 PhysX 3.4 做游戏或仿真，又被穿透问题折腾过的开发者。
1. 子弹为什么会穿墙：低速碰撞检测在高速场景下的失控
1.1 固定步长碰撞检测的局限
先说清楚一个基础概念：PhysX 默认的碰撞检测是离散的。物理引擎按固定时间步长推进模拟，在一个步长内，物体从位置 A 移动到位置 B，引擎只检查这个步长结束时刻的碰撞状态，而不关心中间过程。这在低速运动下没问题，因为物体在一个步长里移动的距离很小，碰撞基本都能被捕捉到。
但物体速度一旦提上来，情况就变了。比如一个厚度为 0.1 米的墙，物体每秒移动 20 米，固定步长是 1/60 秒，那么一个步长内物体移动约 0.33 米。这已经远大于墙体厚度，物体可能在步长开始时位于墙的左侧，步长结束时位于墙的右侧，两个时刻的离散检测都碰不到墙体，于是穿模发生。用个更直白的类比：你在黑暗里伸手电筒，每隔一秒开一次灯，一颗子弹恰好在这一秒内从你眼前飞过——你看不见它，因为它只存在于两次开灯之间。
这里的根本问题不是碰撞体配置错了，而是离散采样天然存在盲区。很多初学者第一反应是调小固定步长，从 1/60 调到 1/120 甚至 1/240，确实能缓解一部分穿透，但代价是物理模拟整体开销翻倍，CPU 根本吃不消，最后还是得回到引擎本身提供的解决方案上来。
1.2 一个真实的薄墙穿透演示
我当时复现问题用的场景很简单：一个半径 0.02 米的球体，以每秒 30 米的速度射向一面厚 0.05 米的静态墙体。固定步长 1/60 秒下，球体每步移动 0.5 米，是墙厚的 10 倍，穿透几乎是必然的。如果把速度降到每秒 2 米，每步移动约 0.033 米，小于墙体厚度，碰撞正常。
这个对比其实给出了一个核心判断标准：物体单步位移是否超过碰撞体最小尺寸。一旦超过，离散碰撞检测就会失灵。不少人还会遇到另一种翻车情况：物体速度不算特别高，但碰撞体本身很薄，比如一张纸片、一层地板，同样会因为单步位移超过自身厚度而穿透。所以判断是否该启用高级碰撞检测，不能只看速度，还要看碰撞体的尺寸。
PhysX 文档里把这类问题称为高速碰撞问题，并给出了两条解决路径：一是开启连续碰撞检测（CCD），二是使用物理子步进。第 8 章 Advanced Collision Detection 的核心内容，基本都围绕这两条路径展开。我后面会详细拆解 CCD 的几种实现方式和参数配置，因为这才是文档里最有价值也最容易被忽略的部分。
2. 三种CCD方案的取舍：线性扫掠、投机式与混合应用
2.1 经典扫掠式CCD怎么工作
PhysX 3.4 中最基础的 CCD 方案是线性扫掠（Linear Swept）。原理可以理解为：对开启 CCD 的物体，在每一步物理模拟里沿着运动方向生成一个“扫掠体”，也就是从起点到终点拉伸而成的体积，然后用这个扫掠体去和其他碰撞体做检测。扫掠体相当于把物体一路扫过的空间都覆盖住了，墙只要和这个体积相交，引擎就能算出碰撞发生的具体时间点（Time of Impact），并把物体停在最早接触位置。
这个方案的好处是直观、精度高，能解决绝大多数高速穿透问题。但它有一个明显的限制：扫掠基于“线性”运动假设。如果物体同时在做旋转，比如一个高速旋转的飞镖，或者碰撞体不是球体而是细长条，扫掠检测就未必准确，容易出现误差或漏检。另外，扫掠式 CCD 的开销明显高于普通碰撞检测，因为额外生成了扫掠体积并进行了多次窄相检测。
我在项目里的做法是：只给真正高速且需要精确碰撞的物体开启这一档。比如子弹、箭矢、快速移动的角色，这些物体数量很少，不会拖垮性能。至于场景里大量低速移动的道具，一概不开。
2.2 投机式CCD：另一种思路
PhysX 3.4 还提供了一种叫投机式 CCD（Speculative CCD）的方案，英文文档里叫 speculative contacts。它不生成扫掠体，而是提前预测物体可能接触到的其他物体，直接创建接触约束，让物体在没有真正碰到的前提下就开始回避碰撞。用个生活化的比喻：普通人是撞到墙才知道疼，投机式 CCD 是走过去之前就预测到可能要撞墙，提前减速。
这个方案的计算成本比线性扫掠低很多，尤其适合大量高速小物体共存的场景。它的缺点是接触精度不如扫掠式，可能出现“没碰到但被弹开”的错觉，或者接触点位置略有偏差。如果对碰撞精度要求极高，比如需要精确模拟一发子弹弹壳的反弹方向，投机式 CCD 可能给不出理想结果。
实际使用时，两种 CCD 并不冲突。PhysX 允许场景级别同时开启投机式 CCD 和扫掠式 CCD，也可以只开启其中一种，配合每个刚体单独设置 CCD 标志。我常用的组合是：场景级开启投机式 CCD 兜底，对少数需要精确时间点碰撞的关键物体再单独开启扫掠式 CCD。这样性能和精度能平衡得比较好。
2.3 3.4里的开关与参数：怎么选
PhysX 3.4 中，CCD 的开关分布在两个层级。第一层是场景级别，在 PxSceneDesc 里设置 flags，比如 PxSceneFlag::eENABLE_CCD 表示允许场景内的 CCD，eENABLE_SPECULATIVE_CCD 表示启用投机式 CCD，eENABLE_CCD_FOR_STATIC 表示让 CCD 对静态物体也生效。第二层是刚体级别，对具体的 PxRigidBody 调用 setRigidBodyFlag(PxRigidBodyFlag::eENABLE_CCD, true)，单个物体才会真正参与 CCD 计算。
这里有个容易踩的坑：场景级开启了 CCD，但刚体没设标志，CCD 不会生效；反过来也一样，刚体设了标志，但场景级没开启，同样不会生效。两个条件缺一不可。我最初调试时只开了场景级开关，想着全局生效，结果所有高速物体照样穿透，排查了好几个小时才发现刚体级标志没设置。
另外一个重要参数是 ccdMaxPasses，它控制 CCD 在物体重叠、接触边界复现等复杂情况下最多迭代多少次。默认值只有 1，意味着大多数情况下只做一次判断，如果出现多物体连续碰撞或者两个 CCD 物体互相高速接近，可能仍会有漏检。我在有快速团战场景的项目里把这个值调到 3 或 4，穿透率明显下降，但性能开销也在上涨。具体调多少，需要根据自己的场景物体密度和速度分布来权衡。
下面是我整理的一张对照表，方便在不同场景下快速选型：
| 场景特点 | 推荐方案 | 理由 |
|---|---|---|
| 少量高速物体（子弹、箭矢） | 刚体级扫掠式 CCD | 精度高，数量少，性能可控 |
| 大量高速小物体（弹片、碎片） | 投机式 CCD | 成本低，覆盖广，精度要求不苛刻 |
| 高速物体与静态薄墙 | 场景级开启 eENABLE_CCD_FOR_STATIC | 默认静态体不参与 CCD，不开会漏检 |
| 混合场景 | 投机式兜底 + 关键物体扫掠式 | 性能和精度折中，适合绝大多数项目 |
3. 手动sweep查询：把文档API变成你的调试放大镜
3.1 sweep查询的API使用与代码示例
PhysX 的 Advanced Collision Detection 章节除了自动的 CCD，还有个容易被低估的部分：场景查询（Scene Query），其中最有实战价值的就是 PxScene::sweep。sweep 允许你自己指定一个几何体、起点、方向和最大距离，沿路径做一次扫掠检测，返回最先命中的碰撞结果。它本质上是把“扫掠”这个能力以查询形式开放给你，不依赖物理模拟步进，可以在任意时刻做一次性检测。
我当时用这个 API 写了一个自定义的“预判系统”：在物体高速移动前，先用一个与物体同等大小的球体沿运动方向做 sweep，提前确认路径上是否有障碍物。这么做的好处是把碰撞逻辑从物理模拟中拆出来，完全由游戏逻辑控制。比如有些技能需要穿墙、有些子弹需要“擦边但不击中”，默认的 PhysX 碰撞很难表达，但用 sweep 查询就能非常灵活地实现。
一个简化版的 C++ 调用示例：
PxVec3 origin(0.0f, 0.0f, 0.0f); PxVec3 direction(1.0f, 0.0f, 0.0f); float maxDistance = 50.0f; PxSweepBuffer result; PxQueryFilterData filterData(PxQueryFilterData::allFlags); PxQueryFilterCallbackNoFilter filterCallback; bool hit = gScene->sweep( PxSphereGeometry(0.5f), PxTransform(origin), direction, maxDistance, result, PxHitFlag::ePOSITION | PxHitFlag::eNORMAL | PxHitFlag::eDISTANCE, filterData, &filterCallback ); if (hit) { PxVec3 hitPoint = result.block.position; float hitDistance = result.block.distance; // 在这里决定游戏逻辑如何处理这次碰撞 }这里有几个细节值得注意。第一个是 PxSweepBuffer，它在 3.4 中既用来接收命中结果，也用来做输出，调用前不需要初始化，调用后通过 result.block 访问命中的位置、法线、距离和表面信息。第二个是 filterData，它决定了这次查询会和哪些物体碰撞，如果设置不当，可能会把触发器（Trigger）也当成阻挡物，把热区检测误判成实际碰撞。
3.2 三类查询的适用场景对比
PhysX 场景查询家族里，除了 sweep，还有 raycast 和 overlap。raycast 是向一条射线方向查询最近命中，适合瞄准、视线检测；overlap 是检测指定几何体与哪些物体有重叠，适合范围判定、触发区域。sweep 则专注于“物体沿路径移动会不会碰到东西”，是三者中与碰撞检测关系最密切的。
| 查询类型 | 核心问题 | 典型场景 |
|---|---|---|
| raycast | 射线路径上有什么 | 瞄准判定、枪线检测、NPC 视线 |
| overlap | 当前和谁重叠 | 范围伤害、触发器、AI 感知 |
| sweep | 移动路径上会不会撞到 | 寻路避障、子弹预判、CCD 结果验证 |
这三者的共同点是都可以通过 filterData 自定义参与查询的对象和碰撞通道，这让它们非常适合做游戏逻辑层的碰撞决策，而不只是物理模拟层的被动反馈。很多开发者对这套 API 的认知停留在“调试工具”，其实把它用在玩法逻辑上才是文档中隐藏的高级玩法。
3.3 用sweep调试CCD穿透问题
接下来分享一个很实用的技巧：用 sweep 反向验证 CCD 是否正常工作。物理引擎的自动 CCD 是一个黑盒，你只知道最终有没有穿透，却不知道接触点计算得对不对。但你可以拿同一组参数手动执行一次 sweep，对比自动碰撞的结果。如果手动 sweep 明明检测到了墙体，自动碰撞却穿透了，那就能确认问题出在 CCD 配置或参数上，而不是几何体本身。
我在排查箭矢穿透问题时就是这么定位的：先对被穿透的墙体做 sweep，确认查询能命中；再检查箭矢刚体的 CCD 标志，发现场景级和刚体级确实都开了；最后把 ccdMaxPasses 从 1 提高到 3，穿透消失。整个过程大约十分钟，比盲目调整步长高效得多。所以遇到穿透问题，我建议先判断“能不能查到”，再判断“为什么没触发”，两步走能节省大量时间。
sweep 还有一类更高级的用法是配合自定义碰撞形状做渐进逼近：比如判断一个角色能否安全跳过一个台阶，可以先从当前位置向下 sweep 角色胶囊体，看接地距离；再向前 sweep，看路径上是否有障碍。物理模拟里的自动碰撞负责“当前时刻的状态”，而你自己的 sweep 查询负责“未来一段时间的预判”，两者结合就能让角色行为变得非常稳定。
4. 接触偏移、触发器与子步进：文档里容易被忽略的细节
4.1 contactOffset和restOffset对高速碰撞的影响
PhysX 的每个形状都有 contactOffset 和 restOffset 两个参数，听名字就让人以为是摆设，实际上它们对碰撞检测尤其是 CCD 的影响非常直接。contactOffset 是接触生成的距离阈值，两个物体之间的距离小于这个值时，引擎就开始生成接触点；restOffset 则是物体静止时希望保持的距离。
默认情况下 contactOffset 是 0.02 个单位。这个值在低速场景下无感，但高速物体每步移动 0.5 米时，0.02 的接触生成阈值基本等于没有，物体在接触刚生成时已经进入了墙内。把 contactOffset 适当调大，比如调到 0.1 或 0.2，物体就能在更远的距离开始生成接触，CCD 时也能更早发现潜在碰撞。代价是碰撞判断变得更“敏感”，可能出现物体还没真正碰到就感到“被空气挡住了”的情况。
restOffset 的坑则是另一个方向。如果 restOffset 设得太大，物体静止时和墙体会留出一条明显缝隙，视觉上像悬浮。我记得有个项目里角色站在地面上显得“脚底发虚”，排查到最后发现是 restOffset 被误设成了 0.05。高速物体穿透问题里其实很少直接涉及 restOffset，但它会干扰你对 CCD 是否生效的判断——明明碰撞成功，视觉效果却像没撞上。所以调 CCD 之前，先把这两个偏移量确认一遍。
4.2 触发器与查询过滤：CCD的漏网之鱼
PhysX 文档里触发器（Trigger）是个很有意思的存在。触发器本身不参与物理碰撞，只用于重叠检测，默认情况下它不会阻挡任何物体。但问题在于，当你启用了 CCD 或者使用自定义 sweep 查询时，过滤逻辑可能会把触发器意外地当成可碰撞对象或者反过来忽略掉。
我在一个项目里设置了一个大范围的触发器区域，用来检测子弹是否经过。自动 CCD 生效后，子弹能正常穿墙，但触发器区域却经常漏报，原因是触发器默认不参与扫掠式 CCD 的接触生成。要在手动 sweep 里检测到触发器，必须在 filterData 里设置 PxQueryFlag::eDYNAMIC | PxQueryFlag::eSTATIC 之外，还要特别留意 shapeFlag 的配置。这个细节在文档里只有一小段，却让不少开发者挠头。
建议的做法是：把游戏里所有需要“可感知但不可阻挡”的对象（比如弹道检测区域、NPC 感知范围）明确用触发器实现，并在所有手动查询的过滤器里独立处理触发器通道，不要复用阻挡碰撞的过滤条件。分开管理的代价是多写一点过滤代码，但能避免一堆隐蔽的逻辑 bug。
4.3 子步进：一个被低估的CCD替代方案
相比 CCD，PhysX 3.4 里的物理子步进（Substepping）讨论度低很多，但它其实是解决高频穿透的另一把钥匙。子步进的思路简单粗暴：把一次固定步长的物理模拟拆成若干个子步骤，在每个子步骤里只移动一小段距离，再进行碰撞检测。比如一个 1/60 秒的物理步长，分成 4 个子步，每个子步只移动约 1/4 的原距离，穿透概率大幅下降。
和 CCD 相比，子步进更“物理”，因为它没有线性扫掠的假设，旋转和复杂形状都能正常工作；缺点则是性能成倍上涨，相当于把物理模拟频率硬生生提高了几倍。如果场景里大量物体都在高速运动，CCD 的总成本可能超过子步进，但只有少数几个高速物体时，CCD 明显更划算。我的经验是：物体数量少但需要精确碰撞，用 CCD；物体数量多、整体速度都比较高且能接受性能开销，可以考虑子步进。两者可以并存，但在方案设计阶段就要想清楚，因为运行时切换会带来很多不可预期的问题。
5. 性能边界与调优：别让高级碰撞检测拖垮整个物理帧
5.1 成本从哪里来：broadphase、midphase、narrowphase
理解了高级碰撞检测的原理，再看性能问题就清晰多了。PhysX 的碰撞检测通常分为三个阶段：broadphase（粗筛）、midphase（中筛）、narrowphase（精判）。普通的离散碰撞在 narrowphase 阶段只需要在步长结束时计算一次接触，而 CCD 的扫掠式检测需要额外做扫掠体计算和多次 narrowphase 检测，成本自然更高。
投机式 CCD 虽然不生成扫掠体，但它需要预判接触，相当于提前做了一批本可以延后计算的接触创建工作。如果场景里一半物体都开了投机式 CCD，这部分开销会非常可观。我记得在某个项目里，把场景级投机式 CCD 打开后，物理线程的整体耗时上涨了约 30%，最后不得不筛选出真正需要它的物体。
所以高级碰撞检测的调优核心不是“怎么开”，而是“给谁开”。我的建议是：先确认解决方案里哪些物体是高速且重要的，比如玩家角色、远程攻击、关键交互物，再为它们单独开启；其余大量非关键物体一律保持离散碰撞。很多人一开始图方便，场景级全开，结果性能崩了才回来做减法，其实不如从第一天就按需分配。
5.2 一个实用调优流程和自查清单
当穿透问题出现时，我通常按下面这个顺序排查，可以快速缩小原因范围：
- 确认物体开启 CCD 的层级是否完整：场景级、刚体级、静态体相关选项都要检查。
- 用 sweep 手动查询确认路径上的碰撞对象是否存在、是否可被命中。
- 检查 contactOffset 是否过小、restOffset 是否有异常残留。
- 如果物体带有旋转，检查线性扫掠的适用性，必要时改用投机式或子步进。
- 检查 filter 和触发器通道，确保没有把阻挡对象排除了。
还有一个我反复踩过的坑：CCD 开启后，物体的碰撞材质如果设置的反弹系数（restitution）过高，扫描接触会非常不稳定，甚至出现物体被“快速弹飞”的瞬移现象。这时候优先把 CCD 物体的反弹系数调低，不能用普通碰撞的经验去套。高速碰撞和反弹是天然矛盾的一对，想同时获得精确的子弹反弹方向和稳定的 CCD，在 PhysX 3.4 里要花不少调参功夫。
5.3 可视化调试：开启碰撞形状显示
最后补充一个便宜又高效的调试手段：PhysX 自带可视化功能，可以把所有参与碰撞的形状实时显示出来。在 PxScene 里开启碰撞形状的可视化参数后，你能直接看到哪些物体用了什么碰撞体、目标对象在什么位置。对排查“碰撞体配置看起来在，实际却失效”这类问题非常有用。
我见过不少同事 debug 穿透问题时靠打日志、甚至肉眼盯着屏幕看运动轨迹，效率很低。其实只要打开可视化，一眼就能看出碰撞体大小是否合理、位置是否偏移、扫掠体有没有生成。高级碰撞检测本身是黑盒，但可视化把这个黑盒的边界画了出来，这对理解文档里抽象的“扫掠体”“接触偏移”概念也有很大帮助。调试工具结合文档知识，才算真正把这套高级碰撞检测用明白。
回到开头那个箭矢穿透问题，最终的解决方案是三层组合：箭矢刚体开启扫掠式 CCD，墙体所在的静态碰撞对象通过场景标志纳入 CCD 计算，同时把箭矢碰撞体的 contactOffset 从默认 0.02 提高到 0.1，覆盖单步位移的 20%。穿透彻底消失。这一套参数配下来，箭矢数量即使在同屏十几个的情况下，物理线程耗时也只增加了不到 5%。所以我的习惯是：先确保每个高速物体单独开启 CCD，再用场景级额外选项兜底静态碰撞，最后根据实测数据微调接触偏移和迭代次数。物理调优没有万能公式，按需求分层、按数据调整，才能既解决穿透又不牺牲性能。
