1. 项目概述当游戏世界需要“真实”的物理法则如果你是一名游戏开发者或者对游戏技术底层有浓厚兴趣那么“物理引擎”这个词对你来说一定不陌生。它就像是虚拟世界的“牛顿”负责计算物体如何下落、碰撞、滚动让游戏世界从一堆静止的模型变成一个充满动态和反馈的活生生的空间。然而随着游戏世界规模的爆炸式增长——从几十个敌人到成千上万的单位同屏从简单的场景到复杂的开放世界——传统的物理引擎开始力不从心。计算一个物体的运动轨迹不难难的是当屏幕上同时有十万、甚至百万个实体在运动时如何高效、准确地判断它们之间“谁撞到了谁”。这就是“碰撞检测”成为性能瓶颈的核心原因。最近几年Unity推出的DOTSData-Oriented Technology Stack面向数据的技术栈架构配合其全新的高性能物理引擎正在尝试从根本上解决这个难题。它不再满足于每秒处理几千次碰撞而是将目标定在了“每秒百万级实体”。这个数字听起来有些夸张但它背后代表的是一种技术范式的转变从面向对象到面向数据从单线程到极致并行。这不仅仅是Unity引擎的进步更是整个实时交互内容开发领域在面对海量实体模拟需求时必然要走的道路。今天我们就来彻底拆解一下DOTS物理引擎是如何实现这一看似不可能的任务的。我们会从最根本的设计哲学讲起一直深入到具体的代码和配置细节让你不仅知道它“快”更明白它为什么能“这么快”。2. DOTS物理引擎的核心设计哲学数据与计算解耦要理解DOTS物理引擎的威力首先必须跳出我们熟悉的“面向对象”思维。在传统的游戏开发中一个游戏实体比如一个敌人、一颗子弹通常被建模为一个GameObject上面挂载着各种组件Component如Transform、Rigidbody、Collider。物理引擎会遍历这些GameObject检查它们的Collider计算碰撞。这种模式直观但效率低下原因在于“数据局部性”差。CPU需要在整个内存中跳跃式地访问不同对象的数据导致缓存命中率极低大量时间浪费在等待数据从内存加载到缓存上。2.1 面向数据的设计让数据连续排列DOTS物理引擎的核心变革就在于它彻底采用了“面向数据”的设计。它不再关心“对象”只关心“数据”。具体来说所有实体的同类数据被紧密地、连续地存储在内存中。数据布局的转变假设我们有100万个球体需要进行碰撞检测。在传统模式下每个球体的位置Position、速度Velocity、半径Radius数据是分散在100万个不同的内存块中的。CPU为了计算碰撞需要像查电话簿一样东翻一页西翻一页。而在DOTS模式下我们会创建三个巨大的、连续的数组一个float3数组存放所有100万个球体的Position一个float3数组存放所有Velocity一个float数组存放所有Radius。缓存友好的优势当CPU需要处理碰撞时它可以一次性将一大块连续的Position数据加载到高速缓存中然后以极高的效率进行遍历和计算。这就像你把所有需要处理的文件都按顺序整理好放在一张桌子上而不是分散在办公室的各个抽屉里处理效率自然天差地别。这种数据布局是后续所有高性能优化的基础。2.2 实体组件系统数据访问的抽象层DOTS通过ECSEntity Component System架构来管理这种面向数据的设计。你可以把ECS理解为一套高效的数据组织和管理规范。Entity仅仅是一个轻量级的ID代表一个存在它本身不包含任何数据。这就像一个人的身份证号只代表身份。Component纯粹的数据结构。例如PhysicsVelocity速度、PhysicsCollider碰撞体。这些组件数据按照类型以我们上面提到的连续数组称为Archetype块方式存储。System负责处理数据的逻辑系统。一个CollisionDetectionSystem就是一个系统它在一个更新循环中遍历所有拥有PhysicsCollider和PhysicsVelocity组件的实体数据执行碰撞检测算法。这种强制性的分离使得数据存储最优化的同时逻辑System也可以被高度并行化。2.3 作业系统与Burst编译器榨干CPU的每一滴性能有了好的数据布局还需要强大的计算能力。DOTS通过Job System和Burst Compiler来实现。Job System这是一个将任务拆分成多个可以并行执行的“作业”的系统。碰撞检测是一个可以完美并行化的任务——检测球A和球B是否碰撞与检测球C和球D是否碰撞这两项工作之间没有依赖关系。Job System 允许我们将100万个实体的碰撞检测任务分解成成千上万个小型作业分发到CPU的多个核心上同时执行。从“单车道”变成了“百车道高速公路”。Burst Compiler这是一个为Unity专门设计的高性能编译器。它会把你的C# Job代码编译成高度优化的本地机器码绕过了.NET虚拟机的开销。经过Burst编译后的碰撞检测循环其执行速度可以接近甚至达到手写C的水平。它特别擅长优化数学运算向量、矩阵而这正是物理计算的核心。注意Burst编译器对代码有严格限制例如不能使用托管对象、需要避免某些分支预测不友好的代码模式。在编写物理相关的Job时必须遵循它的规则否则无法编译或无法达到最优性能。3. 百万级碰撞检测的算法奥秘有了高效的数据和并行计算框架接下来就要看算法本身了。最笨的办法是进行“暴力检测”Brute Force即让每一个实体都和其他所有实体进行碰撞判断。对于N个实体这需要N*(N-1)/2次检测当N1,000,000时计算量是天文数字即使并行化也无力回天。因此DOTS物理引擎采用了一套多层次的空间分割与筛选策略。3.1 空间划分Broad Phase宽阶段宽阶段的目标是快速剔除那些“绝对不可能发生碰撞”的实体对将候选对的数量降低几个数量级。DOTS物理引擎主要依赖的是层次包围盒树。工作原理引擎会为整个世界场景动态构建一棵BVH树。树的每个节点都有一个轴对齐包围盒这个包围盒包裹了其所有子节点的包围盒。叶子节点则对应着单个实体的碰撞体包围盒。遍历与筛选当需要检测碰撞时系统从树根开始遍历。如果两个节点的包围盒都不相交那么它们子树下的所有实体都不可能发生碰撞整棵子树都会被跳过。只有那些包围盒相交的节点才会继续向下递归检查。这个过程极大地减少了需要进入下一阶段检测的实体对数量。动态更新由于实体在持续运动BVH树也需要更新。DOTS物理引擎会采用增量式更新等策略只更新那些位置发生变化的实体所在的树枝而不是每一帧重建整棵树以维持高性能。3.2 精确检测Narrow Phase窄阶段经过宽阶段筛选后我们得到了一组“可能碰撞”的实体对列表。窄阶段的任务就是对这每一对实体进行精确的几何相交测试。形状支持DOTS物理引擎支持多种基础碰撞体形状如球体Sphere、胶囊体Capsule、盒子Box、凸包Convex Hull等。每种形状之间都有特定的、高度优化的相交测试算法。算法选择例如检测两个球体是否碰撞只需要比较球心距离和半径之和计算一次开方即可速度极快。而检测两个凸包是否碰撞则可能使用GJKGilbert–Johnson–Keerthi算法或EPAExpanding Polytope Algorithm算法这些算法更复杂但能提供精确的接触点和穿透深度信息。数据导向的实现在DOTS中这些算法被实现为在连续数据上操作的Job。一个Job专门处理所有“球体-球体”对另一个Job处理所有“盒子-球体”对以此类推。这种按数据类别分工作业的方式进一步提高了缓存利用率和并行效率。3.3 接触点生成与解析检测到碰撞后工作还没结束。物理引擎需要生成详细的碰撞信息供后续的碰撞响应如反弹、摩擦使用。接触流形对于像盒子-盒子这样的面接触碰撞点通常不止一个。物理引擎会计算一个“接触流形”即一组代表接触区域的信息如接触点、法线、穿透深度。DOTS物理引擎会高效地计算并存储这些信息。数据流所有这些碰撞信息实体A的ID实体B的ID接触点法线等会被收集到一个线程安全的“事件流”或通过ECS的“碰撞事件组件”中。游戏逻辑系统可以随后读取这些数据播放声音、触发特效、计算伤害等。4. 实战从零构建一个DOTS物理碰撞演示理论说得再多不如亲手实践。下面我们来一步步搭建一个简单的演示看看如何用DOTS实现成千上万个实体的物理模拟。4.1 环境准备与项目设置首先你需要一个安装了最新版Unity Hub和Unity Editor建议2022.3 LTS或更新版本的环境。创建新项目使用“3D Core”模板创建项目。这个模板最干净。安装Package打开Package Manager安装以下关键包Entities(ECS核心)Entities Graphics(用于渲染ECS实体)Physics(DOTS物理引擎核心)Hybrid Renderer(V2) (用于将ECS实体渲染到场景注意版本)你可能还需要Unity.Collections、Unity.Mathematics等它们通常会作为依赖被自动安装。启用BurstBurst编译器通常已包含在Unity安装中确保它在Package Manager中已启用。4.2 创建可物理模拟的实体在DOTS中我们不再创建传统的GameObject而是通过代码或子场景来生成实体。方案一通过Authoring MonoBehaviour转换这是最常见的方式便于在编辑器中配置。using Unity.Entities; using Unity.Physics; using Unity.Physics.Authoring; using UnityEngine; public class SpawnerAuthoring : MonoBehaviour { public GameObject Prefab; public int Count; public float Radius; class Baker : BakerSpawnerAuthoring { public override void Bake(SpawnerAuthoring authoring) { var entity GetEntity(TransformUsageFlags.Dynamic); AddComponent(entity, new Spawner { Prefab GetEntity(authoring.Prefab, TransformUsageFlags.Dynamic), Count authoring.Count, Radius authoring.Radius }); } } } public struct Spawner : IComponentData { public Entity Prefab; public int Count; public float Radius; }创建一个空GameObject挂载此脚本并拖入一个预制体这个预制体需要包含PhysicsShapeAuthoring和PhysicsBodyAuthoring组件来定义碰撞体和刚体属性。方案二纯ECS代码生成在System中直接创建实体灵活性最高。using Unity.Entities; using Unity.Physics; using Unity.Transforms; using Unity.Mathematics; using Unity.Collections; public partial class SphereSpawnerSystem : SystemBase { protected override void OnCreate() { // 仅在开始时运行一次 RequireForUpdateSpawner(); } protected override void OnUpdate() { var spawner SystemAPI.GetSingletonSpawner(); var ecb new EntityCommandBuffer(Allocator.TempJob); // 使用随机数生成位置 var random Random.CreateFromIndex(1234); for (int i 0; i spawner.Count; i) { var newEntity ecb.Instantiate(spawner.Prefab); // 在一个球形范围内随机生成位置 float3 pos random.NextFloat3Direction() * random.NextFloat(0, spawner.Radius); ecb.SetComponent(newEntity, LocalTransform.FromPosition(pos)); // 赋予一个随机初始速度 float3 velocity random.NextFloat3Direction() * 10.0f; ecb.SetComponent(newEntity, new PhysicsVelocity { Linear velocity }); } ecb.Playback(EntityManager); ecb.Dispose(); // 移除Spawner组件防止下一帧再次生成 EntityManager.DestroyEntity(SystemAPI.GetSingletonEntitySpawner()); } }4.3 配置物理世界与碰撞过滤物理世界的全局属性通过PhysicsWorldIndex和PhysicsStep组件来配置。创建物理世界配置实体你可以创建一个空实体并为其添加PhysicsWorldIndex和PhysicsStep组件。PhysicsStep组件可以设置重力、求解器迭代次数等。碰撞过滤这是控制“谁和谁碰撞”的关键。每个PhysicsCollider组件在创建时都可以指定一个CollisionFilter。var filter new CollisionFilter { BelongsTo 1u 0, // 这个碰撞体属于第0组 CollidesWith ~(1u 1) // 与除了第1组之外的所有组都碰撞 }; var sphereGeometry new SphereGeometry { Center float3.zero, Radius 0.5f }; var collider Unity.Physics.SphereCollider.Create(sphereGeometry, filter);通过位掩码进行分组管理可以高效地实现复杂的碰撞关系例如子弹只打敌人玩家之间不互相碰撞等。4.4 编写系统驱动物理与响应碰撞物理模拟本身由PhysicsSystem等内置系统驱动。我们需要编写自己的System来响应碰撞事件。响应碰撞事件DOTS物理提供了几种方式。ICollisionEventsJob在一个Job中处理所有碰撞事件性能最好。public partial struct CollisionEventSystem : ISystem { public void OnUpdate(ref SystemState state) { var physicsWorld SystemAPI.GetSingletonPhysicsWorldSingleton(); var simulation SystemAPI.GetSingletonSimulationSingleton(); // 调度一个处理碰撞事件的Job state.Dependency new CollisionEventJob { // 通过Lambda表达式或IJobEntity方式处理事件 }.Schedule(simulation, ref physicsWorld, state.Dependency); } }CollisionEvent组件当碰撞发生时会自动为发生碰撞的实体添加一个CollisionEvent组件你可以在另一个System中查询并处理这些组件处理完毕后销毁该组件。这种方式更符合ECS的“数据驱动”思维。自定义物理行为你可以在System中直接修改实体的PhysicsVelocity或施加PhysicsForce来创造自定义的物理效果比如爆炸冲击波、磁力吸引等。5. 性能调优与深度避坑指南将百万实体跑起来是一回事跑得流畅是另一回事。以下是一些关键的调优点和常见陷阱。5.1 性能瓶颈分析与工具使用Profiler是你的第一工具务必使用Unity Profiler的Deep Profile模式特别是观察Jobs和Burst编译的线程执行情况。关注PhysicsSimulationGroup下的系统耗时。关键指标宽阶段耗时如果这里耗时高说明实体空间分布太散或BVH树更新开销大。考虑调整世界边界或实体密度。窄阶段耗时如果这里耗时高说明经过宽阶段筛选后候选对仍然太多或者碰撞体形状过于复杂如高精度凸包。主线程等待时间如果主线程长时间等待物理Job完成说明Job依赖关系可能没组织好或者有主线程上的阻塞操作如同步加载资源。5.2 实体与碰撞体设计的黄金法则简化碰撞形状永远使用能满足需求的最简单形状。顺序是球体 胶囊体 盒子 低顶点数的凸包 网格碰撞体。对于大量的小碎片用球体代替复杂形状能带来数量级的性能提升。合理设置碰撞层充分利用CollisionFilter。让不需要相互碰撞的物体处于不同的层可以极大减少宽阶段和窄阶段的计算量。这是最重要的优化手段之一。静态与动态分离将永远不会移动的静态环境碰撞体标记为Static。物理引擎会对它们进行特殊优化如更优的BVH构建。动态物体之间和动态与静态之间的检测通常是分开处理的。控制实体数量百万是理论极限在具体项目中要权衡。是否可以用粒子系统代替一部分物理实体是否可以用一个大的碰撞体代表一群小物体5.3 多线程与Job的安全陷阱Race Condition竞态条件这是多线程编程的头号敌人。确保你在一个Job中只写入一个组件或者使用NativeContainer如NativeQueue进行线程安全的数据传递。EntityCommandBuffer是跨线程安全创建/修改实体的利器。错误的依赖关系如果Job B需要Job A的结果你必须正确设置JobHandle的依赖关系JobHandle.CombineDependencies。依赖设置错误会导致逻辑错误或性能下降无法并行。Burst兼容性在Job中使用的所有代码和数据结构都必须是Burst兼容的。避免在Job中使用string、class、GameObject等托管类型。使用NativeArray代替List使用FixedString代替string。5.4 内存管理与泄漏排查Allocator的选择ECS中大量使用NativeContainer创建时必须指定分配器。Allocator.Temp帧生命周期最快但必须在同一帧的Job完成后销毁。Allocator.TempJob4帧生命周期适合在Job间传递数据。Allocator.Persistent长期存在手动管理用不好会导致内存泄漏。泄漏检查在编辑器的Jobs-Burst-Native Leak Detection中开启泄漏检测。任何未正确释放的NativeContainer都会在运行时抛出错误。实体泄漏同样确保不再需要的实体通过EntityManager.DestroyEntity或EntityCommandBuffer.DestroyEntity进行销毁。6. 进阶超越基础碰撞的扩展应用掌握了基础的碰撞检测DOTS物理引擎还能做更多酷炫的事情。6.1 触发器与查询非物理交互除了硬碰撞游戏还需要大量的“感知”逻辑比如进入一个区域触发剧情。这可以通过触发器和物理查询来实现。触发器将碰撞体的CollisionResponsePolicy设置为CollisionResponsePolicy.RaiseTriggerEvents它就不会产生物理阻力但会生成TriggerEvent事件你可以在System中处理这些事件。物理查询例如射线检测Raycast、形状重叠检测Overlap、最近点查询Closest Point。这些查询同样可以利用BVH进行加速并且可以在Job中并行执行。你可以一次性发射成千上万条射线来检测视线、火力瞄准等性能极高。6.2 自定义物理材质与碰撞响应通过PhysicsMaterial组件你可以定义物体的摩擦系数和恢复系数弹性。但DOTS物理也允许你更深入地介入碰撞响应过程。修改求解器输入在物理系统计算碰撞响应之前有一个ISimulationEvent阶段。你可以在这里获取到预求解的碰撞数据如速度、质量、接触点并对其进行修改从而实现自定义的物理效果比如“粘性”表面、速度依赖的摩擦力等。直接速度修改在碰撞事件处理Job中你可以直接读取碰撞双方的PhysicsVelocity并进行修改实现完全自定义的碰撞后行为无视标准的物理公式。6.3 与动画、VFX和游戏逻辑的集成物理引擎不是孤岛它的数据需要驱动其他系统。驱动动画将实体的PhysicsVelocity或角速度数据传递给动画系统可以用来混合“移动”状态机或者驱动 procedural animation程序化动画比如根据速度摆动披风。触发特效在碰撞事件处理System中可以根据碰撞强度相对速度和碰撞点位置命令VFX系统生成火花、灰尘等粒子效果。这里可以通过EntityCommandBuffer异步创建特效实体。游戏逻辑伤害计算、得分、任务触发等都可以基于碰撞事件中的数据谁撞了谁撞在哪里有多快来驱动。这完美体现了ECS“数据驱动”的理念物理系统产出碰撞数据其他系统消费这些数据。7. 常见问题与实战排错记录在实际项目中你一定会遇到各种光怪陆离的问题。下面是我踩过的一些坑和解决方案。问题1实体生成后一动不动像被冻住了。排查首先检查实体是否拥有PhysicsVelocity组件。如果没有它就是静态的。其次检查PhysicsWorldIndex和PhysicsStep组件是否存在于世界中至少有一个实体拥有它们。最后检查碰撞体是否被正确创建特别是Collider的Size是否不为零。心得给新生成的动态物理实体一个非零的初始速度是快速验证物理系统是否工作的好方法。问题2性能随着实体数量增加急剧下降但Profiler显示物理耗时并不高。排查这很可能不是物理引擎本身的问题。检查渲染部分。你是否为每个实体都实例化了一个完整的GameObject进行渲染这会导致Draw Call爆炸。应该使用ECS专用的渲染方案如MeshInstanceRendererComponent或最新的Entities Graphics它能够合批渲染成千上万个相同网格的实体。心得在DOTS项目中渲染往往是比物理更大的瓶颈。确保采用面向数据的渲染管线。问题3碰撞事件有时触发有时不触发或者触发对象不对。排查99%的原因是CollisionFilter设置错误。仔细检查发生碰撞的双方实体的BelongsTo和CollidesWith位掩码。使用Debug.Log或UnityEngine.Debug.DrawLine在编辑器中可视化调试碰撞关系。另一个可能是碰撞体太小或相对速度太快导致“隧道效应”一帧穿过去了。可以尝试启用连续碰撞检测CCD但会显著增加性能开销。心得为不同的物体类型玩家、敌人、子弹、环境定义好清晰的碰撞层枚举并在代码中集中管理避免硬编码的魔数。问题4Burst编译错误提示某些代码不支持。排查Burst不支持在Job中使用try-catch、string.Format、虚函数调用、访问托管对象等。仔细阅读错误信息它会指出哪一行代码有问题。常见的解决方法是将复杂的字符串操作移到主线程使用FixedString避免在Job中调用非Burst兼容的第三方库。心得尽量让Job中的逻辑保持纯粹和简单只做数学计算和数据搬运。复杂的业务逻辑和资源管理放在主线程的System中。问题5在编辑器里运行正常打包后物理行为不一致或崩溃。排查首先检查所有NativeContainer的分配和释放是否成对出现特别是在不同场景切换时。其次确保Burst编译在发布模式下是开启的有时开发中会关闭用于调试。最后检查是否有依赖于编辑器特定顺序的初始化逻辑在独立的玩家进程中执行顺序可能不同。心得养成在打包后立即进行基础功能测试的习惯。使用Development Build并启用日志可以在真机或打包环境中看到错误输出。
1. 项目概述当游戏世界需要“真实”的物理法则如果你是一名游戏开发者或者对游戏技术底层有浓厚兴趣那么“物理引擎”这个词对你来说一定不陌生。它就像是虚拟世界的“牛顿”负责计算物体如何下落、碰撞、滚动让游戏世界从一堆静止的模型变成一个充满动态和反馈的活生生的空间。然而随着游戏世界规模的爆炸式增长——从几十个敌人到成千上万的单位同屏从简单的场景到复杂的开放世界——传统的物理引擎开始力不从心。计算一个物体的运动轨迹不难难的是当屏幕上同时有十万、甚至百万个实体在运动时如何高效、准确地判断它们之间“谁撞到了谁”。这就是“碰撞检测”成为性能瓶颈的核心原因。最近几年Unity推出的DOTSData-Oriented Technology Stack面向数据的技术栈架构配合其全新的高性能物理引擎正在尝试从根本上解决这个难题。它不再满足于每秒处理几千次碰撞而是将目标定在了“每秒百万级实体”。这个数字听起来有些夸张但它背后代表的是一种技术范式的转变从面向对象到面向数据从单线程到极致并行。这不仅仅是Unity引擎的进步更是整个实时交互内容开发领域在面对海量实体模拟需求时必然要走的道路。今天我们就来彻底拆解一下DOTS物理引擎是如何实现这一看似不可能的任务的。我们会从最根本的设计哲学讲起一直深入到具体的代码和配置细节让你不仅知道它“快”更明白它为什么能“这么快”。2. DOTS物理引擎的核心设计哲学数据与计算解耦要理解DOTS物理引擎的威力首先必须跳出我们熟悉的“面向对象”思维。在传统的游戏开发中一个游戏实体比如一个敌人、一颗子弹通常被建模为一个GameObject上面挂载着各种组件Component如Transform、Rigidbody、Collider。物理引擎会遍历这些GameObject检查它们的Collider计算碰撞。这种模式直观但效率低下原因在于“数据局部性”差。CPU需要在整个内存中跳跃式地访问不同对象的数据导致缓存命中率极低大量时间浪费在等待数据从内存加载到缓存上。2.1 面向数据的设计让数据连续排列DOTS物理引擎的核心变革就在于它彻底采用了“面向数据”的设计。它不再关心“对象”只关心“数据”。具体来说所有实体的同类数据被紧密地、连续地存储在内存中。数据布局的转变假设我们有100万个球体需要进行碰撞检测。在传统模式下每个球体的位置Position、速度Velocity、半径Radius数据是分散在100万个不同的内存块中的。CPU为了计算碰撞需要像查电话簿一样东翻一页西翻一页。而在DOTS模式下我们会创建三个巨大的、连续的数组一个float3数组存放所有100万个球体的Position一个float3数组存放所有Velocity一个float数组存放所有Radius。缓存友好的优势当CPU需要处理碰撞时它可以一次性将一大块连续的Position数据加载到高速缓存中然后以极高的效率进行遍历和计算。这就像你把所有需要处理的文件都按顺序整理好放在一张桌子上而不是分散在办公室的各个抽屉里处理效率自然天差地别。这种数据布局是后续所有高性能优化的基础。2.2 实体组件系统数据访问的抽象层DOTS通过ECSEntity Component System架构来管理这种面向数据的设计。你可以把ECS理解为一套高效的数据组织和管理规范。Entity仅仅是一个轻量级的ID代表一个存在它本身不包含任何数据。这就像一个人的身份证号只代表身份。Component纯粹的数据结构。例如PhysicsVelocity速度、PhysicsCollider碰撞体。这些组件数据按照类型以我们上面提到的连续数组称为Archetype块方式存储。System负责处理数据的逻辑系统。一个CollisionDetectionSystem就是一个系统它在一个更新循环中遍历所有拥有PhysicsCollider和PhysicsVelocity组件的实体数据执行碰撞检测算法。这种强制性的分离使得数据存储最优化的同时逻辑System也可以被高度并行化。2.3 作业系统与Burst编译器榨干CPU的每一滴性能有了好的数据布局还需要强大的计算能力。DOTS通过Job System和Burst Compiler来实现。Job System这是一个将任务拆分成多个可以并行执行的“作业”的系统。碰撞检测是一个可以完美并行化的任务——检测球A和球B是否碰撞与检测球C和球D是否碰撞这两项工作之间没有依赖关系。Job System 允许我们将100万个实体的碰撞检测任务分解成成千上万个小型作业分发到CPU的多个核心上同时执行。从“单车道”变成了“百车道高速公路”。Burst Compiler这是一个为Unity专门设计的高性能编译器。它会把你的C# Job代码编译成高度优化的本地机器码绕过了.NET虚拟机的开销。经过Burst编译后的碰撞检测循环其执行速度可以接近甚至达到手写C的水平。它特别擅长优化数学运算向量、矩阵而这正是物理计算的核心。注意Burst编译器对代码有严格限制例如不能使用托管对象、需要避免某些分支预测不友好的代码模式。在编写物理相关的Job时必须遵循它的规则否则无法编译或无法达到最优性能。3. 百万级碰撞检测的算法奥秘有了高效的数据和并行计算框架接下来就要看算法本身了。最笨的办法是进行“暴力检测”Brute Force即让每一个实体都和其他所有实体进行碰撞判断。对于N个实体这需要N*(N-1)/2次检测当N1,000,000时计算量是天文数字即使并行化也无力回天。因此DOTS物理引擎采用了一套多层次的空间分割与筛选策略。3.1 空间划分Broad Phase宽阶段宽阶段的目标是快速剔除那些“绝对不可能发生碰撞”的实体对将候选对的数量降低几个数量级。DOTS物理引擎主要依赖的是层次包围盒树。工作原理引擎会为整个世界场景动态构建一棵BVH树。树的每个节点都有一个轴对齐包围盒这个包围盒包裹了其所有子节点的包围盒。叶子节点则对应着单个实体的碰撞体包围盒。遍历与筛选当需要检测碰撞时系统从树根开始遍历。如果两个节点的包围盒都不相交那么它们子树下的所有实体都不可能发生碰撞整棵子树都会被跳过。只有那些包围盒相交的节点才会继续向下递归检查。这个过程极大地减少了需要进入下一阶段检测的实体对数量。动态更新由于实体在持续运动BVH树也需要更新。DOTS物理引擎会采用增量式更新等策略只更新那些位置发生变化的实体所在的树枝而不是每一帧重建整棵树以维持高性能。3.2 精确检测Narrow Phase窄阶段经过宽阶段筛选后我们得到了一组“可能碰撞”的实体对列表。窄阶段的任务就是对这每一对实体进行精确的几何相交测试。形状支持DOTS物理引擎支持多种基础碰撞体形状如球体Sphere、胶囊体Capsule、盒子Box、凸包Convex Hull等。每种形状之间都有特定的、高度优化的相交测试算法。算法选择例如检测两个球体是否碰撞只需要比较球心距离和半径之和计算一次开方即可速度极快。而检测两个凸包是否碰撞则可能使用GJKGilbert–Johnson–Keerthi算法或EPAExpanding Polytope Algorithm算法这些算法更复杂但能提供精确的接触点和穿透深度信息。数据导向的实现在DOTS中这些算法被实现为在连续数据上操作的Job。一个Job专门处理所有“球体-球体”对另一个Job处理所有“盒子-球体”对以此类推。这种按数据类别分工作业的方式进一步提高了缓存利用率和并行效率。3.3 接触点生成与解析检测到碰撞后工作还没结束。物理引擎需要生成详细的碰撞信息供后续的碰撞响应如反弹、摩擦使用。接触流形对于像盒子-盒子这样的面接触碰撞点通常不止一个。物理引擎会计算一个“接触流形”即一组代表接触区域的信息如接触点、法线、穿透深度。DOTS物理引擎会高效地计算并存储这些信息。数据流所有这些碰撞信息实体A的ID实体B的ID接触点法线等会被收集到一个线程安全的“事件流”或通过ECS的“碰撞事件组件”中。游戏逻辑系统可以随后读取这些数据播放声音、触发特效、计算伤害等。4. 实战从零构建一个DOTS物理碰撞演示理论说得再多不如亲手实践。下面我们来一步步搭建一个简单的演示看看如何用DOTS实现成千上万个实体的物理模拟。4.1 环境准备与项目设置首先你需要一个安装了最新版Unity Hub和Unity Editor建议2022.3 LTS或更新版本的环境。创建新项目使用“3D Core”模板创建项目。这个模板最干净。安装Package打开Package Manager安装以下关键包Entities(ECS核心)Entities Graphics(用于渲染ECS实体)Physics(DOTS物理引擎核心)Hybrid Renderer(V2) (用于将ECS实体渲染到场景注意版本)你可能还需要Unity.Collections、Unity.Mathematics等它们通常会作为依赖被自动安装。启用BurstBurst编译器通常已包含在Unity安装中确保它在Package Manager中已启用。4.2 创建可物理模拟的实体在DOTS中我们不再创建传统的GameObject而是通过代码或子场景来生成实体。方案一通过Authoring MonoBehaviour转换这是最常见的方式便于在编辑器中配置。using Unity.Entities; using Unity.Physics; using Unity.Physics.Authoring; using UnityEngine; public class SpawnerAuthoring : MonoBehaviour { public GameObject Prefab; public int Count; public float Radius; class Baker : BakerSpawnerAuthoring { public override void Bake(SpawnerAuthoring authoring) { var entity GetEntity(TransformUsageFlags.Dynamic); AddComponent(entity, new Spawner { Prefab GetEntity(authoring.Prefab, TransformUsageFlags.Dynamic), Count authoring.Count, Radius authoring.Radius }); } } } public struct Spawner : IComponentData { public Entity Prefab; public int Count; public float Radius; }创建一个空GameObject挂载此脚本并拖入一个预制体这个预制体需要包含PhysicsShapeAuthoring和PhysicsBodyAuthoring组件来定义碰撞体和刚体属性。方案二纯ECS代码生成在System中直接创建实体灵活性最高。using Unity.Entities; using Unity.Physics; using Unity.Transforms; using Unity.Mathematics; using Unity.Collections; public partial class SphereSpawnerSystem : SystemBase { protected override void OnCreate() { // 仅在开始时运行一次 RequireForUpdateSpawner(); } protected override void OnUpdate() { var spawner SystemAPI.GetSingletonSpawner(); var ecb new EntityCommandBuffer(Allocator.TempJob); // 使用随机数生成位置 var random Random.CreateFromIndex(1234); for (int i 0; i spawner.Count; i) { var newEntity ecb.Instantiate(spawner.Prefab); // 在一个球形范围内随机生成位置 float3 pos random.NextFloat3Direction() * random.NextFloat(0, spawner.Radius); ecb.SetComponent(newEntity, LocalTransform.FromPosition(pos)); // 赋予一个随机初始速度 float3 velocity random.NextFloat3Direction() * 10.0f; ecb.SetComponent(newEntity, new PhysicsVelocity { Linear velocity }); } ecb.Playback(EntityManager); ecb.Dispose(); // 移除Spawner组件防止下一帧再次生成 EntityManager.DestroyEntity(SystemAPI.GetSingletonEntitySpawner()); } }4.3 配置物理世界与碰撞过滤物理世界的全局属性通过PhysicsWorldIndex和PhysicsStep组件来配置。创建物理世界配置实体你可以创建一个空实体并为其添加PhysicsWorldIndex和PhysicsStep组件。PhysicsStep组件可以设置重力、求解器迭代次数等。碰撞过滤这是控制“谁和谁碰撞”的关键。每个PhysicsCollider组件在创建时都可以指定一个CollisionFilter。var filter new CollisionFilter { BelongsTo 1u 0, // 这个碰撞体属于第0组 CollidesWith ~(1u 1) // 与除了第1组之外的所有组都碰撞 }; var sphereGeometry new SphereGeometry { Center float3.zero, Radius 0.5f }; var collider Unity.Physics.SphereCollider.Create(sphereGeometry, filter);通过位掩码进行分组管理可以高效地实现复杂的碰撞关系例如子弹只打敌人玩家之间不互相碰撞等。4.4 编写系统驱动物理与响应碰撞物理模拟本身由PhysicsSystem等内置系统驱动。我们需要编写自己的System来响应碰撞事件。响应碰撞事件DOTS物理提供了几种方式。ICollisionEventsJob在一个Job中处理所有碰撞事件性能最好。public partial struct CollisionEventSystem : ISystem { public void OnUpdate(ref SystemState state) { var physicsWorld SystemAPI.GetSingletonPhysicsWorldSingleton(); var simulation SystemAPI.GetSingletonSimulationSingleton(); // 调度一个处理碰撞事件的Job state.Dependency new CollisionEventJob { // 通过Lambda表达式或IJobEntity方式处理事件 }.Schedule(simulation, ref physicsWorld, state.Dependency); } }CollisionEvent组件当碰撞发生时会自动为发生碰撞的实体添加一个CollisionEvent组件你可以在另一个System中查询并处理这些组件处理完毕后销毁该组件。这种方式更符合ECS的“数据驱动”思维。自定义物理行为你可以在System中直接修改实体的PhysicsVelocity或施加PhysicsForce来创造自定义的物理效果比如爆炸冲击波、磁力吸引等。5. 性能调优与深度避坑指南将百万实体跑起来是一回事跑得流畅是另一回事。以下是一些关键的调优点和常见陷阱。5.1 性能瓶颈分析与工具使用Profiler是你的第一工具务必使用Unity Profiler的Deep Profile模式特别是观察Jobs和Burst编译的线程执行情况。关注PhysicsSimulationGroup下的系统耗时。关键指标宽阶段耗时如果这里耗时高说明实体空间分布太散或BVH树更新开销大。考虑调整世界边界或实体密度。窄阶段耗时如果这里耗时高说明经过宽阶段筛选后候选对仍然太多或者碰撞体形状过于复杂如高精度凸包。主线程等待时间如果主线程长时间等待物理Job完成说明Job依赖关系可能没组织好或者有主线程上的阻塞操作如同步加载资源。5.2 实体与碰撞体设计的黄金法则简化碰撞形状永远使用能满足需求的最简单形状。顺序是球体 胶囊体 盒子 低顶点数的凸包 网格碰撞体。对于大量的小碎片用球体代替复杂形状能带来数量级的性能提升。合理设置碰撞层充分利用CollisionFilter。让不需要相互碰撞的物体处于不同的层可以极大减少宽阶段和窄阶段的计算量。这是最重要的优化手段之一。静态与动态分离将永远不会移动的静态环境碰撞体标记为Static。物理引擎会对它们进行特殊优化如更优的BVH构建。动态物体之间和动态与静态之间的检测通常是分开处理的。控制实体数量百万是理论极限在具体项目中要权衡。是否可以用粒子系统代替一部分物理实体是否可以用一个大的碰撞体代表一群小物体5.3 多线程与Job的安全陷阱Race Condition竞态条件这是多线程编程的头号敌人。确保你在一个Job中只写入一个组件或者使用NativeContainer如NativeQueue进行线程安全的数据传递。EntityCommandBuffer是跨线程安全创建/修改实体的利器。错误的依赖关系如果Job B需要Job A的结果你必须正确设置JobHandle的依赖关系JobHandle.CombineDependencies。依赖设置错误会导致逻辑错误或性能下降无法并行。Burst兼容性在Job中使用的所有代码和数据结构都必须是Burst兼容的。避免在Job中使用string、class、GameObject等托管类型。使用NativeArray代替List使用FixedString代替string。5.4 内存管理与泄漏排查Allocator的选择ECS中大量使用NativeContainer创建时必须指定分配器。Allocator.Temp帧生命周期最快但必须在同一帧的Job完成后销毁。Allocator.TempJob4帧生命周期适合在Job间传递数据。Allocator.Persistent长期存在手动管理用不好会导致内存泄漏。泄漏检查在编辑器的Jobs-Burst-Native Leak Detection中开启泄漏检测。任何未正确释放的NativeContainer都会在运行时抛出错误。实体泄漏同样确保不再需要的实体通过EntityManager.DestroyEntity或EntityCommandBuffer.DestroyEntity进行销毁。6. 进阶超越基础碰撞的扩展应用掌握了基础的碰撞检测DOTS物理引擎还能做更多酷炫的事情。6.1 触发器与查询非物理交互除了硬碰撞游戏还需要大量的“感知”逻辑比如进入一个区域触发剧情。这可以通过触发器和物理查询来实现。触发器将碰撞体的CollisionResponsePolicy设置为CollisionResponsePolicy.RaiseTriggerEvents它就不会产生物理阻力但会生成TriggerEvent事件你可以在System中处理这些事件。物理查询例如射线检测Raycast、形状重叠检测Overlap、最近点查询Closest Point。这些查询同样可以利用BVH进行加速并且可以在Job中并行执行。你可以一次性发射成千上万条射线来检测视线、火力瞄准等性能极高。6.2 自定义物理材质与碰撞响应通过PhysicsMaterial组件你可以定义物体的摩擦系数和恢复系数弹性。但DOTS物理也允许你更深入地介入碰撞响应过程。修改求解器输入在物理系统计算碰撞响应之前有一个ISimulationEvent阶段。你可以在这里获取到预求解的碰撞数据如速度、质量、接触点并对其进行修改从而实现自定义的物理效果比如“粘性”表面、速度依赖的摩擦力等。直接速度修改在碰撞事件处理Job中你可以直接读取碰撞双方的PhysicsVelocity并进行修改实现完全自定义的碰撞后行为无视标准的物理公式。6.3 与动画、VFX和游戏逻辑的集成物理引擎不是孤岛它的数据需要驱动其他系统。驱动动画将实体的PhysicsVelocity或角速度数据传递给动画系统可以用来混合“移动”状态机或者驱动 procedural animation程序化动画比如根据速度摆动披风。触发特效在碰撞事件处理System中可以根据碰撞强度相对速度和碰撞点位置命令VFX系统生成火花、灰尘等粒子效果。这里可以通过EntityCommandBuffer异步创建特效实体。游戏逻辑伤害计算、得分、任务触发等都可以基于碰撞事件中的数据谁撞了谁撞在哪里有多快来驱动。这完美体现了ECS“数据驱动”的理念物理系统产出碰撞数据其他系统消费这些数据。7. 常见问题与实战排错记录在实际项目中你一定会遇到各种光怪陆离的问题。下面是我踩过的一些坑和解决方案。问题1实体生成后一动不动像被冻住了。排查首先检查实体是否拥有PhysicsVelocity组件。如果没有它就是静态的。其次检查PhysicsWorldIndex和PhysicsStep组件是否存在于世界中至少有一个实体拥有它们。最后检查碰撞体是否被正确创建特别是Collider的Size是否不为零。心得给新生成的动态物理实体一个非零的初始速度是快速验证物理系统是否工作的好方法。问题2性能随着实体数量增加急剧下降但Profiler显示物理耗时并不高。排查这很可能不是物理引擎本身的问题。检查渲染部分。你是否为每个实体都实例化了一个完整的GameObject进行渲染这会导致Draw Call爆炸。应该使用ECS专用的渲染方案如MeshInstanceRendererComponent或最新的Entities Graphics它能够合批渲染成千上万个相同网格的实体。心得在DOTS项目中渲染往往是比物理更大的瓶颈。确保采用面向数据的渲染管线。问题3碰撞事件有时触发有时不触发或者触发对象不对。排查99%的原因是CollisionFilter设置错误。仔细检查发生碰撞的双方实体的BelongsTo和CollidesWith位掩码。使用Debug.Log或UnityEngine.Debug.DrawLine在编辑器中可视化调试碰撞关系。另一个可能是碰撞体太小或相对速度太快导致“隧道效应”一帧穿过去了。可以尝试启用连续碰撞检测CCD但会显著增加性能开销。心得为不同的物体类型玩家、敌人、子弹、环境定义好清晰的碰撞层枚举并在代码中集中管理避免硬编码的魔数。问题4Burst编译错误提示某些代码不支持。排查Burst不支持在Job中使用try-catch、string.Format、虚函数调用、访问托管对象等。仔细阅读错误信息它会指出哪一行代码有问题。常见的解决方法是将复杂的字符串操作移到主线程使用FixedString避免在Job中调用非Burst兼容的第三方库。心得尽量让Job中的逻辑保持纯粹和简单只做数学计算和数据搬运。复杂的业务逻辑和资源管理放在主线程的System中。问题5在编辑器里运行正常打包后物理行为不一致或崩溃。排查首先检查所有NativeContainer的分配和释放是否成对出现特别是在不同场景切换时。其次确保Burst编译在发布模式下是开启的有时开发中会关闭用于调试。最后检查是否有依赖于编辑器特定顺序的初始化逻辑在独立的玩家进程中执行顺序可能不同。心得养成在打包后立即进行基础功能测试的习惯。使用Development Build并启用日志可以在真机或打包环境中看到错误输出。
