PhysX 3.4高级碰撞检测实战：从broadphase到CCD的全栈解析

做物理模拟项目的人都知道，碰撞检测在物理引擎里永远是“又核心又不起眼”的模块。绝大多数人用PhysX的默认碰撞配置能跑通demo，但一到真项目——角色被高速物体击穿、碰撞回调顺序错乱、过滤规则和触发器打架、性能莫名飙高——才发现文档里的“Advanced Collision Detection”这一章才是真正拉开水平和踩坑数量的分水岭。

本文围绕PhysX 3.4文档第8章“高级碰撞检测”展开，把我实际项目中反复验证过的核心机制、参数选择、工程化写法、以及文档里没写明的坑一次性盘清楚。内容适合三类人：一是刚接触PhysX、想系统搞懂碰撞系统的初学者，二是已经能跑物理但经常被穿透、漏检、回调诡异折磨的开发者，三是准备做物理调优、需要从碰撞层面压性能的人。读完你至少能回答这几个问题：SAP和MBP怎么选、filter shader到底要不要自己写、raycast/sweep/overlap在什么场景下用、CCD是不是开得越多越好、trigger回调为什么经常丢状态。

1. 先理解碰撞检测的两级管线：Broadphase与Narrowphase

物理引擎的碰撞检测从来不是“检测一下两个物体是否相交”这么简单。引擎内部为了让性能可控，把整个碰撞检测过程拆成了两级：broadphase（粗筛）和narrowphase（细判）。这两级的思路和生活里找人很像——先在一个城市里圈定几个人可能在的区域，再挨个敲门确认。

PhysX 3.4里的broadphase主要负责回答“哪两个actor可能相交”。它不会精确计算接触点，而是用包围体（通常是与坐标轴对齐的AABB）做快速重叠判断。这一步筛出的候选对会被丢给narrowphase，narrowphase才精确计算接触点、法线、穿透深度，并生成contact管理后续的约束求解。

理解这两级最大的意义在于：很多性能问题和bug，根源根本不在narrowphase，而在broadphase把太多无关物体对筛进来了。比如一个开放世界场景，角色站在A区域，B区域一整栋楼的物体都在broadphase的范围内，那narrowphase就会被迫去处理大量远距离的“伪候选对”，虽然它们会在细判后被剔除，但CPU已经浪费了。

1.1 为什么需要两级检测，而不是一杆子捅到底

如果所有物体都直接做精确的几何相交判断，复杂度会随着物体数量上升得非常难看。举个例子，场景里1000个物体，两两做一次narrowphase就是大约50万次精确计算，如果每个物体还是复杂的凸包或三角网格，这个量级一帧根本扛不住。

broadphase用简单的AABB重叠测试先把“绝对不可能相交”的组合过滤掉。AABB重叠只需要6次浮点比较，成本比精确碰撞检测低了好几个数量级。经粗筛后，真正进入narrowphase的对数会大幅减少。实际项目中，1000个动态物体的场景，一帧可能只有几十对候选对需要精确计算，压力完全不一样。

所以选物理引擎或者调碰撞性能时，别一上来就盯着接触点计算的算法，先看broadphase这层的过滤效率。PhysX 3.4提供SAP和MBP两种broadphase算法，选型会直接影响这层过滤的效率和稳定性。

1.2 Broadphase选型：SAP还是MBP

PhysX 3.4的PxBroadPhaseType提供了两个主流选项：eSAP和eMBP。

SAP（Sweep And Prune）的机制是把所有物体的AABB投影到坐标轴上，然后只比较投影区间的重叠情况。因为在场景中，物体通常会在某条轴上分布得比较均匀，SAP可以通过“先排序、再滑动扫描”的方式快速找出可能重叠的相邻物体。它对静态场景和中小规模的动态物体非常友好，内存占用小，速度稳定。PhysX默认也是用SAP，多数中小型项目不用改。

但SAP有一个软肋：如果大量动态物体在同一条轴上反复横跳，排序缓存会频繁失效，退化会比较明显。想象一下几百个物体全挤在同一块区域上下翻滚，AABB投影区间一直在变，SAP的增量排序优势就被抵消了。

MBP（Multi Box Pruning）的核心思路是把世界划分成多个区域，每个区域独立做pruning。它更像是“分而治之”的版本，把broadphase的空间复杂度拆到了多个局部空间里，适合大世界、超多动态物体、或者物体分布极不均匀的场景。MBP的代价是内存和管理开销更大，对静态物体的优化不如SAP激进。

实际选型经验：如果你的项目是室内场景、房间级关卡、或者动态物体总数在几百这个量级，用默认SAP足够，别折腾。如果做的是开放世界或大地图，场景横跨几个公里，动态角色和载具散布在各地，建议切到MBP并配合区域划分。切换方式是在创建scene时设置broadPhaseType为eMBP，同时还可以指定PxBroadPhaseRegion用于定义区域。

注意：MBP不是万能药。如果场景里动态物体数量本身不大，强行用MBP会白付额外的管理开销，性能反而可能变差。选型前先Profile，别凭感觉。

1.3 Narrowphase：真正产生“接触点”的地方

到了narrowphase阶段，PhysX会对候选对做精确的几何相交测试。不同的几何组合走不同的算法——凸体对凸体、凸体对三角网格、复合体对复合体，各有各的处理路径。

对开发者来说，narrowphase阶段最需要关心的其实是“为每个shape生成正确的接触信息”，以及“如何配置接触的标志位”。接触点的数量、位置、法线、穿透深度，都直接影响物理表现。如果一个角色站在地面上，接触点法线算歪了，角色就会轻微抖动；接触点数量太少，角色可能站不稳。

PhysX 3.4里，接触的生成和过滤是绑定在一起的。每一对可能发生碰撞的shape，都会过一遍filter shader（后面会细说），filter shader决定这一对到底要不要生成接触、要不要产生通知。narrowphase生成接触后，这些接触会进入求解器计算力反馈。

这里有个常见的认知误区：很多人以为增加碰撞形状的三角面数就能让碰撞更精确。其实narrowphase阶段对三角网格的处理反而会对某些几何体（比如高速运动的球体）出现边缘穿透问题，因为三角形网格内部没有厚度信息。这个在遇到隧道效应的时候会展开讲。

2. 高级碰撞检测的重点之一：碰撞过滤与分组

PhysX 3.4的碰撞过滤机制是文档第8章里分量最重的内容，也是实际项目中最容易写错的模块。很多开发者最初接触碰撞过滤时，都以为只要给Shape设置一个group和mask就能解决所有需求。实际上PhysX里真正的过滤逻辑是在filter shader中完成的，分组掩码只是快速预筛选的辅助工具。

2.1 filter shader决定一切的规则

PhysX的碰撞事件流大致是：broadphase产生候选对后，每一对进入narrowphase之前，引擎会调用一次filter shader。这个函数是全局的，通过scene创建时的PxSimulationFilterShader字段传入。

filter shader的输入包含两个物体的filterData、物体类型属性（例如是否是触发器），以及一个constantBlock。输出是PxFilterFlags和一对pairFlags。PxFilterFlags决定这对物体“接下来怎么办”，pairFlags则决定“如果能碰撞，要不要额外通知你”。

PxFilterFlags核心的几个取值：

• eKILL_PAIR：直接杀死这对碰撞。narrowphase根本不会执行，也不会有任何接触。适合两个物体永远不该发生物理交互的情况。
• eSUPPRESS_PAIR：抑制接触生成，但对某些逻辑仍可能保留通知。用途比较局限。
• eNOTIFY_TOUCH_FOUND / eNOTIFY_TOUCH_PERSISTS / eNOTIFY_TOUCH_LOST：控制接触事件的通知。这是实现“进入区域”“离开区域”等逻辑的关键。

pairFlags则影响contact的生成方式，比如是否调用求解器解析、是否生成接触点通知等。

实际工程里，大部分人不需要从零写这个函数，可以直接用PhysX提供的PxDefaultSimulationFilterShader，它基于物体的filterData里的group和mask做快速匹配。但默认实现只能处理“组与组之间是否碰撞”的规则，一旦你需要更细粒度的逻辑，比如“A组的这个特定物体不跟B组碰，但同一个组的其他物体可以碰”，就得自己写filter shader。

我建议的划分维度是：组间规则用默认过滤，个体例外用自定义filter shader，用constantBlock传自定义参数，而不是把所有逻辑硬塞到filterData的位标记里。

2.2 PxFilterData与分组掩码的搭配

PxFilterData是32位乘4的结构，四个uint32分别称为word0到word3。默认的碰撞匹配逻辑常用word0作为“自身所在的组”，word1作为“自己能碰撞的组掩码”。当word0与对方的word1做按位与，结果非0就允许碰撞。

这种一张掩码走天下的做法适合规则简单的项目。但要注意，PxFilterData的位宽度有限，最多也就32个自定义组。如果团队里策划定的标签超过32个，掩码方式直接崩。就算没超过32个，位的分配也需要全局统一，否则两个模块各自用不同语义的位，碰撞规则会变得极难排查。

另一个容易忽略的点是：setSimulationFilterData并不是只影响碰撞过滤。部分情况下，模拟过滤数据还会被一些内置系统读取，比如角色控制器或车辆系统有自己的过滤约定。你自定义的filter data如果和这些系统冲突，会导致角色或车辆无法正常执行碰撞逻辑。遇到这种情况，优先考虑用自定义filter shader，让默认的simulationFilterData保持原样。

2.3 过滤逻辑的性能纪律

filter shader在每一帧、每一对候选shape上都会被调用，这个函数必须保持足够快。如果filter shader里写了复杂逻辑，比如遍历场景里的其他物体数组、或者在里头做字符串匹配，性能会立刻爆炸。我曾经见过有人把某个“后果很严重的库调用”直接写在filter shader里，物理开销瞬间翻了几倍。

filter shader的设计纪律有几点：

• 只用整形位运算和常数判断，不要做浮点运算。
• 不要分配内存，不要调用外部系统函数。
• constantBlock里的数据在调用前已经准备好，只读使用。
• 如果需要更复杂的过滤条件，提前把上下文预计算好，通过constantBlock传入，或者用PxQueryFilterCallback做查询类过滤（raycast/sweep/overlap时用），而不是在shader里现场推演。

提示：filter shader的调用频率远高于你的直觉，它是对性能最敏感的物理回调之一。写之前多想想“这段逻辑能不能在仿真开始前就预计算成一张位掩码”。

3. 碰撞查询的三种武器：Raycast、Sweep、Overlap

PhysX的碰撞检测并不只发生在物理模拟内部。作为开发者，我们还经常要“主动地、单方面地”询问场景中某个方向是否有碰撞体，这时就需要用到碰撞查询。PhysX 3.4提供三种基础查询：Raycast、Sweep、Overlap。很多新手分不清三者的区别，总觉得都是“检测一下有没有挡住”，实际它们的语义完全不同。

3.1 三种查询的适用场景

Raycast是沿着一条射线找第一个被击中的物体，返回命中点、法线、距离、shape信息。它适合做枪械命中判定、视线遮挡、鼠标拾取、角色脚底探测。

Sweep是把某个形状沿一段路径推过去，检测形状在扫描过程中是否碰到障碍。它适合做角色移动前的防碰撞预检测、投掷物路径预测、物体放置合法性检查。

Overlap则是在某个位置放置一个形状，检测该位置是否存在任何重叠对象。它不做方向扫描，只是一个静态重叠判断，适合做范围感知、出生点是否被占据、区域检测。

三者的核心区别是维度：Raycast是“点/线”检测；Sweep是“形状沿轨迹扫过的体积”检测；Overlap是“某个瞬时空间区域”检测。

3.2 查询标志位与命中收集的细节

三种查询都通过PxScene的相应方法发起，都需要传一个PxQueryFilterCallback用于过滤查询结果，以及一组PxQueryFlag控制查询行为。

PxQueryFlag里有几个关键位：

• eSTATIC / eDYNAMIC：控制是否检测静态物体和动态物体。
• eANY_HIT：只要碰到任意一个障碍就提前返回。这对优化很有用，比如一个“是否被挡住”的判断根本不需要知道第一个命中在哪，用eANY_HIT能省掉大量narrowphase计算。
• ePREFILTER / ePOSTFILTER：控制是否在检测前和执行后调用过滤回调。

命中结果的收集方式也需要注意。最简单的是传入一个PxRaycastHit数组和最大命中数，但如果你一次raycast可能命中多个物体，比如一枪穿过多个玻璃，需要把最大命中数设置得足够大，并处理数组溢出的情况。

PhysX还支持TOUCH（所有触碰）和BLOCK（最近一个阻挡物）两种命中语义。BLOCK是默认的，通常返回距离最近的命中；TOUCH则收集所有命中。工程上常见的坑是：用BLOCK语义去做穿透检测，结果距离最近的阻挡物挡住了，你永远拿不到后面的障碍信息。反过来用TOUCH收集所有命中时，如果命中数组不够大，溢出命中会被静默丢弃。

3.3 批量查询与命中缓冲区的工程坑

性能敏感的项目里，逐帧做大量raycast或overlap查询时，应该使用批量接口。批量查询的优势不只是减少API调用次数，更重要的是允许你复用内存、降低单次查询的调度开销。

批量raycast需要你手动管理result缓冲区和hit缓冲区，而且索引关系可能比较绕。经验是：前期先跑通单次查询逻辑，再一次性改成批量，别一开始就上批量，出问题后排查成本会很高。

还有一个高频问题：在物理模拟回调里做查询。PhysX的仿真过程和查询过程共享场景数据，如果在simulate和fetchResults之间去执行查询，结果可能读到中间状态，轻则不准确，重则触发断言。推荐的模式是：用fetchResults拿完结果，在外部更新逻辑里做查询，等下一帧再调用simulate。

注意：不要把碰撞查询放在onContact、onTrigger这类仿真回调中，PhysX官方对这个用法是很明确的——查询接口和仿真更新不能重入。我在这上面吃过亏，程序稳定崩溃，查了半天才定位到是用例的问题。

4. 连续碰撞检测（CCD）与高速运动物体

几乎所有物理引擎使用者都会遇到同一个现象：子弹、高速飞行的碎片、高速移动的角色，在某帧之间直接穿过了墙。这就是经典“隧道效应”。要解决它，PhysX 3.4里提供的方案是连续碰撞检测（CCD）。

4.1 为什么高速物体会穿透

物理引擎的模拟是离散的：每一帧计算一次位置，然后检测这个离散时间点上的碰撞。如果物体在单帧内移动的距离大于障碍物厚度，一帧开始时物体还在墙的一侧，帧结束时已经到了另一侧，引擎就完全看不到穿透过程。这和摄像机子弹时间的原理正好相反——它不是快，而是“时间被切碎了”。

防止穿透有两种思路。一种是把固定时间步长调小，让每帧位移变小，但这样会整体增加物理消耗。另一种就是针对性地对高速物体启用CCD，让引擎额外处理“位移前后的扫掠体积”。

4.2 CCD怎么工作：motion clamping与speculative contacts

PhysX 3.4的CCD实现名称很技术：motion clamping和speculative contacts（推测性接触）。通俗理解就是，引擎在计算碰撞时，不是只看物体当前的位置，而是把这一帧的位移路径也纳入考虑，提前生成“可能在运动途中碰到的接触”。

运动夹持（motion clamping）的思路是：如果物体这一帧的位移已经超出了“安全步长”，就把它的运动限制在一个更短的距离内，分步执行碰撞检测，直到走完整个移动路径。它可以有效防止快速物体穿墙，代价是增加了子步的迭代次数。

推测性接触（speculative contacts）的思路更聪明：引擎在一帧开始时把物体沿速度方向“推”出一个包围体，找出可能与这个包围体相交的其他物体，提前生成接触约束。这样即使物体在这一帧内的中间状态没有实际接触，约束求解器也会提前施加力阻止穿透。这个方案性能比子步迭代好一些，但要求接触生成的物理形状足够精确。

4.3 CCD的开启方式和性能管理

PhysX 3.4中开启CCD的接口很简单：在创建actor时设置PxRigidBodyFlag::eENABLE_CCD标志位。但开完你会发现，如果场景里所有快速物体都开，物理性能可能下降得非常明显。CCD的成本不只是额外的子步计算，还包括对CCD形状做额外扫掠检测的开销。

实际操作建议：

• 只对必须防穿透的物体开CCD，比如子弹、抛射物、高速角色。
• 不要给面积特别大或复合度特别高的形状开启CCD，大形状的扫掠检测成本会成倍增加。
• 如果用了CCD还是偶尔穿透，优先检查形状本身的厚度和单帧移动距离，必要时把固定时间步长调小一档。
• 角色控制器自带专门的扫掠防穿透逻辑，不需要给角色的每个shape都开CCD，否则角色控制器和CCD两个系统互相作用，可能出现奇怪的弹跳。

提示：CCD不是开了就100%不穿透，它只是把穿透概率压低到可接受范围。极端高速运动下，仍然可能出现漏检，尤其是体积很小的物体。最稳妥的方案是配合固定时间步长和运动速度上限一起控制。

还有一个工程上很容易被忽略的地方：为了性能，PhysX内部对CCD的接触生成设置了可配置的缓冲大小。如果某个场景中CCD物体太多，生成了大量speculative contacts，内存和计算会明显上涨。检测这个问题的办法很简单：在profile工具里看CCD相关函数的耗时占比，如果超过你预期，就该限制CCD物体数量了。

5. 触发器与碰撞回调的工程细节

触发器（Trigger）是碰撞检测中很特殊的一类角色：它能感知重叠，却不产生物理阻挡。PhysX 3.4中通过PxShapeFlag::eTRIGGER_SHAPE将一个shape标记为触发器，之后这个shape只参与overlap检测，不会生成物理接触。适合做伤害区域、楼梯检测、搜集判定、任务区域。

5.1 Trigger的核心机制

触发器本身不会响应力，但它能触发一系列事件。你需要实现PxSimulationEventCallback中的onTrigger方法，接收PxTriggerPair数据。每一对数据里包含triggerShape、otherShape以及一对状态标志，比如eNOTIFY_TOUCH_FOUND和eNOTIFY_TOUCH_LOST。

触发器的过滤逻辑、过滤数据和普通碰撞体一致，同样经过filter shader。但有个区别：触发器和普通shape的配对过滤，要确保pairFlags里显式包含eNOTIFY_TOUCH_FOUND / eNOTIFY_TOUCH_LOST，否则即使触发了重叠，事件也不会上抛。这是非常常见的“触发器没反应”的原因。

触发器的另一个隐蔽特性是：它只对“需要通知”的配对有效。如果你的触发器要和动态物体产生交互，但这个动态物体被你自己的过滤规则排除了，触发器就完全感知不到。所以排查触发器问题时，第一件事是检查filter shader里有没有把这组配对kill掉。

5.2 事件回调的时序与线程安全

onContact和onTrigger的触发时机是在fetchResults阶段，此时物理仿真已经完成，但这些回调仍然运行在物理引擎的线程上。回调函数内不要执行任何可能阻塞的操作，也不要直接修改物理场景中尚未结束仿真的actor状态。

常见错误有几种：在onTrigger里直接销毁shape或actor；在onTrigger里调用simulate或查询接口；在onTrigger里加锁并等待其他线程释放。这些操作轻则造成物理表现异常，重则直接crash。更合理的做法是把onTrigger收到的状态记录到一个队列，在游戏逻辑的主循环中统一处理。

实际项目里，触发器的事件丢失问题也比比皆是。比如物体在单帧内完成“进入触发器并离开触发器”，如果引擎的broadphase没有连续追踪到这个短暂重叠，TOUCH_FOUND和TOUCH_LOST都可能漏发。解决思路是让触发器的shape比实际区域略大一点，或者用持久化接触信息辅助判断。

注意：onTrigger里拿到的PxTriggerPair指针只在回调函数执行期间有效，不要把指针存到别的地方后再访问。把需要的信息拷贝出来就好——位置、朝向、shape指针这些，但要小心后续shape可能已经被销毁。

6. 实战中的常见问题与排查速查表

到这一章，原理和配置思路基本都覆盖了。剩下的是把我在实际项目中反复遇到过的问题汇总一下，做成速查表，方便大家踩坑后快速定位。

6.1 高频碰撞问题记录

6.2 我踩过的几个坑和调试习惯

第一个坑是复合碰撞体（Compound Shape）的过滤数据。复合体内的每个shape有自己独立的filterData，如果不统一设置，可能出现同一个actor的不同部位分别与外部物体碰撞，触发不同的回调逻辑。我当时排查一个“同一堵墙，角色左边能过右边不能过”的诡异问题，最后发现是角色的两个胶囊shape设置了不同的过滤组。

第二个坑是缩放。PhysX 3.4的shape缩放是通过setLocalPose的scale参数实现的。很多人直接在actor上放大scale，却忘了内部碰撞检测对非均匀缩放的凸包处理并不理想。遇到碰撞抖动或接触点错乱时，先排查缩放是否均匀。

第三个坑是查询结果的坐标系。PhysX的raycast结果position和normal默认在world space，但如果你在做角色控制器这类存在局部空间计算的模块，忘了把结果转换到自己的坐标系，就会出现距离和方向都对，但位置就是偏移一截的怪现象。

关于调试习惯，我的经验是准备一个专门的“碰撞可视化”调试模式：把所有shape的filterData、是否触发器、是否开启CCD一次性打印出来，配合物理引擎自带的debug渲染线框，一眼就能看出问题。比对着配置手撸代码排查效率高得多。

提示：千万不要等到项目后期才统一设计碰撞过滤规则。越早把“谁和谁碰、谁和谁只重叠不碰撞、谁和谁根本不检测”的规则表定下来，后面联动角色、技能、AI时踩坑概率越小。物理系统是强耦合系统，改一个组的过滤规则，影响范围可能波及整个场景。

最后说点个人习惯。我做物理配置时，习惯把所有碰撞过滤规则集中在一个配置模块里管理，谁都不能直接在业务代码里set一个裸的过滤数据；所有shape的创建都走统一的工厂方法。这套约束刚开始显得繁琐，但项目到中后期，当几十个角色技能、载具、武器系统都在同一张物理场景里运行时，你会发现这套“繁琐”替你挡掉了大量因过滤规则混乱导致的诡异表现。高级碰撞检测的内容远不止API调用，它更考验的是对整个检测流程的理解和工程层面的纪律。