如果你已经跟着前两篇把渲染管线和资源系统搭起来了那么接下来真正让一套引擎“活过来”的部分就是物理与动画这一对搭档。物理解决“物体之间的运动关系”动画解决“角色姿态随时间的变化”看起来两条线各走各的但它们在引擎架构里共享同一份逻辑时钟、服务于同一个渲染帧、最终都写进同一个场景对象树。这篇我按第三篇的经验总结来写把物理与动画放在一起讲不是因为它们抄了同一段代码而是因为两者的耦合点——角色控制器、布娃娃切换、脚部IK贴合——恰恰是架构设计最容易出恶性问题的地方。自己从零写引擎的人、正在给引擎做功能集成的客户端团队还有想搞懂官方引擎内部调度逻辑的同学这篇应该都能对得上号。1. 物理与动画在引擎架构中的真实定位以及为什么它们必须被一起设计先说一个容易被忽略的事实物理和动画都是“时间步进”系统但它们的步进节奏完全不一样。物理系统几乎从诞生起就走固定步长比如每步 1/60 秒或者 1/120 秒因为数值积分在变步长下会飘碰撞求解器的收敛性也依赖稳定步长。动画系统则更偏向渲染帧驱动——它按播放线性采样按状态机跳转按帧率插值不要求物理意义上的稳定。架构层面的第一个难题就在这两个节奏不同的系统怎么在同一个渲染帧里给出对齐的结果。我的做法是把时钟分成三层渲染时钟、动画采样时钟、物理步进时钟。渲染时钟就是实打实的那一帧动画采样时钟可以跟随帧率但要做平滑钳制物理步进时钟则是独立累加器不受渲染帧率波动干扰。每次渲染帧结束时物理系统把刚体状态写到组件里动画系统把骨骼姿态写到骨架组件里渲染层只消费这两个结果。听起来简单但如果你没有在数据结构上把“物理结果”和“动画结果”做成可插值、可缓存的对象后面做回放、做断点调试、做网络同步都会非常痛苦。物理与动画之所以必须一起设计还有一个更现实的原因它们共同占据 CPU 帧预算的大头。主机平台上物理大概占 1.5~2ms动画采样加骨骼计算差不多 3~4ms合起来几乎快赶上半程渲染的 CPU 开销。如果架构上允许物理撞动动画、动画回写物理的位置那每一帧就会产生循环依赖调度器根本没法并行化。所以我在引擎里强制约定动画系统每帧只读“上一帧物理结果”物理系统每帧只读“上一帧动画姿态”二者通过延迟一帧的组件缓存解耦。延迟一帧对大多数玩法感知极小但换来了两个系统都能独立并行这个取舍非常划算。还有一点值得写进架构文档物理和动画虽然“不画像素”但它们直接影响画面可信度。物理抖动一帧玩家会觉得“飘”动画过渡闪一下玩家会觉得“假”。玩家嘴上说不上来哪里不对但手感和沉浸感就是这样一点点累积起来的。所以这一块的设计目标不是“跑得通”而是“在极端帧率波动下看起来也顺”。1.1 物理系统固定步长下的数值模拟器物理核心可以简化成一句话每步推进一个固定时间片计算所有外力积分所有刚体速度解算所有约束更新所有位置。这里的“约束”不只是关节还包括碰撞接触点、摩擦、马达等。结构上它是一个非常典型的“模拟器”没有渲染概念不关心摄像机只关心一个独立的物理世界。我见过很多从零写物理的团队在第一版就把“刚体”和“碰撞体”混成同一个类结果后面想加“静态场景碰撞体”时被迫重构。正确分层是至少拆成四个类型刚体动力学属性速度、力、质量、惯性张量、碰撞体形状属性盒、球、凸体、三角网格、物理材质摩擦、恢复系数、约束关节、接触约束。刚体可以被禁用碰撞但保留动力学也可以反过来只有碰撞体没有刚体。把这个数据结构理清楚物理引擎的迭代成本会低很多。物理引擎在架构里通常作为独立库存在但主引擎要给它包一层门面组件负责创建刚体、同步位置、上报碰撞回调。这层门面决定了物理库的可替换性——你前期用开源方案后期想换商业方案应该只动门面不动游戏层代码。1.2 动画系统状态驱动下的姿态生成器动画系统解决的是“给定当前角色状态生成一帧骨骼姿态”。核心数据结构是骨骼层级每块骨骼保存相对于父骨骼的本地变换最终通过自顶向下的矩阵连乘得到世界空间姿势。动画资源本身只是一组曲线每条曲线对应一个骨骼节点的某个通道位移、旋转、缩放采样频率常见 30Hz 或 60Hz。关键点在于动画系统并不一定每一帧都重新采样所有曲线。为了省 CPU我用了两级缓存第一级缓存原始采样数据解压后按字节保存第二级缓存上一帧已经算好的骨骼矩阵。只有当状态机发生跳转、混合权重改变、时间轴前进时才触发重采样。大部分休闲场景里角色站着不动时动画系统可以直接跳过整棵骨骼树的更新这个优化省下的开销比你想象的还大。动画状态机则是把“游戏状态想要的动作”翻译成“具体播放哪一段动画”的逻辑层。它的输入是速度、朝向、动作标签、受击信号输出是当前激活的动画 clip、播放时间、和过渡参数。架构设计上我倾向于让状态机完全独立于骨骼计算甚至可以做成纯数据驱动的表让策划在编辑器里填状态转移条件而不是让程序写死在代码里。1.3 为什么架构文档里总把它们放在同一篇物理和动画在引擎组织里经常归到同一个模块原因有三。第一它们都产生“每帧变化的变换数据”这些数据最终要被渲染层消费而渲染层需要统一的接口去读姿势矩阵和刚体变换。第二它们都涉及“插值”和“重采样”物理要做结果插值来消除步长抖动动画要做混合插值来平滑过渡插值本质上是同一套数学工具抽象出来可以复用。第三也是最重要的角色控制器这种对象天然同时依赖两者角色移动方向由动画状态机决定角色碰撞体积又受物理约束。如果不把两者放在同一个模块的视野里角色控制器会被撕成两半维护成本直线上升。2. 物理核心链路拆解从候选对筛选到约束求解这一节我把物理引擎的运行链路按阶段拆开讲每个阶段都会说清楚“为什么必须这么做”以及“不做会出什么问题”。物理模拟最核心的执行顺序是宽相位碰撞检测、窄相位碰撞检测、刚体积分、约束求解、位置修正。这个顺序不能随便换因为碰撞检测需要用到当前刚体的速度和外力而约束求解又依赖碰撞检测给出的接触点列表。2.1 宽相位碰撞检测先快速筛掉明显不碰的组合宽相位的任务不是“精确检测”而是“用很低廉的成本把明显不相交的对子排除掉”。最简单实用的方案有几种统一网格把世界按格子划分只看同格子或邻格子的物体、SAP扫描剪枝适合物体分布相对均匀的场景、以及层次包围盒BVH适合大量静态与少量动态物体的组合。我用得最多的是动态物体的 BVH 加静态场景的二分网格。动态物体数量通常不多几百个刚体建一棵 BVH 每帧更新完全来得及静态场景体量巨大用网格预计算可以避免每帧都遍历一棵巨大的树。宽相位产出一组“可能碰撞对”交给窄相位去精确处理。别小看这个阶段的排序和剔除逻辑宽相位做得好窄相位可能只需要处理几十对做得差窄相位压力翻倍被打穿问题也就随之而来。2.2 窄相位碰撞检测精确计算接触点与穿透深度窄相位阶段需要回答两个问题到底碰没碰如果碰了接触点在哪儿、穿透了多深对凸体之间有现成算法GJK 负责判定距离和分离轴方向EPA 在 GJK 判定穿入后继续扩展单纯形来得到最小穿透深度。这两种算法配合稳定是物理库常用的组合。对长方体、胶囊体等简单形状其实还有更快的手写近路比如分离轴定理SAT在形状简单时比 GJK 更直接不过要处理退化情况。这里有一个工程细节特别值得提碰撞检测的结果不能只算一次因为物理步进里刚体在运动接触点可能在下一步就失效。所以很多物理库会做“接触持久化”把上一帧的接触点缓存下来用于新接触点的首次猜测再配合约束求解做平滑。持久化做得好堆叠体就不容易抖动做不好箱子落在地面上会跟跳跳球一样弹来弹去。2.3 刚体积分与约束求解数字“手感”的真正来源刚体的运动方程看起来简单速度对时间积分得到位置力的累加除以质量得到加速度。但离散化的时候积分器选错结果就是灾难。显式欧拉积分——用当前速度直接更新位置——在帧率不足时会导致能量增长物体越蹦越高。我在物理系统里固定用“半隐式欧拉”先用当前帧的力更新速度再用这一帧更新后的速度更新位置。这一改数值上的稳定区域大幅提升是几乎所有主流物理库的标准做法。刚体积分之后紧接着是约束求解。约束包括接触约束物体不能穿透、关节约束两个刚体的相对变换被限制、以及马达约束。工程上最主流的解法是顺序冲量法建立约束的雅可比矩阵把约束力转化为施加在刚体上的冲量然后对每个约束反复迭代修正相对速度。迭代次数很关键太少会出现弹性残留太多则浪费 CPU。我在项目中把默认迭代次数设为 8 到 12 次堆叠场景适当加到 20 次层数越多迭代需求越大。可以这样理解每一次迭代都是对约束系统的“粗调”刚体数量多、约束链长就需要多调几次。稳定性的另一个细节是误差消除。约束求解并不能完美满足所有约束位置约束经过速度级求解之后仍会残留微小穿透。一种直观的补偿方式是把位置误差按比例转化为速度修正量注入下一轮求解。但这个系数不能调太大否则物体接触瞬间会获得不合理的速度冲量看起来像被“弹了一下”。一般取值 0.1 到 0.3 是安全的。2.4 摩擦、恢复系数和材质参数的表驱动同样材质要想反复调整并保持一致的物理手感就一定要做表驱动。我维护一张物理材质表行和列分别代表两个接触材质表格里填摩擦系数和恢复系数而不是在每个碰撞体上单独写死数字。换材质只需改表格不需改代码逻辑这本来就是物理系统被外部配置化的标准思路。这里有个常见坑摩擦系数和恢复系数是“两者之间的参数”如果不做材质配对表你根本没法让“铁球撞木箱”和“木球撞铁箱”得到稳定一致的效果。3. 动画系统的资源与逻辑骨骼、蒙皮和状态驱动动画系统的定位是“姿态生成器”它不负责规则地运动只负责把动画资源播放成最终骨骼矩阵。但这层逻辑再往下拆还能分为资源层、采样层、混合层和输出层每一层都要和引擎的资产加载系统、组件系统做边界切割。3.1 骨骼与蒙皮从动画曲线到顶点变形骨架的根节点往往在角色的髋部或脚底子骨骼依次连接。材质资源里记录的只是相对于绑定姿势的矩阵偏移。动画播放时对每条曲线做时间采样得到该骨骼相对父骨骼的本地变换然后从根开始做矩阵连乘生成每个骨骼的世界变换。这里的开销主要来自链的深度每根骨头对它的所有祖先做一次矩阵乘法人形骨架一般 40~80 根骨头一帧需要几百次矩阵连乘。数量级不算大但在大批量单位动画并存的场景里累计成本很可观。网格蒙皮把顶点绑定到最多四根骨骼上每根骨骼分配一个权重顶点最终位置是这四根骨骼变换后的位置加权平均。这就是最常用的线性蒙皮LBS。线性蒙皮有个经典问题在关节旋转接近 180 度时网格会出现“塌陷”或“卷糖纸效应”。双四元数蒙皮DQS能改善这类问题但涉及比较复杂的数据转换而且并不是所有模型都需要。我自己的取舍是维持 LBS 作为默认因为大多数动作游戏不会出现极端弯曲而 DQS 在大量顶点并行的场景里可能反而带来额外计算量。动画采样频率和资源压缩也需要在架构层留好接口。这里涉及到存储与 CPU 的权衡骨骼动画数据经过量化压缩后体积大幅缩小但解压需要额外计算。对于移动平台我倾向于保精度压缩对于 PC 主机更看重解压速度。正确的做法是把压缩解压做成可替换的编解码器资源系统只负责给动画系统一个“可寻址的曲线容器”。3.2 动画状态机让游戏逻辑决定播哪段动画动画状态机是连接玩法逻辑和动画资源之间的一层胶水。它接收的输入通常包括移动速度、移动方向、是否落地、是否持械、当前受击阶段等。这些输入经过状态转移条件判断决定角色处于哪个动画状态每个状态内再指定播放哪条动画 clip。常见实现是一张状态表每条记录包含来源状态、目标状态、转移条件、过渡时长和是否允许打断。过渡时长的选择是手感的关键。过渡过短动画切换时姿态会瞬间跳变过渡过长玩家输入后反应很“肉”。我在动作游戏项目里的经验是技能释放类的切换过渡控制在 50~100 毫秒移动转向类的过渡控制在 100~200 毫秒受击与硬直切换控制在 30 毫秒以内。另外不是所有转移都需要完整走混合如果两个动画在同一姿势附近所谓过渡其实就是下一帧直接切换。3.3 混合空间多动画连续插值的正确姿势当角色需要根据任意移动方向播放“左前、前、右前、左、右……”时单个 clip 没法覆盖所有方向。混合空间就是解决这个问题的把一组同构动画按参数轴摆放比如横轴是速度、纵轴是转向角然后用双线性插值或聚类插值计算当前参数下的混合姿态。混合空间的实现比状态机简单但效果直接决定角色的移动手感。做二维混合空间时有一点必须注意动画之间必须匹配也就是所有动画在当前姿势阶段的位置和骨骼旋转大体一致否则插值结果会明显“爆姿势”。我遇到过一次用混合空间做低头到抬头角度切换结果两个动画身体转的角度差了 20 度混合后角色看起来像在跳机械舞。这类问题很难靠调混合权重解决必须回头改动画资源让美术把起始姿势摆到一致的位置。程序化动画可以作为状态机的补充手段比如待机时叠加一点呼吸起伏、走路时叠加一点随机的头部转动。用于叠加的计算量很小但能明显增加角色的自然感。程序化动画的数据流很简单动画状态机输出基础姿态程序化动画生成局部修正量两者在骨骼空间相加再进入后续的 IK 和物理修正。叠加要在骨骼空间做而不是在世界空间否则修正量会随着角色朝向发生无意义的扭曲。4. 物理和动画的真正耦合角色控制器、布娃娃与IK物理与动画最难的不是各自内部而是交界处角色控制器要用物理碰撞体又不想被物理完全支配布娃娃要把动画骨骼交给物理刚体IK 要把姿态调整到环境几何上。这一节说清楚这些耦合点怎么设计才不出大问题。4.1 角色控制器为什么不能直接用全物理驱动很多新手会问角色不就是一个刚体加几个力吗为什么主流的角色控制器都是“半物理”的原因是人的控制精度和物理引擎的数值噪声天然冲突。物理引擎为“自然真实”服务角色控制为“精确反馈”服务。如果用全物理推一个胶囊体玩家松手后角色会因为摩擦力、惯性滑出去一小段这在跳跃和站立场景中完全不可接受。我的做法是分两层角色自己的位移由动画和输入直接驱动但是角色的碰撞能力由物理引擎提供。通俗地说是这样一个配合动画系统算出角色意图位置物理系统基于“是否发生碰撞”来修正这个位置最终写回的位移才是角色真正移动的距离。这样角色的脚能稳稳踩在斜坡上又不会完全失去把持。更新顺序也有讲究先算输入意图再让物理查询碰撞再决定最终位置。不要把角色放进物理世界的主模拟循环否则角色和普通物理物体的互相作用会变得不可控。4.2 布娃娃系统动画让位于物理的极端情况布娃娃是物理对动画的接管过程。角色先是动画驱动也许是被一颗子弹打中之后切换为物理驱动——全身各骨骼绑定到对应的物理胶囊体和球状关节让重力、碰撞、关节约束去主导这具“身体”怎么倒地。架构上的核心是两套骨架的映射动画骨骼层级到物理刚体层级之间的“质心点”和“旋转锚点”要一一对应。映射错了最常见的现象就是布娃娃在倒地的瞬间突然“挤成一团”或“炸开”。我见过不少项目在切换瞬间给物理刚体施加过大初速度直接让整个布娃娃像被踢了一脚似的飞出场景。正确做法是切换瞬间从动画骨骼读取当前的世界变换把它赋给对应物理刚体并且不要额外给线速度或角速度让布料与刚体的自然衰减去接管。另外一个非常实用的方案是“混合布娃娃”。受击瞬间不把整个身体交给物理而只让受击部位例如手臂或头部局部受物理驱动其余部分仍然走动画然后在几十毫秒内把受影响范围逐步扩大。混合布娃娃可以做出非常有表现力的受击反馈同时避免了全身布娃娃带来的不可控性。从实现看混合布娃娃就是给每块骨骼设一个介于 0 和 1 之间的“物理混合权重”权重由动画与物理姿态按权重插值得到。4.3 脚部IK与手部IK让姿态贴合环境IK 系统负责在动画基础姿态上做局部修正核心是让角色脚能踩在斜坡上、手能抓住目标点。最常用的两关节 IK 求解器会做这样一件事已知肩/跨位置、肘/膝关节的链式长度让末端手或脚到达目标点二关节链存在解析解直接算两个关节的旋转即可。它比较快更适合手脚这类简单的两段链对于手指抓握或脊柱弯曲这类多关节链CCD 和 FABRIK 迭代法更常用。脚部 IK 在项目中最大的坑在于“脚踝高度”和“地板检测”的配合。贴合斜坡时你需要先计算脚底接触点的法线再让脚掌绕脚踝旋转去匹配法线方向。如果只做高低平移而不做旋转角色上下坡时脚尖会插进地面或翘起来看起来像飘在斜坡上。我在架构上让 IK 系统直接读取物理空间的查询结果——比如射线检测和形状投射——来获得地面高度和法线这样动画系统不需要知道地面细节只需要消费一个“脚底目标变换”。IK 和物理耦合还有一层稳定性问题当角色站在移动平台上时地面高度是每帧变化的脚部 IK 的修正需要平滑。我用低通滤波处理目标变换避免地面检测噪声每帧剧烈跳动。但注意滤波器的截止频率不能调太低否则角色在快速变化的地形上会“跟不上”。5. 帧调度与多线程性能预算物理动画如何并行才是核心物理和动画的并行设计决定了项目在复杂场景下能撑住多少同屏单位。我这里不是讲具体的线程池怎么实现而是讲为什么要延迟一帧、为什么要固定步长、为什么要做结果插值这些调度决策是整个性能预算的基础。5.1 固定步长与渲染插值物理不随帧率抖动物理系统必须在固定步长下推进是因为可变的步长会改变碰撞求解的收敛特性和积分稳定性。但渲染帧率是不固定的如果物理每步正好对应一渲染帧帧率掉到 30 帧以下时物理质量会大幅下降。所以调度上要区分物理步进和渲染输出的时刻先累计渲染帧的 deltaTime按固定步长多次步进物理步进结束后记录刚体位置与速度最后在渲染帧真正显示的时刻对两次物理步进的结果做线性插值得到“视觉上的平滑位置”。插值换来的是视觉顺滑但要注意“刚体变换插值”和“物理查询”是两码事。物理查询比如射线、形状投射应该使用物理当前的真实步进状态而不是插值状态否则你拾取物体时会发现射线和画面没对齐。这个区分在测试时格外重要我踩过一次坑当时把渲染用插值状态直接传进物理系统的查询接口结果子弹射线的命中和画面表现完全对不上排查了半天才发现是插值污染了查询输入。5.2 动画并行度采样与骨骼计算独立化动画系统天然适合并行不同角色的动画彼此独立同一个角色的多根骨骼也可以按集群拆给不同线程。实践中最有效的并行粒度是按角色并行每个角色分配到一条 job内部串行处理采样、状态机、骨骼计算。但当同屏角色数不多时按角色并行收益有限这时需要按骨骼集群切分上半身、下半身、手臂各自拆成子任务每个子任务只处理局部骨骼链的矩阵计算。性能预算的分配经验动画系统中最贵的往往不是状态机逻辑而是骨骼矩阵更新和蒙皮矩阵计算。骨骼矩阵更新做的是“从根到叶子”的依赖遍历这个遍历逻辑上必须串行但你可以把它切成几个链段各链段之间的根节点过渡矩阵提前算好。我见过有引擎把整个人形骨架拆成骨盆—脊柱—头一条链、骨盆—左腿链、骨盆—右腿链三部分根节点的矩阵每帧先算然后三条链并行更新效果非常明显。5.3 性能预算分配物理与动画各自能占用多少CPU帧预算分配是我每次在项目第一周就要写入开发文档的约定。主机平台以 60 帧为基准每帧约 16.67ms物理步进预算我切 2ms动画采样加骨骼计算切 3ms这样物理加动画占到 CPU 总帧预算的三成左右。再高的占比会让渲染和玩法逻辑被挤得很难受。具体调整顺序也有讲究物理预算优先保证迭代次数和碰撞检测次数动画预算优先保证骨骼采样质量和过渡计算。一旦预算超了物理上先降迭代次数从 12 降到 8 通常体感不明显动画上先降采样精度或减少同时激活的混合层数从 4 层降到 2 层而不是粗暴地把整个系统的频率减半。调这些参数前一定要量化——我习惯在引擎里加统计面板直接显示物理步进耗时、动画骨骼更新耗时和各自的目标预算折线所有参数调整都以数据为准。6. 调参实战与踩坑记录给后来者省两个通宵所有引擎架构方案最后都要用项目里的真实表现来检验。这里整理几个我在实际调试中耗费最多时间的问题以及最终稳定生效的处理办法希望对正在做物理与动画集成的人有帮助。6.1 隧穿与连续碰撞检测的高成本高速物体比如子弹、快速挥舞的武器在单个步长内从碰撞体的一侧穿过另一侧宽相位和窄相位都没检测到这就是隧穿。固定步长下物体越“细长”、速度越快穿透概率越高。解决手段是连续碰撞检测CCD它把一个步长内的运动视为一段扫掠运动检测此段时间内碰撞体是否会与其他形状相交。但 CCD 的开销明显高于普通碰撞检测不能全局默认开启只能对少数高速运动、且体积又不大的物体开启。我经历过一次典型场景一个初始速度很高的投掷物打穿了一面薄墙穿过去才触发墙后的爆炸。当时排查到最后才发现CollisionShape 被设置成了“不可扫描”的静态体积物理库强制回落到了离散检测无论怎么调 CCD 阈值都没用。所以如果你的物理库里已经开启了 CCD 却不生效先检查碰撞体的扫描标志位。6.2 动画状态机切换瞬间的“闪姿”问题状态机切换最常见的表现是角色明明播着站立动画一点攻击键瞬间切成了攻击姿势中间没有过渡动作看起来像跳帧。问题不在状态机本身而在两个动画 clip 并没有“对齐帧”。比如攻击动画的起手姿势和站立动画的结束姿势差 20 度哪怕过渡时长只有 50ms视觉上依然能感觉到闪光。我的处理套路是让策划在编辑器里给每个动画标一个“衔接姿势标记”状态机过渡时先强制从标记对应的姿态开始混合而不是从动画第 0 帧开始。这本质上是在组合“动画路径同步姿态对齐”。早期团队没有这个功能时美术只能把所有待机动画的姿势控制在接近 0 帧处代价是动作很僵。加了对齐标记之后角色动作丰富度明显提升还不用每根骨骼都人工对齐。6.3 物理关节跟随动画时的弹簧抖动一个典型的联合控制场景角色伸手抓住门把手门把手是受物理驱动的角色手部则受动画驱动。动画手部的位置每帧计算不变但物理门把手每帧被门锁的约束修正就会产生微小的相对位移。你如果不处理这段位移差关节约束就会持续微调表现出门把手和手之间永不停歇的颤抖。这里的关键是“放松追赶”而非“强制锁定”。我用带阻尼的弹簧约束来驱动物理物体的目标位置目标是动画手部的当前位置弹簧的刚度和阻尼参数需要针对不同物体调整。调参经验是刚度大到能跟上动画但阻尼要大到不让它震荡。通过测量最小相对位移和稳定时间就能确定一组普适参数。好的弹簧约束不仅是物理和动画的胶水也是布娃娃混合、IK 修正等所有耦合场景的公共基础。如果是自己在维护一套引擎我真心建议先把“物理结果插值”“动画对物理延迟一帧读取”“材质表驱动”“姿态对齐标记”这四个基础能力做进引擎底层。它们不会直接让画面更好看但会让后面所有项目和玩法迭代省下大量排查黑盒的时间。物理和动画这对系统越往深处写越会发现它们本质上是同一个问题——把现实中连续的运动在一系列离散的时间点上用数值办法还原本真架构设计的目标就是让这种“还原”在项目复杂度上升时依然稳定可靠。