企业官网建设流程全解析

1. 项目概述：碰撞检测，游戏性能的隐形战场

在游戏开发里，碰撞检测是个既基础又核心的活儿。它决定了你的角色能不能在墙上撞得头破血流，子弹能不能精准命中目标，或者两个物体相遇时是穿模而过还是发生一次物理上可信的交互。听起来简单，对吧？但就是这个“基础”功能，往往是项目后期性能瓶颈的罪魁祸首。我见过太多项目，美术资源精雕细琢，玩法设计别出心裁，结果一跑起来，帧率在特定场景下断崖式下跌，一查Profile，CPU耗时的大头赫然是物理线程里的碰撞检测。尤其是在Unity和Unreal Engine这两大主流引擎里，它们提供了丰富的碰撞检测算法和组件，但如果你只是无脑地用默认设置，或者在不了解原理的情况下随意搭配，性能“翻车”几乎是必然的。

为什么碰撞检测这么“吃”性能？想象一下，在一个开放世界游戏里，有成百上千个物体在运动。每一帧，引擎都需要判断任意两个物体之间是否发生了接触或穿透。这是一个典型的O(n²)复杂度问题——如果对1000个物体进行两两检测，理论上的检测次数会接近50万次。显然，没有任何引擎会这么“笨”，它们都依赖一套精密的算法体系来大幅减少不必要的计算。这套体系的核心，就是宽相位和窄相位检测的分层策略。宽相位像是一个快速筛选器，用简单的几何体（如轴对齐包围盒AABB）快速找出“可能”发生碰撞的物体对，排除掉那些距离很远、根本不可能碰上的对象。然后，窄相位才会对这些候选对进行精确的、基于物体实际形状（如凸包、三角网格）的碰撞计算。

Unity和Unreal都内置实现了这套分层体系，但它们的实现方式、默认行为以及可供开发者调优的“旋钮”各有不同。选错算法，或者用错了地方，轻则浪费算力，重则直接导致游戏卡顿。今天，我就结合自己踩过的坑和项目优化的经验，来拆解一下在Unity和Unreal中，如何根据你的具体需求，选对碰撞检测算法，让性能真正“翻倍”。这里的“翻倍”不是夸张，在优化得当的情况下，将物理开销从每帧10ms降到5ms以下，是完全可能且常见的。

2. 核心需求解析：你的游戏到底需要什么样的碰撞？

在动手选择算法之前，我们必须先搞清楚自己的游戏对碰撞检测的核心需求。这直接决定了后续的技术选型。盲目追求“最精确”或“最高性能”都是片面的，关键是找到平衡点。

2.1 精度需求：要物理真实，还是游戏性优先？

这是第一个要问自己的问题。你的游戏是像《欧洲卡车模拟》那样需要高度拟真的物理交互，还是像《超级马里奥》那样，碰撞规则服务于跳跃手感而非真实物理？

• 高精度需求：适用于赛车游戏、模拟建造、基于物理的解谜游戏。你需要精确的接触点、穿透深度和法线信息，用于计算真实的弹力、摩擦力。这时，窄相位算法必须足够精确，通常需要用到连续碰撞检测来防止高速物体穿透，并且碰撞体的形状要尽可能贴合模型（使用凸包分解或三角网格）。
• 游戏性优先需求：绝大多数动作游戏、RPG、MOBA都属于此类。碰撞更像是一个“触发器”或“体积阻挡”。例如，角色的攻击范围是一个胶囊体，敌人的受击判定是另一个胶囊体。只要它们相交，就判定为命中，不需要知道具体的相交面积或穿透向量。这种情况下，可以使用更简单、更快速的近似形状，如球体、胶囊体、AABB，并且可以关闭昂贵的连续碰撞检测。

2.2 性能预算：移动端、PC还是主机？

平台性能天花板决定了你能在碰撞检测上“挥霍”多少算力。

• 移动端：性能预算极其紧张。必须严格限制动态刚体的数量，大量使用静态碰撞体，并优先选择计算最简单的形状（球体 > 胶囊体 > 盒子 > 凸包 >> 三角网格）。宽相位算法的效率至关重要。
• PC/主机：拥有更强大的多核CPU，可以承受更复杂的物理模拟。你可以使用更多的动态物体和更精确的碰撞形状。但即便如此，在大型场景中，低效的碰撞设置依然是性能杀手。你需要利用好引擎提供的多线程物理计算特性。

2.3 动态与静态：谁在动，谁不动？

场景中的物体可以粗暴地分为两类：动态的和静态的。动态物体会移动、旋转，需要每帧更新其碰撞体的位置并参与碰撞解算。静态物体则固定不动。引擎内部会对它们进行特殊优化（如构建空间加速结构）。一个常见的性能陷阱是，将本该设置为静态的物体（如地形、建筑）错误地设置为动态或运动学，这会导致引擎无法对其进行优化，每帧都白白计算它们的碰撞更新。

2.4 触发与阻挡：需要物理反馈吗？

Unity中的Is Trigger和Unreal中的Generate Overlap Events选项，定义了碰撞体的行为模式。

• 阻挡：物体会发生物理相互作用，相互推开，消耗性能进行碰撞解算。
• 触发：物体只会检测重叠事件，但不会产生物理阻挡。性能开销远小于阻挡，常用于检测玩家进入某个区域、拾取物品等。

明确区分这两种用途，将大量仅需检测的碰撞体设为触发器，能立即释放可观的性能。

3. 算法工具箱：Unity与Unreal的核心碰撞检测机制

理解了需求，我们来看看引擎给我们提供了哪些工具。Unity和Unreal在底层都整合了强大的第三方物理引擎（Unity主要是NVIDIA PhysX，Unreal则是自家的Chaos物理系统，UE4及以前也是PhysX），但它们的上层接口和默认行为有显著差异。

3.1 Unity的碰撞检测体系

Unity的物理系统相对“黑盒”，但通过组件和参数提供了足够的控制力。

1. 碰撞体形状与层级：Unity提供了多种基本碰撞体：Box Collider,Sphere Collider,Capsule Collider是最常用的，性能极高。Mesh Collider可以使用模型的三角网格进行精确碰撞，但性能开销巨大，尤其是对于复杂模型。一个黄金法则是：永远不要对动态物体使用Mesh Collider。对于复杂形状的物体，应该使用多个基本碰撞体组合近似，或者使用Convex Hull模式的Mesh Collider（将网格转换为凸包）。

碰撞层级通过Layer和Physics Settings中的Layer Collision Matrix来管理。精细地设置碰撞矩阵，禁止不可能发生交互的层之间进行检测（比如，子弹层和子弹层之间），是减少宽相位检测数量的最有效手段之一。

2. 连续碰撞检测：为了防止高速运动物体（如子弹）穿过薄墙，Unity提供了CCD。它通过进行额外的插值检测来弥补离散时间步长带来的问题。CCD非常消耗性能，必须按需启用。

• Discrete：默认模式，性能最好，高速物体会穿透。
• Continuous：对动态物体使用连续检测，防止穿透其他动态或静态物体。开销较大。
• Continuous Dynamic：仅对标记为此模式的物体进行连续检测，性能相对较好，是处理高速子弹的推荐方案。

3. 物理更新频率与时间步长：在Project Settings -> Time中，Fixed Timestep决定了物理更新的频率。默认0.02秒（50Hz）。降低这个值（如0.0167秒，60Hz）会让物理更平滑，但会增加CPU负担。对于节奏快的游戏，可能需要提高频率；对于性能吃紧的项目，可以适当降低，但要注意可能导致的“卡顿”感。

注意：不要盲目提高Fixed Timestep频率。物理计算是确定性的，提高频率意味着每帧可能要进行多次物理更新，如果一帧的游戏时间（Time.deltaTime）远大于Fixed Timestep，就会累积多次物理更新，造成“螺旋式下降”的卡顿。一个常见的优化是设置Maximum Allowed Timestep来限制一帧内物理更新的最大时间，防止极端情况下的卡死。

3.2 Unreal Engine的碰撞检测体系

Unreal的碰撞系统更为显式和可配置，概念上也略有不同。

1. 碰撞预设与对象类型：这是Unreal碰撞管理的核心。Project Settings -> Collision中定义了各种Object Channels（如WorldStatic, Pawn, PhysicsBody）和Presets。每个预设定义了不同通道之间的碰撞响应（Ignore, Overlap, Block）。这套系统非常强大，可以精细地控制任意两类物体之间的交互关系，其本质就是配置一个高级的碰撞矩阵。

2. 碰撞形状与复杂碰撞：和Unity类似，有Box,Sphere,Capsule组件。复杂形状主要通过Convex Hull和Triangle Mesh来实现。

• 简单碰撞：在静态网格体编辑器中，可以生成Convex Hull（凸包）作为简单碰撞。这是对复杂形状性能最好的近似，强烈推荐用于所有动态物体。
• 复杂碰撞：即使用原始三角网格。仅适用于静态世界几何体（如复杂的地形、建筑内部）。将其用于动态物体会导致灾难性的性能下降。

3. 碰撞查询与跟踪：Unreal提供了多种碰撞查询方式，如LineTrace,SphereOverlap等，用于游戏逻辑中的射线检测、范围检测。这些查询的性能也受碰撞设置影响。对于频繁进行的查询（如每帧检测玩家脚下的地面），一定要确保其查询通道设置精确，避免检测不必要的物体。

4. Chaos物理系统的新特性：从UE5开始，Chaos物理系统逐渐成为默认。它带来了更强大的破坏模拟、更精确的连续碰撞检测（CCD）以及更好的多线程支持。对于新项目，建议直接基于Chaos进行开发。Chaos的CCD实现更高效，可以通过Project Settings -> Physics -> CCD全局启用，或针对单个Primitive Component设置。

4. 实战选型策略：从场景出发的决策树

理论说再多，不如直接看怎么选。下面我根据几种典型场景，给出具体的算法和组件选型建议。

4.1 场景一：移动端ARPG或休闲游戏

核心矛盾：大量单位同屏，性能预算极低。优化目标：最大限度减少每帧的碰撞检测对数量。

• 形状选择：
  • 玩家/敌人：统一使用Capsule Collider（Unity）或Capsule（Unreal）。胶囊体能很好地拟合人形，且计算速度仅次于球体。
  • 子弹/飞行物：使用Sphere Collider。计算最快。
  • 环境/障碍物：使用Box Collider组合。对于复杂静态地形，在Unity中可对静态网格使用Mesh Collider并勾选Convex（如果是简单形状）或使用多个盒子拼接；在Unreal中，为静态网格体生成Convex Hull简单碰撞。
• 层级/通道管理：
  • Unity：创建清晰的Layer，如Player,Enemy,Bullet,Environment。在碰撞矩阵中，明确设置：Bullet与Bullet相互忽略，Player与Player相互忽略（除非有友军伤害）。
  • Unreal：创建对应的Object Channels，并在Collision Presets中精细配置响应。例如，创建一个Bullet预设，它BlockWorldStatic和Pawn，但Ignore其他Bullet和PhysicsBody。
• 刚体设置：
  • 尽可能将不会移动的环境物体设置为Static（Unity）或World Static（Unreal）。
  • 对于大量同类型的敌人（如一群小怪），可以考虑使用简化版的碰撞检测，例如只与玩家进行检测，小怪之间使用更简单的距离判断或基于网格的空间划分来避免两两检测。
• 禁用与启用：对于屏幕外或远离玩家的单位，直接禁用其Collider组件或设置其碰撞响应为Ignore，可以立即消除其带来的性能开销。

4.2 场景二：PC/主机平台的FPS或动作游戏

核心矛盾：需要处理高速子弹（防穿透）和复杂的场景互动，同时保持高帧率。优化目标：平衡精度与性能，善用连续碰撞检测。

• 高速子弹解决方案：
  • Unity：
    1. 为子弹使用Sphere或Capsule Collider。
    2. 在子弹的Rigidbody上，将Collision Detection设置为Continuous Dynamic。
    3. 为可能被子弹击中的薄墙等静态物体，将其Collider的Rigidbody（即使没有刚体组件，也可以为其添加一个并设置为Kinematic）的碰撞检测也设置为Continuous。
    4. 实测心得：不要全局启用Continuous，开销太大。只为高速运动的子弹和与之交互的关键薄壁物体启用，是性价比最高的方案。
  • Unreal (Chaos)：
    1. 在项目设置中启用CCD（Project Settings -> Physics -> CCD）。
    2. 在子弹的Primitive Component细节面板中，找到Physics部分，将Solver Iterations下的Use CCD勾选为True。
    3. 同样，为薄墙等静态网格体组件也勾选Use CCD。
    4. Chaos的CCD可以设置CCD Threshold（速度阈值），只有速度超过此值的物体才会启用CCD，非常智能。
• 复杂角色碰撞：
  • 角色通常需要多个碰撞体：一个胶囊体用于移动和阻挡，多个更小的碰撞体（如盒子）用于不同部位的受击判定（爆头区、躯干区）。
  • 在Unreal中，可以利用Skeletal Mesh的Physics Asset来为每个骨骼绑定一个碰撞体，实现精确的布娃娃系统和部位伤害。
  • 注意事项：每增加一个碰撞体，就增加了宽相位检测的负担。务必确保这些额外碰撞体之间的碰撞是相互忽略的（在Unity中设置相同的Layer并在矩阵中忽略自身；在Unreal中通过预设配置），避免它们自己和自己做无用的碰撞检测。

4.3 场景三：包含大量可互动小物体的解谜或沙盒游戏

核心矛盾：成百上千的物理小物件（如箱子、瓶子、积木），两两之间都可能发生碰撞。优化目标：优化宽相位检测效率，防止O(n²)的复杂度爆炸。

• 空间划分与休眠：
  • 这是此类场景性能的关键。PhysX和Chaos引擎内部都使用高效的空间划分数据结构（如BVH树）来加速宽相位。但我们可以通过设置帮助引擎更好地工作。
  • Unity：确保静态物体在场景加载后位置不再改变，这样引擎可以为其构建优化的静态碰撞树。对于动态小物体，合理设置Rigidbody的Sleep Threshold（休眠阈值）。当物体速度低于此值并保持一段时间后，物理引擎会将其置为“休眠”状态，在唤醒前不再计算其碰撞和物理更新，能极大节省性能。
  • Unreal：同样，静态网格体使用World Static。对于可移动的小物体，使用Movable类型，并注意其Simulation Generates Hit Events等选项，不需要的事件一律关闭。
• 简化碰撞形状：
  • 对于小物件，坚决不使用Mesh Collider。一个酒瓶完全可以用一个胶囊体来近似。一摞书可以用一个扁平的盒子来代表。形状越简单，窄相位计算越快，宽相期的包围盒测试也越快。
• 分层管理：
  • 创建一个专门的SmallProp层或通道。在碰撞矩阵/预设中，可以设置SmallProp与SmallProp之间为Overlap（触发）而非Block（阻挡），如果它们之间的物理阻挡对游戏性不重要的话。这能避免大量小物件相互卡住时复杂的约束解算，性能提升立竿见影。
  • 踩过的坑：曾经在一个沙盒项目中，上千个小石子都用的是简化的凸包碰撞体，并且相互阻挡。结果玩家一炮轰过去，物理线程直接卡死数秒。后来将小石子之间的碰撞改为Overlap，只检测重叠事件（用于播放音效、粒子），性能问题瞬间解决。

5. 性能分析与调试实战

选型之后，如何验证效果？靠感觉是不行的，必须依赖数据。

5.1 Unity性能分析工具

1. Profiler (CPU Usage)：这是最主要的工具。切换到Profiler窗口，录制一段游戏运行过程，重点关注Physics.Processing和Physics.Simulate所占用的CPU时间。如果它们占比过高（比如超过每帧时间的10%-15%），就说明物理是瓶颈。
2. Physics Debug Visualization：在Window -> Analysis -> Physics Debugger中，可以可视化碰撞体、接触点、刚体休眠状态等。看到屏幕上密密麻麻的碰撞体线框，你就能直观感受到检测的密度。确保静态碰撞体是绿色（已优化），动态的是其他颜色。
3. 定制脚本计数：可以在代码中统计每帧Physics.Raycast、OverlapSphere等查询的调用次数，或者通过Physics.GetContacts来估算活跃的接触点数量，辅助定位热点。

5.2 Unreal Engine性能分析工具

1. Unreal Insights：这是UE最强大的性能分析套件。通过命令行参数-trace=stat,frame,cpu,physics启动游戏，然后使用Unreal Insights桌面端加载录制的数据。在Timing视图中，可以清晰看到GameThread和PhysicsThread的时间消耗。展开Physics相关计数器，可以查看碰撞检测、约束求解等具体耗时。
2. Stat Commands：在游戏运行时按**~**键打开控制台，输入以下命令：
   • stat physics：显示物理相关的统计信息，包括刚体数量、碰撞对数量等。
   • stat scenerendering：有时碰撞渲染开销也会体现在这里（如碰撞体调试绘制）。
   • stat game：查看游戏线程的帧时间。
3. 可视化调试：在编辑器视口中按`键，可以显示碰撞体、物理网格等。同样，观察碰撞体的复杂度和数量。

5.3 优化前后对比案例

假设一个场景有200个动态小道具（盒子）和1个玩家。

• 优化前：
  • 所有200个盒子使用Mesh Collider（复杂网格）。
  • 碰撞矩阵全开，所有物体两两检测。
  • Unity Profiler显示Physics.Processing耗时 8ms/帧。
• 优化步骤：
  1. 形状简化：将200个盒子的Mesh Collider全部替换为Box Collider。
  2. 层级优化：创建Prop层，在碰撞矩阵中设置Prop层内部物体相互Ignore。
  3. 休眠设置：为盒子的Rigidbody设置合理的Sleep Threshold。
• 优化后：
  • Physics.Processing耗时降至 1.5ms/帧。
  • 性能提升超过80%。

这个案例清晰地表明，碰撞体的形状复杂度和检测对数量，是影响性能的两个最关键因素。

6. 高级技巧与避坑指南

掌握了基础选型和调试，下面这些进阶技巧和常见陷阱，能让你在复杂项目中更加游刃有余。

6.1 复合碰撞体的正确使用

当一个物体需要由多个简单形状组合时（比如一个机器人由身体（盒子）、头部（球体）、手臂（胶囊体）组成），在Unity中你会添加多个Collider组件到一个GameObject上；在Unreal中，你会在一个Actor上添加多个Primitive Component。

• 优点：比单个复杂网格碰撞体性能好得多。
• 坑点：这些子碰撞体彼此之间也会进行碰撞检测！如果你不处理，引擎会浪费大量资源计算机器人自己的头会不会碰到自己的手臂。
• 解决方案：
  • Unity：确保所有这些子碰撞体都在同一个Layer。然后，在Physics Settings的碰撞矩阵中，将这个Layer与自身的碰撞设置为Ignore。这样，它们彼此之间就不会检测了。
  • Unreal：将这些子碰撞体的Collision Presets设置为同一个自定义预设，并在该预设中，将对应的Object Channel自身的响应设置为Ignore。

6.2 运动学刚体的陷阱

运动学刚体（Rigidbody.isKinematic = truein Unity,Simulation Generates Hit Events&Mobility = Movablewith custom movement in Unreal）由代码控制运动，不受物理力影响。常用于玩家角色、电梯等。

• 性能优势：运动学刚体与静态物体的碰撞检测，通常比两个动态刚体之间更高效。
• 巨大陷阱：一个高速运动的运动学刚体，是连续碰撞检测的“盲区”。默认情况下，CCD只作用于动态刚体。如果你的玩家（运动学）跑得飞快，他可能会直接穿过薄墙。同样，高速运动的运动学子弹也无法通过CCD击中目标。
• 解决方案：
  • 对于玩家穿墙：除了做好关卡设计，可以考虑在玩家身上附加一个微小的、Continuous Dynamic的动态刚体碰撞体作为“探测器”。
  • 对于运动学子弹：要么改用动态刚体+CCD，要么使用射线检测（Raycast）来代替碰撞体进行命中判断。对于大量子弹，射线检测的性能通常远优于物理模拟。

6.3 触发器与性能

很多人认为触发器（Is Trigger）没有性能成本，这是错误的。触发器依然需要参与宽相位检测，以确定是否与其他碰撞体重叠。它的性能优势在于跳过窄相位的接触点计算和物理响应解算，这部分才是物理计算中最耗时的。

• 优化建议：即使使用触发器，也应遵循所有优化原则：使用简单形状、做好层级管理、远离玩家时禁用。一个覆盖全地图的巨大球形触发器，每帧都要和场景中所有碰撞体进行宽相位检测，开销同样不可小觑。

6.4 动态修改碰撞属性的开销

在运行时频繁地启用/禁用碰撞体（collider.enabled）、修改layer、或者改变刚体的isKinematic状态，会触发物理引擎内部状态的更新和脏标记，可能引起性能波动。

• 最佳实践：如果可能，尽量在初始化时（Start/Awake或BeginPlay）就确定好碰撞属性。对于需要频繁切换的状态（如角色的“无敌”状态），考虑修改碰撞矩阵或预设，而不是直接开关碰撞体。例如，在Unity中，可以准备两个Layer：Player和PlayerInvincible。无敌时，将角色切换到PlayerInvincible层，并在碰撞矩阵中预设好该层与子弹层为Ignore。这样切换的是Layer，而不是碰撞体的启用状态，通常开销更小。

7. 总结：从原则到实践的性能提升路径

回顾一下，要让碰撞检测性能“翻倍”，不是一个魔法开关，而是一套从设计到实现的组合拳。

第一步：设计阶段确立原则。在项目初期，就和策划、美术定下规矩：动态物体一律使用基本碰撞体形状（球、盒、胶囊）或其组合；复杂静态网格必须生成凸包简化碰撞；明确各类物体间的碰撞关系表。

第二步：实施阶段精细配置。严格按照第一步的原则创建碰撞体。在Unity中配好Layer和碰撞矩阵，在Unreal中设计好Object Channels和Collision Presets。像管理代码依赖一样管理你的碰撞关系。

第三步：针对特性专项优化。如果有高速物体，谨慎启用CCD并限定范围。如果有大量小物体，利用好休眠和简化碰撞。如果是移动端，把性能预算作为硬性约束。

第四步：善用工具持续监控。开发过程中，定期使用Profiler或Unreal Insights查看物理线程耗时。在复杂场景测试时，打开物理调试可视化，看看屏幕上是不是有多余的、过于复杂的碰撞体线框在跳动。

最后，记住一个核心思想：碰撞检测的优化，本质上是做减法。减去不必要的检测对，减去过于复杂的形状计算，减去无效的物理模拟。每一次减法，都意味着为更重要的游戏逻辑和更绚丽的画面效果腾出了宝贵的CPU时间。当你看到优化后流畅稳定的帧率时，你会觉得这些细致的工作都是值得的。性能优化没有终点，但掌握了正确的方法论和工具，你就能在资源有限的战场上，为你的游戏赢得决定性的优势。