引擎架构这个话题前面聊了资源管理和场景图今天把视角拉到运行时最热闹的两个系统物理与动画。物理负责让物体遵循力学规律动画负责让角色动得自然但真正做引擎的人都知道这两套系统要是各管各的角色要么像提线木偶要么像一袋散掉的土豆。所以这篇文章不准备单讲某个引擎的API而是从架构层面拆开来看物理系统内部的碰撞检测、约束求解、时间步进是怎么组织的动画系统里骨骼数据、状态机、混合、IK各自承担什么角色以及两个系统在根运动、布娃娃、物理矫正这些场景里如何协作。适合正在写自研引擎的开发者也适合想深入理解商业引擎工作原理的同学哪怕你只是天天调Unity物理参数的策划看完也能知道那些面板后面的计算大概是怎么走的。1. 物理系统内部架构拆解从碰撞检测到约束求解1.1 碰撞检测的两层流水线Broad Phase 与 Narrow Phase物理引擎的第一件事不是算力而是先搞清楚哪些物体可能碰在一起。要是场景里有一千个刚体两两检测就是五十万次组合哪怕是简化碰撞体也扛不住更别提每帧都要做。所以现代引擎一致的做法是把碰撞检测拆成两个阶段。Broad Phase宽阶段的目标是快速剔除不可能相交的物体对不追求精确只求快速暴力地筛一遍。常用的手段包括SAPSweep and Prune扫描剔除、BVH包围体层次结构、统一空间网格三种。实际引擎里最常见的是BVH和SAP的组合静态场景用预计算BVH动态物体用SAP做增量排序。因为SAP依赖物体AABB轴对齐包围盒在三个坐标轴上的排序连续性——大部分物体每帧移动量不大增量插入排序可以接近O(n)复杂度比每次都全排序快得多。如果场景是大范围开放世界物体分布稀疏空间哈希网格也会作为备选尤其是粒子系统里大量小物体两两碰撞的场景。Narrow Phase窄阶段才是真正决定“是否碰了”和“碰在哪”的地方。这阶段分两小步第一步是判定相交第二步是生成接触流形Contact Manifold。基础几何体之间有专用求交函数例如球体对球体直接比较圆心距球体对盒子用最近点法盒体对盒体用分离轴定理SAT。凸包与凸包之间则走GJKGilbert-Johnson-Keerthi算法它不直接判断相交而是通过不断构造单纯形逼近原点来判断两个凸形状是否重叠。问题是GJK只能回答“有没有碰”回答不了“碰得多深、从哪个方向分开”所以后面还需要EPA扩展多面体算法或者退回到SAT的变种来求穿透深度和分离法线。注意穿透深度和法线方向是后续约束求解器的直接输入。很多初学者自己写碰撞检测走到“检测到相交”就停了结果物体卡在一起疯狂抖动就是这里少了接触流形生成环节。接触流形至少要包含法线方向、接触点列表、穿透深度三个信息缺一个约束求解器都没法稳定工作。实际工程中窄阶段计算出的接触点还需要做持久化缓存。同一对物体相邻帧的接触点位置是连续变化的缓存上一帧的流形能显著减少接触点抖动。不少引擎会把接触点按物体对存储并设置每帧最大接触点数量常见4个超出部分按深度和角度优先级丢弃这也是为什么你看到一个方块斜着落地时只有四个接触点而不是整面都是点。1.2 刚体动力学与约束求解器的工作方式碰撞检测告诉你“碰上了”刚体动力学则回答“接下来每个物体要怎么动”。物理引擎里刚体的状态通常由位置、旋转四元数、线速度、角速度四个量描述。质量、惯性张量、质心偏移是常量。每帧积分时引擎把加速度重力和外力叠加到速度上再把速度积分到位移上。这里有个关键选择显式欧拉积分简单但有能量增长倾向容易导致物体越弹越高半隐式欧拉先把速度更新完再用新速度更新位置稳定性好得多所以绝大多数引擎都用它。约束求解器负责处理碰撞响应、关节、摩擦这些“不能自由运动”的部分。约束用一个等式或不等式描述比如两个刚体不能相互穿透铰链关节限制某个方向的自由度。求解器会尝试调整速度让约束在当前时间步内尽量被满足。最流行的方法是速度级顺序冲量法Sequential Impulse核心思路是每次只处理一个约束算出为满足该约束所需的速度修正量立刻施加到对应刚体上然后处理下一个多轮迭代后整体收敛。迭代次数直接影响堆叠稳定性。堆一摞箱子时每个箱子都受到下方箱子的支撑约束如果只迭代一次底部的压力无法传到顶部整摞箱子会像果冻一样软趴趴地塌下去。常见引擎里默认迭代次数是4到10次物理要求高的时候比如赛车游戏可以开到20次以上代价是CPU时间翻倍。做引擎的人得明白一个道理迭代次数不是越高越好因为约束之间存在耦合高迭代收益递减而且固定次数的迭代在接触点数量暴增时会失效这时候更需要靠接触流形缓存和岛分区Island来做收敛管理。1.3 物理引擎的时间步进策略为何如此关键刚体模拟的稳定性极其依赖固定时间步长。如果你的逻辑帧是60帧但物理模拟仍按渲染帧去做可变步长帧率波动会直接导致穿透和爆炸。业界成熟方案是固定步长加上累积器渲染帧间隔可能是16.7毫秒也可能33毫秒引擎把多余时间累积下来按固定的1/60秒或1/120秒消费掉。还有更细的做法物理步长固定为1/120秒但每次渲染帧内做多次子步进。子步进能让高速运动物体在单帧内多次检测碰撞减少隧穿Tunneling问题——也就是子弹太快直接穿墙的情况。我接触过的几个自研引擎物理默认配置是1/120步长加上8次子步进也就是一个渲染帧内最多跑16个物理子步。这种配置下角色高速奔跑也不会穿墙但要注意累积器的上限保护否则帧率掉到个位数时一帧时间全被物理消费就会出现“螺旋死亡”式的卡死循环。常见错误是把物理步长直接设成渲染帧率。帧率一掉到30物理也跟着变慢刚体直接变成慢镜头。正确做法是保持物理步长恒定允许渲染帧之间跑0次、1次或多次物理子步这样物理行为始终和真实时间挂钩和画面帧率无关。2. 动画系统架构拆解骨骼、姿态与状态机的数据流2.1 骨骼动画的底层数据结构与更新顺序动画系统的地基是骨骼层级Skeleton Hierarchy。每块骨骼保存父骨骼索引、本地位置、本地旋转构成一棵树。角色模型导入引擎后所有骨骼的本地变换原始姿态叫绑定姿势Bind Pose每个顶点记录受哪些骨骼影响以及权重这就是蒙皮信息。动画播放时引擎从动画曲线采样出每块骨骼的目标本地变换然后从根骨骼开始做一次前向遍历把每个骨骼的本地变换乘到父骨骼的全局变换上得到全局矩阵。全局矩阵再乘以绑定姿势的逆矩阵就得到蒙皮矩阵也就是渲染器真正用来刷顶点位置的矩阵。蒙皮矩阵为什么要乘逆矩阵因为顶点坐标是建模时的绑定姿势下存储的而现在骨骼已经动了不能直接把全局矩阵作用到顶点上得先逆变换回绑定姿势坐标系再正向变换到当前姿势。这个流程的更新顺序很关键先采样动画再算局部姿势再算全局姿势最后生成蒙皮矩阵并提交渲染。每个环节独立可缓存尤其全局姿势的计算可以并行化。现代引擎做成Job系统后一个角色的骨骼更新通常会被切成多个任务并行不过因为骨骼树是前向依赖的并行粒度一般按骨骼节点数组分块处理而不是整棵树一层层并行收益有限但聊胜于无。2.2 动画状态机与混合空间的组织逻辑动画系统不能只会播放单条片段否则角色从走路切到跑步就是生硬瞬移。动画状态机Animation State Machine是组织逻辑层状态表示一个动画或一组动画转移条件决定切换时机。条件可以是变量比较比如“速度大于3.5米/秒进入跑步状态”可以是事件触发比如“按下攻击键进入攻击状态”。状态切换本身用的是过渡Transition机制。最简单的过渡是交叉淡化Crossfade两个动画按时间权重线性混合时长通常50到200毫秒。但这只解决了切换顺滑没解决“方向和速度怎么对应动画”的问题于是混合空间Blend Space就派上了用场。混合空间是一个二维坐标系统横轴往往是角色移动速度纵轴是转向角度或方向增量坐标轴上的每个格子放一段采样动画。运行时把角色当前速度和转向角度映射成坐标系统根据坐标在相邻节点间做双线性插值得到一个连续变化的姿势。混合空间的数据结构本质上是一个二维网格加一组采样点每帧需要做的事情是找到当前坐标所在的四边形计算四个顶点权重然后按权重混合局部姿势。这个混合是在骨骼关节空间做的对每块骨骼的旋转分别做四元数球面插值Slerp。注意位置分量通常做线性插值否则某些极端姿势下骨骼会拉伸变形。2.3 逆向运动学与程序化动画的接入点动画状态机解决了“做什么动作”逆向运动学IK解决“动作和现实对不齐”。典型场景是角色踩在台阶上动画里腿是平的但地形有高低差不做IK脚就会陷进地面或悬浮在空中。IK按算法分好几代最常用的是FABRIK前向和后向Reaching IK和CCD循环坐标下降。两者思路不同FABRIK从末端效应器开始反向迭代调整每个关节位置速度快且稳定CCD从根关节开始逐关节旋转让末端接近目标。引擎架构里IK通常做在状态机和蒙皮之间也就是动画采出姿势后、计算全局蒙皮矩阵前。这个位置非常讲究IK需要操作骨骼的局部旋转但处理时又需要世界空间的目标点位置所以一般得先暂时算一遍全局姿势IK对相关骨骼做旋转修正再重新算一遍全局姿势最后生成蒙皮矩阵。这也意味着IK不是免费的骨骼数量越多、每帧求解次数越多开销越大。实际项目中不会全角色骨头都跑IK只在目标加权骨骼链比如一条腿4-6块骨头上跑。程序化动画是IK的更高层延伸例如根据角色速度动态调整躯干倾斜、攀爬时用物理射线检测手部落点。它们共用一套底层接口允许外部代码在动画姿势计算的特定阶段注入修改量而不是等动画算完再去改渲染结果。3. 物理与动画的协同设计根运动、布娃娃与物理矫正3.1 根运动物理、动画与角色控制器的三方协调角色移动是动画和物理最容易打架的地方。如果动画里角色在跑但角色控制器的移动完全由物理驱动两者速度不一致就会滑步如果完全由动画驱动那么碰撞反弹、拐角摩擦这些物理反馈又会失效。根运动Root Motion就是为调停而生。根运动的做法是把位移信息算进动画数据里。角色动画的根骨骼通常是髋部或脚下的空节点在播放过程中会有位移曲线当根运动开启时动画系统每帧输出根骨骼的位移和旋转增量。控制器拿到这个增量后把增量当作期望速度再经过角色控制器的碰撞检测和物理环境修正最终更新角色位置。也就是说动画决定“想往哪走”物理决定“能不能走”。架构上根运动的数据流是动画到物理再到动画的闭环需要注意节奏。动画采样如果按渲染帧走但物理步进是固定步长帧率不一致时角色控制器的位移量得按物理子步均匀分配否则角色在低帧率下会一顿一顿。我在某项目里遇到过一个经典问题60帧下角色走路匀速锁30帧后就变成“走走停停”排查了很久发现是根位移把整帧的动画位移一次性塞给了物理导致每帧一次性跳跃。解决方案是把根位移增量按物理子步数量均分每个子步只加入对应比例的位移。3.2 布娃娃切换与速度继承角色倒下前必须处理的三个问题死亡瞬间把角色从动画驱动切换成布娃娃这是动作游戏渲染冲击力的关键也是物理动画协作里最容易露馅的地方。直接切换会出现三种典型问题一是角色在倒地前会先“僵直”一下再开始掉落因为布娃娃初始速度是零动画最后一帧的速度没传过去二是布娃娃刚体在初始化时姿态和当前动画姿态对不上导致骨头瞬间扭曲看起来像被折断了三是布娃娃倒下后和地面碰撞弹跳过于剧烈完全不像尸体。解决第一个问题靠速度继承。动画系统在切换前需要把每块骨骼最近几帧的线速度和角速度算出来可以通过前一帧和当前帧姿势差分求得也可以用专门的采样缓存切换时把这些速度直接赋给对应的布娃娃刚体。这样角色倒下是一个连续流动的过程而不是“先静止再倒下”。解决第二个问题靠姿态对齐。布娃娃刚体的初始状态应该由动画当前骨骼全局矩阵反向推导而不是简单地把骨骼矩阵复制给刚体再重置速度。因为刚体有碰撞体形状如果碰撞体形状和骨骼矩阵不完全匹配初始化瞬间就会产生穿透修正视觉上就是瞬移。稳妥做法是切换时先禁用布娃娃重力几帧等约束求解器把姿态调整稳定后再启用。第三个问题靠物理参数调节。布娃娃关节的约束需要设阻尼刚体还需要调低恢复系数。我见过不少项目布娃娃倒地后弹得像弹簧就是直接把通用刚体的恢复系数套到了布娃娃上。布娃娃刚体的恢复系数通常应该压在0到0.1之间关节角约束的柔软度也要单独调。3.3 动画驱动物理与物理矫正动画的两种数据流物理和动画协作并不只有布娃娃这一条路。头发、衣服、胸部摆动这类次级动画如果完全靠手K会累死动画师完全靠物理模拟又容易失控。这类系统常用的是动画驱动物理Animation Driven Physics动画提供目标姿势物理系统跟踪这个姿势并叠加动态效果。架构上表现为一个弹簧-阻尼式的跟踪系统每帧计算当前物理骨骼位置和目标动画位置的差异用弹簧常数和阻尼系数算出修正加速度。弹簧常数越高跟随越紧动态越不明显常数越低飘动越夸张。这套系统的好处是天然稳定不会出现布娃娃那种完全不受控的状态但缺点是需要调参且物理骨骼数量多时开销不小。有些引擎会把这层系统做成可开关的LOD细节层次距离远时关闭头发和衣服模拟以节省性能。物理矫正动画是另一个方向的方案动画为主但用物理做微小修正。最典型的应用是脚部锁定Foot Locking。动捕动画播放时角色脚底经常在移动中轻微滑动看起来像滑冰。引擎可以用一个极小的物理模拟或几何计算来判断脚底当前是否应该固着在地面如果是就把脚踝骨骼的位移和旋转修正到固定位置让脚看起来“钉”在地面上。这类修正的力度通常不大但效果好是很多项目解决滑步问题的重要补充手段。4. 性能优化思路与常见问题排查4.1 内存布局、并行调度与同步点设计物理和动画都是每帧更新的高频系统性能优化不能等到最后拍脑袋。先说内存布局。骨骼数据在动画系统里是按关节索引访问的如果每个骨骼的数据分散在不同结构体里CPU缓存命中率会很差。我在项目里会把所有骨骼的局部位置、局部旋转、全局矩阵分别放到独立的连续数组里也就是结构体数组SoA布局。这样采样动画时只需要顺序访问位置数组和旋转数组计算全局矩阵时则可以连续写全局矩阵数组比弄一个巨大的骨骼结构体数组快不少。物理系统同理刚体的位置、速度、质量数据尽量连续存放避免每个刚体一个大结构体把热数据撑爆缓存。并行调度方面物理和动画的并行友好度差别很大。动画系统中的骨骼前向遍历有依赖关系可以并行到骨骼节点级别但收益有限。实际引擎中动画作业通常是部件级并行——多个角色同时更新每人一个任务配合多线程同时计算多个角色的动画。物理系统里Broad Phase对并行友好可以用多线程并行做AABB更新和剔除Narrow Phase也可并行因为每对物体独立做求交唯独约束求解阶段是串行的因为迭代更新会不断修改同一批刚体的速度并行会带来竞争和收敛问题。某些引擎通过把约束按岛分区后再做并行求解但实现复杂度高一般小引擎不必强求。还有一个容易忽略的同步点问题动画系统通常跟着渲染帧走因为要驱动渲染物理系统跟着固定步长走两者在帧尾需要交换数据。如果动画和物理各跑一个线程它们之间的数据交换点就需要加锁或做双缓冲。常见错误是直接用一把大锁把整个物理步进阶段锁住结果动画线程被卡死帧率直接腰斩。正确做法是只在交换缓存区的地方做无锁双缓冲写方写完指针再切读方读旧数据帧尾统一交换。4.2 抖动、穿透与角色滑步问题排查清单做物理和动画联动最常遇到的诡异现象就三类抖动、穿透、滑步。每类问题的根源不太一样排查顺序也不同。抖动多半不是浮点精度问题而是约束求解的收敛性不够。先检查是不是物理步长过大换个1/120步长试试再检查迭代次数接触点很多时4次迭代很可能不够最后检查是不是接触流形缓存没做好导致接触点每帧跳变。我遇到过一种堪称阴间的抖动是动画输出姿势和物理修正姿势交替覆盖导致的动画系统每帧写骨骼矩阵物理矫正也往同一个矩阵写两个系统的写入顺序没定好帧与帧之间数值反复横跳。最后加了版本号谁后写由帧内阶段顺序决定问题立刻消失。穿透问题优先怀疑隧穿。物体速度过快、物理步长过大、碰撞体太薄都会造成穿透。高速物体用连续碰撞检测CCD能解决大多数隧穿问题但注意CCD不是免费午餐它只应该用于小且快的物体全场景开启CCD的性能代价很多人扛不住。另外静态场景碰撞体常见坑是用开口网格做碰撞内部结构复杂导致误判解决办法是生成带厚度的自动碰撞体或手动分块。滑步问题和物理关系不大主要是动画和实际移动速度不匹配。先检查动画播放速度是否和角色移动速度一致再检查混合空间的横轴速度参数是否更新正确最后看根运动是否被物理系统多算了一份位移。最容易被忽略的是动画倍速变化后的过渡混合时间混合期间两段动画速度不同也会出现阶段性滑步。解决方式是在过渡期间同时修正角色的实际位移速率而不是等混合结束后突然变速。4.3 调试工具与可视化手段的经验之谈物理和动画系统的调试光靠日志没用必须可视化。物理调试基本标配是碰撞体线框叠加把AABB、球体、胶囊体、网格碰撞体全部以线框画出来同时绘制法线方向和接触点位置。只看线框还不行要把穿透深度用颜色标记黄色表示轻微接触红色表示严重穿透。这样场景里哪里挤压严重一眼可见比对着数值猜快得多。动画调试最重要的是骨骼可视化。画出骨骼骨架、全局坐标轴、IK目标点、根运动位移轨迹。一个很实用的图形化方案是在角色脚下画出移动速度向量和动画预期速度向量两个向量不重合就能立刻看出滑步是引擎层面还是动画数据层面问题。IK调试时把目标点、当前末端位置、约束链骨骼画出来能快速判断是目标点误差还是算法迭代收敛不够。还有一个容易被新手忽略的高级技巧物理状态回放。把最近30帧的刚体位置、速度、接触信息写入环形缓冲区运行复现时可以用时间滑块逐帧回看。布娃娃切换那种瞬间问题靠回放可以逐帧看到速度继承那一刻到底发生了什么比反复重启游戏碰运气高效得多。我自己在项目里做这套回放系统只花了一周但它在后面半年里省下来的排查时间远不止这一周。实操中的体会做了这么多年引擎物理和动画是我觉得“入门容易做好极难”的两个系统。物理的难点不在算法——算法是现成的论文有的是——而在工程化的稳定性接触流形缓存、迭代收敛、时间步进策略每一个单独拿出来都是又臭又长的坑。动画的难点则在数据流组织骨骼更新、状态机、IK、物理矫正这么多阶段谁先谁后数据在哪里交接一旦顺序错了表现出来的全是莫名其妙的诡异动作。如果只让我给一条建议那就是从一开始就把动画和物理当成一个整体系统来设计不要各做各的。至少在数据层面预留一个“物理可修改动画姿势”的接口和一个“动画可读取物理速度”的接口哪怕第一版用不上后面做布娃娃和脚部锁定都会省掉大改的苦。最后提醒一句查问题时先看是不是帧同步问题再看是不是缓存问题最后才怀疑算法本身——我踩过太多次“算法明明是标准实现怎么会有问题”最后发现是上游数据喂错的坑。