1. 物理与动画系统在游戏引擎中的定位与整体设计
1.1 为什么物理和动画是引擎架构里最难啃的两块骨头
做引擎开发的人都有一个共识：渲染管线可以靠堆人力优化，脚本层可以靠热重载提升迭代速度，唯独物理和动画这两块，一旦架构设计出了问题，后期几乎不可能靠打补丁救回来。原因很简单——它们都是强状态、强时序、强耦合的子系统。
物理系统每一帧要处理成百上千个刚体的碰撞检测、约束求解、积分更新，任何一个环节的精度损失都会在几十帧后放大成肉眼可见的穿模或抖动。动画系统则要在毫秒级时间内完成骨骼层级变换、蒙皮矩阵计算、状态机切换、动画混合，同时还要和物理驱动的布娃娃系统、IK 反向动力学做数据交换。这两个系统之间还存在双向依赖：物理可以驱动动画（比如角色被击飞时的布娃娃效果），动画也可以反过来影响物理（比如动画驱动的碰撞体位置更新）。
我在实际项目里踩过最典型的一个坑，就是早期把物理更新和动画更新放在同一个线程里串行执行，结果角色移动速度一快，动画的根骨骼位移和物理胶囊体的位置就对不上，出现角色"滑步"的现象。后来把物理更新拆到固定时间步长的独立循环里，动画更新保持在渲染帧率上做插值，问题才彻底解决。这个经历让我深刻理解了一件事：物理和动画的更新频率、时间基准、数据流向，必须在架构设计的第一天就定清楚。
1.2 物理系统的核心架构分层
一个成熟的物理系统在架构上通常分为四层，从下往上依次是：
- 数学基础层：向量、矩阵、四元数、AABB/OBB 包围盒、射线、平面等几何图元。这一层看起来简单，但精度问题往往就出在这里。比如用 float 存储世界坐标时，当坐标值超过 10000 之后，浮点精度会下降到 0.001 左右，对于高速运动的物体来说这就是穿模的根源。
- 碰撞检测层：分为粗检测（Broad Phase）和精检测（Narrow Phase）。粗检测用空间划分结构快速筛掉不可能碰撞的物体对，精检测对候选对做精确的相交测试并生成接触点。
- 约束求解层：把接触点、关节、马达等统一抽象为约束，用迭代求解器（通常是序列脉冲求解器或投影高斯-赛德尔求解器）计算出每个刚体应该受到的冲量。
- 积分更新层：根据求解出的冲量更新速度，再根据速度更新位置。这里涉及到积分器的选择，半隐式欧拉是最常用的，因为它在稳定性和计算量之间取得了很好的平衡。
注意：很多新手会跳过粗检测直接做两两碰撞测试，物体数量到 200 个以上时帧率就会崩掉。粗检测不是可选项，是必选项。
1.3 动画系统的架构演进路线
动画系统的架构经历了从简单到复杂的演进。最早期的引擎就是直接播放骨骼动画片段，没有任何混合逻辑。后来出现了动画状态机，用节点图的方式管理动画切换。再往后发展出动画图（Animation Graph），支持分层混合、遮罩、骨骼过滤等高级功能。
现代引擎的动画架构通常包含以下几个核心模块：
- 动画数据层：存储关键帧数据、曲线数据、压缩后的骨骼变换。这里的关键是压缩策略，原始的关键帧数据量非常大，一个 30 骨骼的角色跑 10 秒动画，未压缩数据可能超过 5MB。
- 动画采样层：根据当前时间从关键帧中插值出骨骼变换。插值方式有线性插值、球面线性插值（用于旋转）、三次样条插值等。
- 动画混合层：把多个动画片段的采样结果按权重混合。混合可以在局部空间做，也可以在世界空间做，各有优劣。
- 动画状态管理层：决定当前应该播放哪些动画、权重是多少、何时切换。这是游戏逻辑和动画数据之间的桥梁。
- 骨骼变换层：把混合后的局部变换转换成世界变换，再计算蒙皮矩阵传给 GPU。
1.4 物理与动画的耦合设计原则
物理和动画的耦合是架构设计中最容易出问题的地方。我的经验是遵循三条原则：
第一，数据流向要单向清晰。要么物理驱动动画，要么动画驱动物理，不要双向同时驱动，否则会出现反馈震荡。如果确实需要双向，必须加阻尼或约束。
第二，时间步长要解耦。物理用固定时间步长（通常是 1/60 秒或 1/120 秒），动画用可变时间步长跟随渲染帧率。两者之间通过插值或外推来同步。
第三，碰撞体和骨骼要分离。不要让物理引擎直接操作骨骼，也不要让动画系统直接操作碰撞体。中间应该有一层映射关系，把骨骼的动画姿态转换成物理碰撞体的目标位置，再由物理引擎去求解。
2. 物理系统核心细节与实操要点
2.1 碰撞检测的粗检测结构选型
粗检测的核心是空间划分结构，常用的有四种：均匀网格、四叉树/八叉树、BVH（包围体层次结构）、空间哈希。
均匀网格适合物体分布均匀且大小相近的场景，实现简单，查询速度快。但如果物体大小差异很大，小物体在大网格里会浪费大量空间，大物体又会跨越多个网格。我一般只在 2D 游戏或者物体尺寸统一的场景里用。
四叉树/八叉树适合静态场景或者变化不频繁的场景。构建成本较高，但查询效率好。动态物体频繁移动时，树的更新会成为瓶颈。
BVH 是目前 3D 引擎里最常用的结构。它把物体按层次组织成树，每个节点是一个包围盒。BVH 的优点是适应性强，物体大小差异大也没问题，而且支持增量更新。缺点是树的平衡性依赖构建算法，不好的构建算法会导致查询效率下降。
空间哈希适合物体数量多但分布稀疏的场景。它把空间划分成固定大小的格子，用哈希表存储每个格子里的物体。优点是插入和删除都是 O(1)，缺点是格子大小需要调参，而且哈希冲突会影响性能。
我在一个开放世界项目里做过对比测试，场景里有 5000 个动态物体，分布在一个 2km x 2km 的区域内。均匀网格的粗检测耗时约 2.3ms，四叉树约 1.8ms，BVH 约 1.2ms，空间哈希约 1.5ms。最终选了 BVH，因为它的性能最稳定，不会因为物体分布变化而剧烈波动。
2.2 精检测的算法选择与精度控制
精检测阶段要处理具体的图元对：球-球、球-胶囊、胶囊-胶囊、凸包-凸包等。最复杂的是凸包-凸包，通常用 GJK 算法加 EPA 算法来求解。
GJK 算法用来判断两个凸包是否相交，它的核心思想是在闵可夫斯基差空间里寻找原点。如果原点在差空间内，说明两个凸包相交。EPA 算法则在 GJK 的基础上继续扩展，找到最小穿透向量，也就是把两个物体分开所需的最短距离和方向。
这里有一个实操中很容易忽略的点：GJK 的迭代次数上限。默认情况下 GJK 可能迭代 20 次就停止，但对于一些特殊形状（比如非常扁的盒子），20 次可能不够，导致检测结果不稳定。我的做法是把上限提高到 64 次，同时加一个收敛阈值，当两次迭代的结果差异小于阈值时就提前退出。
另一个坑是接触点的生成。两个物体相交时，接触点可能是一个点、一条线或者一个面。如果只生成一个接触点，物体会绕着这个点旋转，产生抖动。正确的做法是生成多个接触点，通常 4 个就够，分布在接触面上。这样约束求解器才能计算出稳定的冲量。
2.3 约束求解器的参数调优
约束求解器是物理系统的心脏。目前主流的是序列脉冲求解器（Sequential Impulse Solver），它的核心思想是逐个约束地迭代求解，每次迭代只处理一个约束，但多次迭代后整体会收敛。
求解器的关键参数有三个：
- 迭代次数：默认通常是 8-10 次。迭代次数越多，约束越稳定，但计算量也越大。对于堆叠的物体（比如一摞箱子），迭代次数需要提高到 20 次以上才能稳定。
- 松弛因子：控制每次迭代的修正幅度。太大会震荡，太小会收敛慢。通常设在 0.1-0.3 之间。
- 穿透容差：允许物体之间有多少穿透量。设得太小会导致物体被弹开，设得太大又会出现明显的穿模。一般设在 0.01-0.05 米之间。
我调过一个堆叠场景，20 个箱子叠在一起，初始参数是迭代 10 次、松弛因子 0.2、穿透容差 0.02。结果箱子会缓慢下沉，10 秒后下沉了约 0.5 米。把迭代次数提高到 25 次，松弛因子降到 0.15，下沉速度明显减缓，但仍有约 0.1 米的下沉。最后加了位置修正（Position Correction）才彻底解决，位置修正会在速度求解之后额外做一次位置调整，把穿透的物体推回正确位置。
2.4 物理材质与碰撞过滤
物理材质定义了摩擦系数和恢复系数（弹性）。摩擦系数决定了物体在表面上滑动时的阻力，恢复系数决定了碰撞后的反弹程度。
这里有一个常见的误区：很多人以为摩擦系数就是"越粗糙越大"，但实际上静摩擦和动摩擦是分开的。静摩擦是物体开始滑动前需要克服的力，动摩擦是滑动过程中的阻力。静摩擦通常大于动摩擦，这就是为什么推一个重箱子时，刚开始推不动，一旦推动了就轻松了。
碰撞过滤则是控制哪些物体之间会发生碰撞。通常用位掩码（Bitmask）来实现，每个物体有一个碰撞组和一个碰撞掩码，只有当两个物体的组和掩码互相匹配时才会碰撞。这个机制在游戏里非常有用，比如角色的胶囊体不应该和自身的武器碰撞，但应该和敌人的武器碰撞。
提示：碰撞过滤的位掩码不要超过 32 位，因为大多数引擎用 32 位整数存储。如果需要更多分组，可以用多层过滤或者自定义过滤回调。
3. 动画系统核心细节与实操要点
3.1 骨骼动画的数据压缩策略
骨骼动画的数据量是很大的。一个角色如果有 60 根骨骼，每根骨骼有位置、旋转、缩放三个通道，每个通道用 4 个 float 存储，一帧就是 60 x 3 x 4 x 4 = 2880 字节。如果动画有 30 帧每秒，时长 10 秒，那就是 2880 x 30 x 10 = 864KB。一个游戏里如果有 100 个这样的动画，数据量就接近 90MB。
压缩策略主要有三种：
第一种是关键帧抽稀。不是每一帧都存，而是只存关键帧，中间用插值补出来。抽稀的阈值需要根据动画的曲率来定，曲率大的地方多存，曲率小的地方少存。
第二种是量化压缩。把 float 量化成 16 位整数甚至 8 位整数。旋转用四元数存储时，可以只存三个分量，第四个分量通过归一化计算出来。这样旋转数据可以从 16 字节压缩到 6 字节。
第三种是曲线拟合。用多项式或者样条曲线拟合动画数据，只存曲线参数。这种方法压缩率最高，但拟合误差也最大，适合对精度要求不高的动画。
我在项目里用的是量化压缩加关键帧抽稀的组合方案。旋转用 16 位量化，位置用 16 位量化，缩放通常不变所以只存一个值。抽稀阈值设为 0.5 度，低于这个角度的变化不存关键帧。最终数据量压缩到了原来的 15% 左右，肉眼几乎看不出差异。
3.2 动画混合的数学原理与实现
动画混合的本质是在两个或多个姿态之间做插值。最简单的线性混合就是加权平均：
最终姿态 = 权重1 * 姿态1 + 权重2 * 姿态2 + ... + 权重N * 姿态N但这里有一个问题：旋转不能用线性插值。两个四元数直接做线性插值再归一化，虽然能得到一个合法的旋转，但角速度不均匀，会出现"加速-减速"的现象。正确的做法是用球面线性插值（Slerp），它保证角速度均匀。
Slerp 的公式是：
Slerp(q1, q2, t) = (sin((1-t)*θ) / sinθ) * q1 + (sin(t*θ) / sinθ) * q2其中 θ 是两个四元数之间的夹角。这个公式计算量比线性插值大，但效果明显更好。
对于多个动画的混合，通常用累加混合（Additive Blending）。先选一个基础动画，然后把其他动画作为"增量"叠加到基础动画上。增量动画存储的是相对于参考姿态的偏移量，这样混合时只需要把偏移量加权累加即可。
3.3 动画状态机的设计模式
动画状态机是管理动画切换的核心模块。最简单的实现是一个有限状态机，每个状态对应一个动画，状态之间有转换条件。
但实际项目里，简单的有限状态机会很快变得难以维护。一个角色可能有待机、行走、跑步、跳跃、攻击、受击、死亡等状态，状态之间的转换条件可能涉及十几个参数。这时候就需要更高级的设计模式。
我常用的是分层状态机加混合树的组合。分层状态机把动画分成几个层：基础层（移动）、上半身层（攻击、施法）、表情层（面部动画）。每层独立管理自己的状态，层与层之间通过遮罩（Mask）来控制影响范围。比如上半身层只影响上半身的骨骼，不影响腿部的行走动画。
混合树则用来处理同一状态内的动画变化。比如行走状态，速度从 0 到 5 米每秒，对应从走到跑的过渡。混合树可以根据速度参数自动混合走路和跑步动画，不需要手动切换状态。
3.4 反向动力学（IK）的实操要点
IK 是用来解决"手要放在某个位置，但手臂骨骼怎么旋转"这类问题的。最常见的应用是脚部 IK，让角色的脚在不同坡度的地面上都能正确贴合。
IK 的求解算法有两类：解析法和迭代法。解析法适用于两骨骼链（比如大腿和小腿），可以直接用三角函数算出关节角度。迭代法适用于多骨骼链，常用的是 CCD（循环坐标下降）和 FABRIK。
CCD 的思路是从末端骨骼开始，依次旋转每根骨骼，让末端尽可能靠近目标点。迭代几次后就能收敛。FABRIK 则是先调整骨骼位置，再反推旋转，收敛速度更快。
我在做脚部 IK 时踩过一个坑：直接对脚部做 IK，结果膝盖会向外翻。原因是 IK 只考虑了位置约束，没有考虑关节的角度限制。后来加了膝盖的极向量约束（Pole Vector），指定膝盖应该朝向的方向，问题才解决。
注意：IK 不要每帧都从头求解，可以用上一帧的结果作为初始值，这样迭代次数可以减少一半以上。
4. 物理与动画的协同实战
4.1 布娃娃系统的实现细节
布娃娃系统是物理和动画协同的典型案例。角色死亡时，从动画驱动切换到物理驱动，让身体各部位自然倒下。
实现布娃娃的关键是骨骼到刚体的映射。每根骨骼对应一个刚体，刚体之间用关节连接。关节的角度限制要参考人体关节的活动范围，比如肘关节只能单向弯曲，膝关节不能反向弯曲。
切换时有一个难点：动画姿态和物理姿态的衔接。如果直接切换，物理刚体会从动画姿态的当前位置开始模拟，但动画姿态可能不满足物理约束（比如关节角度超出了限制），导致刚体突然弹开。正确的做法是在切换时先做一次约束求解，把物理姿态调整到满足约束的状态，再开始模拟。
另一个难点是布娃娃的稳定性。布娃娃的刚体数量多，关节链长，很容易出现抖动或者爆炸。我的经验是：降低布娃娃的求解精度要求，增加阻尼，限制最大速度。布娃娃不需要像角色控制器那样精确，看起来自然就行。
4.2 物理驱动动画的根骨骼匹配
角色移动时，动画的根骨骼位移和物理胶囊体的位移需要匹配。如果不匹配，就会出现滑步或者脚陷进地面的现象。
匹配的方法有两种：一种是动画驱动物理，即动画的根骨骼位移直接设置物理胶囊体的位置。这种方法简单，但物理碰撞的反馈无法影响动画，角色撞墙时动画还在往前走。
另一种是物理驱动动画，即物理胶囊体根据输入和碰撞计算出实际位移，然后把位移传给动画系统，动画系统用这个位移来调整根骨骼。这种方法更真实，但需要动画系统支持根骨骼偏移。
我通常用混合方案：物理胶囊体负责碰撞检测和实际位移计算，动画系统根据物理位移和动画原始位移的差值来调整根骨骼。这样既保证了碰撞的正确性，又保留了动画的自然感。
4.3 性能优化：物理和动画的并行化
物理和动画都是计算密集型任务，在多核 CPU 上并行化是必然选择。
物理的并行化相对容易，因为刚体之间的计算是独立的。可以把刚体分组，每组在一个线程上做碰撞检测和积分更新。但约束求解是串行的，因为约束之间会相互影响。常用的做法是图着色算法，把不相关的约束分到同一组，组内并行，组间串行。
动画的并行化更复杂，因为骨骼之间有层级依赖。子骨骼的世界变换依赖父骨骼的世界变换，不能简单地并行。但可以用拓扑排序把骨骼分层，同一层的骨骼可以并行计算。对于 60 根骨骼的角色，通常能分成 8-10 层，并行度还是不错的。
我在一个项目里做过测试，物理和动画都并行化之后，在 8 核 CPU 上整体耗时从 6.2ms 降到了 2.8ms，提升了一倍多。但要注意线程同步的开销，如果任务粒度太小，同步开销会抵消并行收益。
4.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方法 | 解决方案 |
|---|---|---|---|
| 物体抖动 | 约束求解迭代次数不足 | 增加迭代次数观察是否改善 | 提高迭代次数到 20 以上 |
| 物体穿模 | 时间步长过大或碰撞检测遗漏 | 减小时间步长测试 | 启用连续碰撞检测（CCD） |
| 角色滑步 | 动画根骨骼与物理位移不匹配 | 对比动画位移和物理位移 | 启用根骨骼匹配 |
| 动画切换突兀 | 混合时间太短 | 增加混合时间测试 | 设置 0.2-0.3 秒的混合过渡 |
| 布娃娃爆炸 | 关节约束不满足或速度过大 | 检查关节角度限制 | 增加阻尼，限制最大速度 |
| IK 膝盖外翻 | 缺少极向量约束 | 观察膝盖朝向 | 添加极向量约束 |
| 物理帧率波动 | 粗检测结构不适应物体分布 | 统计粗检测耗时 | 换用 BVH 或调整网格大小 |
5. 架构选型的经验与建议
5.1 自研还是用现成物理引擎
这是每个引擎团队都会面临的问题。我的建议是：除非你的游戏有非常特殊的物理需求（比如大规模破坏、流体模拟），否则不要自研物理引擎。
自研物理引擎的坑太多了：数值稳定性、碰撞检测的边界情况、约束求解的收敛性、多线程安全……每一个都需要大量的测试和调优。Bullet、PhysX、Jolt 这些成熟的物理引擎都是经过十几年迭代的，代码质量和稳定性远超一般团队的自研水平。
但用现成引擎也有代价：性能特征不可控、调试困难、定制化受限。我的做法是：核心物理用成熟引擎，但在外面包一层适配层，把引擎的 API 隔离起来。这样将来如果要换引擎，只需要改适配层，不需要改游戏逻辑。
5.2 动画系统的架构选择
动画系统的选择相对灵活一些。如果项目规模不大，用引擎自带的动画系统就够了。如果项目有特殊的动画需求（比如大量角色同屏、复杂的动画图），可能需要自研或者深度定制。
自研动画系统的核心是数据管线和运行时的分离。数据管线负责把美术做的动画数据转换成引擎可用的格式，运行时负责采样、混合、状态管理。这两部分应该解耦，数据管线的改动不应该影响运行时。
我在项目里用的方案是：数据管线用 Python 脚本实现，运行时用 C++ 实现。数据管线输出的格式是自定义的二进制格式，运行时直接读取。这样美术可以在不重新编译引擎的情况下更新动画数据。
5.3 物理和动画的调试工具
调试工具的重要性怎么强调都不为过。物理和动画的问题往往很难复现，没有好的调试工具，排查效率会极低。
物理调试工具需要能可视化碰撞体、接触点、约束、受力方向。最好还能暂停、单步、回放。我习惯在引擎里加一个物理调试模式，按快捷键就能切换。
动画调试工具需要能显示骨骼层级、当前播放的动画、混合权重、状态机状态。如果能实时调整参数并立即看到效果，调试效率会高很多。
提示：调试工具不要等到项目后期才做，应该在物理和动画系统开发的第一天就开始做。前期投入的时间，后期会十倍地省回来。
5.4 跨平台适配的注意事项
物理和动画系统在不同平台上的表现可能有差异。浮点精度是最常见的问题，x86 和 ARM 的浮点运算结果可能不同，导致物理模拟的结果不一致。如果游戏有回放或者联网同步的需求，这个问题必须解决。
解决方案有两种：一是用定点数代替浮点数，保证所有平台的计算结果完全一致。二是用浮点数，但在关键计算后做量化，把差异控制在可接受范围内。定点数的精度有限，适合物理模拟；浮点数量化适合动画采样。
我在一个联网项目里用的是定点数物理，精度设为 1/1024 米。这个精度对于大多数游戏场景足够了，而且所有平台的计算结果完全一致，回放和同步都没有问题。
