UE5碰撞通道分层检测：一次真实项目中的“血的教训”与架构重生

引言：一个“简单”的需求，如何让我在深夜崩溃

那是去年秋天，我们工作室接了一个开放世界射击游戏的Demo。老板拍板，两周内要拿出一个可玩的原型。我作为资深技术TA（技术美术），自然扛起了Gameplay框架的大旗。需求文档上写着：“我们需要一种机制，让子弹、探测技能、摄像机物理碰撞，都能准确区分‘敌人’、‘环境’和‘玩家’。”听起来很简单，对吧？我当时嘴角一扬，心想：这不就是设几个碰撞预设（Collision Preset）嘛，蓝图拖拖拽拽，完事。

但现实给了我一个响亮的耳光。第一周周末，我们发现了诡异的Bug：狙击枪子弹穿墙、敌人AI看不到玩家（视线检测被玩家自己的胶囊体挡住）、还有角色翻越障碍物时，摄像机会钻到墙里。整个团队陷入绝望，我盯着Breakpoint看了四个小时，最后发现：问题全都出在碰撞通道（Collision Channel）的默认设置和项目级配置上。

这篇文章，就是那次项目实战的完整复盘。我会用第一人称，从需求分析、技术选型、踩坑、解决到最终交付，把UE5碰撞通道分层检测的底层原理、架构设计和实战技巧，掰开揉碎了讲给你听。如果你正在为自己的游戏做物理交互，希望你能少走我走过的弯路。

需求分析：把“感觉”翻译成“规则”

我们先别急着打开引擎。做任何系统，第一步永远是需求分析。这个Demo的核心需求有三个：

• 子弹碰撞：需要区分命中“敌人”（造成伤害）、“环境”（产生弹痕）和“玩家”（穿透或反弹）。
• AI感知：敌人的视线检测需要能穿透“环境”的一部分（比如草丛），但被“墙体”阻挡。
• 摄像机碰撞：摄像机不能穿墙，但可以穿过“玩家”和“敌人”的胶囊体。

这些需求本质上是想让不同系统（武器、AI、Camera）对同一组物理对象有不同的“碰撞响应”。而UE5的碰撞通道（Collision Channel）正是为此设计的。

我当时的第一反应是：直接用内置的通道，比如WorldStatic、Pawn、PhysicsBody。但很快发现，内置通道只有几个，且语义模糊。比如Pawn通道，它既包括敌人也包括玩家，这就无法区分“子弹打敌人”和“子弹打玩家”的不同响应。

因此，正确做法是自定义碰撞通道（Custom Collision Channel）。在项目设置（Project Settings）→碰撞（Collision）中，我们可以添加新的通道，例如：Enemy（敌人）、Player（玩家）、Environment（环境）。然后为每个通道设置默认的碰撞响应（比如Ignore、Overlap、Block）。

这里有个关键概念：碰撞响应是相互的。A对B的响应，取决于A所在对象的碰撞预设中，对B通道的设定，同时也受B的预设影响。具体规则是：当两个物体的通道发生碰撞时，如果任意一个设置是Ignore，则忽略；如果都是Block，则阻挡；如果一个是Overlap，一个是Block，则结果是Overlap（因为Overlap优先于Block？不对，实际上是如果任意一方是Overlap，且没有Block，则Overlap；但如果有Block，则Block优先？我们需要查阅文档）。实际上，UE5的规则是：如果两个实例中，任何一个对另一个的通道响应是Ignore，则忽略；否则，如果任意一个是Overlap，则Overlap；否则Block。但这有点绕，我们后面细说。

总之，我先自定义了三个通道：

然后为不同的Actor（如子弹、AI控制器、摄像机）设置不同的碰撞预设，指定它们对各个通道的响应。

听起来很完美，对吧？但问题就在这个“默认响应”上。我希望子弹对Enemy是Block（命中），对Player是Ignore（穿透），对Environment是Block（弹痕）。于是我在子弹的碰撞预设里，将Enemy设为Block，Player设为Ignore，Environment设为Block。然后我测试，发现子弹打敌人，敌人居然不掉血？因为子弹和敌人的胶囊体都是Pawn类型，但我们的通道是自定义的，需要确保敌人胶囊体的碰撞预设中，对子弹的通道（我设了一个Projectile通道）也设为Block，否则无法触发。这里就涉及到了“对象类型”和“通道”的区别。

对象类型是Actor自身的类型（如Pawn、PhysicsBody），而通道是用于检测的“频道”。碰撞预设就是定义这个Actor作为对象时，对其他通道的响应。所以，子弹的通道是Projectile，而敌人胶囊体的预设中，需要设置对Projectile通道的响应。如果敌人胶囊体的预设中，对Projectile是Block，那么两者才能碰撞。否则，即使子弹对Enemy是Block，但敌人的对象类型是Pawn，子弹的通道是Projectile，而敌人胶囊体对Projectile的响应是Ignore，那么就会忽略。

这就是第一个坑：你必须在两个对象的碰撞预设中，都正确地设置对方通道的响应。这个“相互性”是碰撞检测的底层规则，很容易被忽略。

第一轮踩坑：默认通道的“陷阱”与“全Block”的灾难

我最初图省事，直接用内置的Pawn通道，把敌人都设为Pawn，玩家也是Pawn。结果就是：子弹打玩家和打敌人一样，都会触发伤害，因为响应一样。AI视线检测，被玩家的胶囊体挡住，因为两者都是Block。摄像机也被玩家的头挡住，穿不过去。

这就是“全Block”的灾难：所有东西都互相碰撞，物理世界变成了“钢铁丛林”。

我当时还犯了一个错误：把环境（Environment）设为WorldStatic，但这默认是Block一切。这没问题，但问题是，我想让AI的视线能穿透草丛，但被墙壁挡住。如果环境全是WorldStatic，那么草丛也是WorldStatic，就会阻挡视线。所以我需要把草丛设置为另一个通道，或者使用“忽略/重叠”响应。

于是，我决定自定义通道，并且为不同的系统定义“查询通道”（Trace Channel）。在UE5中，碰撞通道分为两种：对象通道（Object Channel）和追踪通道（Trace Channel）。对象通道用于物理碰撞（如阻挡），追踪通道用于射线检测（如LineTrace）。我们可以在项目设置中创建自定义追踪通道，比如Visibility、Camera、Weapon等。

这样做的好处是：我们可以针对不同系统设置不同的碰撞过滤。例如，AI视线检测使用Visibility通道，它只对世界静态几何体（如墙）Block，对草丛（设置为Ignore）就穿透。摄像机使用Camera通道，它只对EnvBlock，对PlayerIgnore。

所以，正确的架构应该是：

• 对象通道：Enemy、Player、Environment，用于物理碰撞（子弹触碰）。
• 追踪通道：Visibility（视线）、Camera（摄像机）、Bullet（子弹射线）等，用于各类射线检测。

在设置碰撞预设时，我们为每个Actor（如敌人胶囊体）设置：

• 对象类型（Object Type）为Enemy。
• 对所有对象通道的响应：如对Environment是Block，对Player是Block（敌人和玩家碰撞）等。
• 对所有追踪通道的响应：如对Visibility是Block（敌人阻挡视线），对Camera是Ignore（摄像机可穿过敌人）等。

这样，不同系统各取所需。但是，这又引入了一个新问题：如何管理这么多预设？

在UE5中，我们可以在碰撞预设（Collision Profile）中保存这些设置，然后给每个Actor类指定预设。但请注意，预设是针对组件（如胶囊体）的，不是针对Actor类的。所以你需要确保所有敌人角色的胶囊体都使用同一个预设，这可以通过在蓝图或C++中设置默认值来完成。

当时我是在每个敌人的角色蓝图中，手动设置胶囊体的碰撞预设，这导致了后续的维护噩梦。这是第二个坑：没有建立一个统一的碰撞预设管理策略。

技术选型：C++还是蓝图？我们选择了“混合双打”

在解决这个问题的过程中，我意识到，依赖蓝图手动设置每个组件的碰撞预设，既易错又低效。于是我们决定，用C++编写一个基类角色（BaseCharacter），在构造函数中统一设置碰撞预设。这样所有敌人和玩家都继承这个基类，碰撞配置就一劳永逸了。

对于子弹，我们也用C++生成一个基类Actor，在生成时设置碰撞预设，并处理碰撞事件。

此外，对于AI的视线检测，我们使用异步线追踪（Async Line Trace），并在C++中直接指定追踪通道（Visibility），而不用蓝图节点，以提升性能。

C++实现：基类角色碰撞配置

// MyCharacter.h
UCLASS()
class AMyCharacter : public ACharacter {
    GENERATED_BODY()
public:
    AMyCharacter();
};

// MyCharacter.cpp
AMyCharacter::AMyCharacter() {
    // 设置胶囊体碰撞
    UCapsuleComponent* Capsule = GetCapsuleComponent();
    Capsule->SetCollisionProfileName(TEXT("Character")); // 自定义一个名为Character的预设

    // 或者更精细地设置：
    Capsule->SetCollisionObjectType(ECollisionChannel::ECC_Pawn); // 对象类型设为Pawn
    Capsule->SetCollisionResponseToAllChannels(ECR_Ignore); // 先全部忽略
    Capsule->SetCollisionResponseToChannel(ECC_WorldStatic, ECR_Block); // 对世界静态几何体阻挡
    Capsule->SetCollisionResponseToChannel(ECC_Pawn, ECR_Block); // 对其它Pawn阻挡
    Capsule->SetCollisionResponseToChannel(ECC_Visibility, ECR_Block); // 阻挡视线检测
    Capsule->SetCollisionResponseToChannel(CameraChannel, ECR_Ignore); // 不阻挡摄像机
}

注意，这里我们使用了自定义通道CameraChannel，需要在项目设置中定义。

这样，所有继承自AMyCharacter的敌人和玩家，都自动拥有了正确的碰撞配置。而敌人和玩家的区别，可以通过在子类中调整对象类型，或者使用Tag来区分。

子弹碰撞处理：从Overlap到Block

对于子弹，我们使用一个SphereComponent作为碰撞体。在Bullet构造函数中，设置碰撞预设，并绑定OnComponentBeginOverlap事件（如果使用Overlap）或通过射线检测（如果使用LineTrace）。

通常，高速子弹推荐使用射线检测（LineTrace）来避免隧穿效应（tunneling），而不是依靠物理碰撞。我们最终采用的是：子弹飞行时，每帧从上一帧位置到当前位置做一次射线检测，然后根据命中对象的通道来判断响应。这样可以精准控制，并规避物理精度问题。

void ABullet::Tick(float DeltaTime) {
    FVector Start = GetActorLocation();
    FVector End = Start + GetVelocity() * DeltaTime;
    FHitResult Hit;
    FCollisionQueryParams Params;
    Params.bTraceComplex = true;
    Params.AddIgnoredActor(this);
    if (GetWorld()->LineTraceSingleByChannel(Hit, Start, End, BulletChannel, Params)) {
        // 处理命中
        HandleHit(Hit);
    }
    SetActorLocation(End);
}

其中BulletChannel是我们定义的一个追踪通道（例如ECC_GameTraceChannel3）。在这里，我们通过通道来过滤，只有对Bullet通道有Block响应的对象才会被命中。这样，子弹对Env、Enemy是Block（命中），对Player是Ignore（穿透）。

这个架构非常清晰。我们在项目设置中，定义了以下通道（以C++枚举为例）：

但这里有一个问题：对象通道和追踪通道是分开的，但碰撞预设中，你无法把“子弹”设置为一个对象类型，因为子弹是动态生成的，每次生成时我们手动设置它的碰撞响应。这就是“混合”方案。

深入原理：碰撞查询与过滤的底层机制

可能有些读者会问：为什么我们要区分对象通道和追踪通道？它们底层有什么不同？

在UE5中，物理引擎（PhysX或Chaos）进行碰撞检测时，会为每个Actor生成一个碰撞代理（Collision Proxy），其中包含它的对象类型和碰撞响应表。当进行射线检测（LineTrace）时，引擎会沿着射线遍历所有与包围体相交的代理，并检查“射线通道”与“对象类型”的响应矩阵，来决定是否命中。

具体来说，每个碰撞组件包含：

• ObjectType：这是一个Byte，表示对象的类型，如Pawn、WorldStatic。
• CollisionResponses：这是一个TEnumAsByte的数组，长度为ECollisionChannel::ECC_MAX，表示对该通道的响应（Ignore/Overlap/Block）。

对于追踪通道（如Visibility），它并不是一个实际的对象类型，而是查询时指定的一个通道。射线检测函数（如LineTraceSingleByChannel）会传入一个通道参数（如ECC_Visibility），然后引擎会检查每个碰撞代理对ECC_Visibility的响应，如果是Block或Overlap（根据ObjectType不同）就会命中。实际上，对于追踪检测，只有在组件对指定通道的响应是“Block”时才会被命中（Overlap不会被Hit）。

所以，我们可以为每个Actor组件设置“对Visibility的响应为Block”，这样它就会阻挡视线检测。同样的，设置“对Camera的响应为Ignore”，它就不会阻挡摄像机。

技巧：在C++中，我们可以用SetCollisionResponseToChannel，或者直接在构造函数中调用SetCollisionProfileName来加载一个配置好的碰撞预设。使用预设（Profile）有好处：可以在编辑器里调整而无需重编译代码，方便策划调试。

另一个底层概念是碰撞过滤分组（Collision Filter Groups），这是Chaos引擎特有的高级功能，它允许我们按组进行更细粒度的过滤。但通常我们不需要用到那么深层。

我们遇到的另一个坑是：当在蓝图中修改碰撞预设后，有时候不会生效，因为缓存（CDO）没有更新。我们必须在修改后点击“Apply”并重新加载关卡。或者使用“构建场景”来更新物理场景。

第二轮踩坑：默认响应与“非玩家”的意外阻挡

经过第一轮的改造，我们的子弹和视线检测都正常了。但出现了一个新问题：敌人的视线检测，居然被其他敌人挡住了。A敌人的视线，被B敌人的胶囊体阻挡，导致A看不到玩家，实际上A的视线应该穿过B（毕竟是友军）。

这个问题在于，敌人的胶囊体对Visibility通道的响应是Block（为了阻挡玩家的视线），但对AI视线检测来说，不应该阻挡自己人。解决办法有很多：

• 在AI视线检测时，使用不同的追踪通道，比如AIVision，并且设置敌人对AIVision是Ignore，而对Visibility是Block。
• 或者在射线检测时，添加忽略名单（Ignore List），把其他敌方角色忽略掉。

我们选择了前者，因为更灵活。于是我们增加了新的追踪通道AIVision，并调整了碰撞预设：所有角色对AIVision的响应为Ignore，对Visibility为Block。这样，AI视线检测只被环境阻挡，而不会被角色（包括敌人和玩家）阻挡。但这样也会导致AI看不到玩家，因为玩家对AIVision也是Ignore。所以我们需要让AI对玩家的AIVision通道是Block，而对敌人是Ignore。这又回到“对象类型”的区分上。

最终，我们决定在AI视线检测时，只检测环境（WorldStatic和Environment通道）和玩家（Player通道），忽略其他Pawn（包括敌人）。具体实现是，在射线检测时，使用自定义的过滤，通过参数设置忽略其他敌人。

FCollisionQueryParams QueryParams;
QueryParams.AddIgnoredActors(AllFriends); // 传入所有友军Actor数组

这样，检测时就会忽略这些Actor。这比增加通道更高效，因为通道改动会影响全局，而忽略名单只在特定查询中有效。

这个案例告诉我们：碰撞通道是全局的，而查询参数是局部的。我们要根据需求，合理使用两者。

解决与重构：建立“碰撞通道矩阵”

经过反复打磨，我们最终建立了一个“碰撞通道矩阵”表格，在项目早期就确定下来，作为团队规范。这个矩阵每一行是一个对象类型，每一列是一个通道，交叉处是响应（Ignore/Overlap/Block）。

注意，摄像机通道对角色是Ignore，所以摄像机可以穿过角色，但被环境阻挡。子弹对玩家是Ignore，所以穿过玩家，但对敌人是Block，命中。

同时，我们为不同系统设计了不同的追踪通道，并明确了它们的使用场景：

• Visibility：用于AI视线、玩家瞄准等，应只被环境阻挡（静态几何体），但也可以被角色阻挡（取决于设计）。
• Camera：用于摄像机，只被环境阻挡，忽略角色。
• Bullet：用于子弹射线，被环境、敌人阻挡，忽略玩家。

为了便于维护，我们在C++中定义了常量，并在项目设置中配置好。最重要的一课是：碰撞配置应该由代码或数据驱动，而不是每个蓝图手工设置。

这次重构后，我们封版，再也没出现过碰撞相关的Bug。最终，Demo按时交付，并且性能良好（我们使用了异步物理检测，避免阻塞游戏线程）。

实战总结与经验教训

回顾这个项目，我从“碰撞通道”这个看似简单的功能中，学到了很多：

1. 需求驱动设计：先列出所有系统的碰撞需求，再设计通道，而不是先设通道再改需求。
2. 理清对象与通道：对象类型是“你是谁”，通道是“你算什么”，响应是“你对我怎样”。三者要分开思考。
3. 避免“全Block”：千万不要把所有东西都设为Block，那会导致性能下降和逻辑混乱。
4. 使用追踪通道：对于射线检测，尽量使用专门的追踪通道，而不是复用对象通道。
5. 代码控制配置：在构造函数中设置碰撞配置，确保一致性，并且方便版本控制。
6. 善用忽略名单：在查询时，用局部参数忽略不需要碰撞的Actor，而不是全局修改通道响应。

最后，我想说，碰撞通道是UE5 Gameplay框架的基石之一，理解它的底层逻辑，能让你在设计复杂交互时游刃有余。希望这篇“血的教训”能帮你少踩一些坑，把时间花在更有趣的游戏玩法上。

技巧：如果你在调试碰撞问题，可以在运行时打开“碰撞可视化”（Pause键菜单中的Collision可视化），或者使用“显示碰撞”命令（show collision），快速查看每个对象的碰撞形状和响应情况。

另外，推荐使用“碰撞分析工具”（Collision Analyzer），它可以记录每次碰撞请求，帮助你精确定位问题。

关于火星人教育

就像我们在这个项目中不断调试、优化碰撞配置一样，学习UE5也需要系统化的训练和项目实战。火星人教育，创办24年来专注数字艺术与AIGC实战职业技能培训，开设课程包括：AI漫剧创作、AIGC视觉设计、UE5游戏特效、室内全屋定制、MAYA三维动画、C4D动态设计、工业设计、NUKE影视后期、摄影摄像实训。我们在北京、深圳双校区开设线下面授班，面向美术生、在校大学生及意向转行的职场人群，以项目化实训教学，夯实专业技能，助力就业与职业提升。如果你也对UE5开发或游戏特效感兴趣，欢迎咨询我们的课程顾问，电话：010-65918670。希望下一个项目，你能少踩一些坑，早点交付。