企业官网建设流程全解析

引擎做了这些年，我越来越觉得物理和动画是引擎里最容易被低估的两个系统。渲染做得好，玩家顶多说一句画面漂亮；物理和动画配合得好，玩家才会说手感好、沉浸感强。这个系列前两篇聊了框架和渲染，这一篇把物理与动画放到一起讲，因为这俩在真实工程里几乎是一个不可分割的整体：物理提供约束和反馈，动画负责表现和驱动，中间那条路走得顺不顺，直接决定了游戏玩起来像不像回事。

不管你是正在自己琢磨引擎，还是在Unity、UE这类商业引擎里做深度定制，这篇都值得看完再动手。我不打算丢一堆名词就完事，而是把每个关键架构决策背后的理由讲清楚：物理为什么要固定步长、动画状态机为什么不是万能的、布娃娃为什么要混合而不是直接接管骨骼，这些坑我基本都踩过，写出来比从文档里抄概念实在得多。

1. 物理与动画在引擎架构里的位置

先想清楚一个问题：这两个系统到底在引擎里服务于谁？

物理服务的是模拟世界本身。所有需要受重力、碰撞、推动影响的对象，都要在这个系统里有自己的身份，不管是角色、箱子、载具还是布料。动画服务的则是角色表现。动画组件除了要更新骨骼姿态，还得不断回答"角色现在在干什么""下一步往哪走"这类问题。两者的服务对象不同，天然就会在数据流上产生分叉。

另一个容易忽略的差异是：物理是一套数值系统，动画是一套数据驱动系统。物理的每一帧都是在解方程，动画的每一帧都是在查数据、做插值和筛选。运行节奏也很不一样——物理喜欢固定步长，比如锁定在每秒60次更新，这样才能保证数值积分稳定；动画则倾向于贴着渲染帧走，因为画面表现上的流畅度更重要。一个要锁频，一个要跟帧，这俩放同一个循环里，如果时间步长处理得不到位，后面所有穿透、抖动、滑步的诡异问题，有一大半都能从这个源头追到。

还有一个更实际的层面：物理系统的输入数据来自玩家的操作和场景里的其他物体，输出的是位置、速度、接触信息；动画系统的输入是状态机的转移、动画时间、根运动数据，输出的是骨骼变换矩阵。物理管的是"世界怎么动"，动画管的是"角色怎么表现"。问题在于，角色既是物理世界里的一个碰撞体，又是动画系统里的一副骨骼，两套数据同时挂在一个对象上，谁来当主导、谁来当跟随，这个关系从架构一开始就要定清楚。定不清楚，后面就会出现"角色被撞飞了，动画还在原地走"这类哭笑不得的情况。

1.1 物理模块的核心职责

物理模块在引擎里通常被大家简化成"刚体加碰撞体"。这话没错，但工程上真正的分工要细得多，一个完整的物理系统至少要拆成四个子层：

第一是动力学层，负责给每个刚体算速度、角速度、力的合成，以及积分位置。这一层是物理的心脏，考虑的是"这个物体在时间步长内应该移动到哪里"。

第二是碰撞检测层，负责判断两个物体是否发生几何相交，以及相交的具体位置、法线、穿透深度。这一层考虑的是"是否碰上了、怎么碰上的"。

第三是约束求解层，负责把碰撞检测出来的接触点变成可执行的修正。刚体相撞之后不能互相嵌入，关节要限制自由度，这些都由约束求解器来处理。

第四是场景与管理层，负责物理对象的增删改查、射线检测、区域查询、触发区域管理。应用层写代码时大量接触的其实是这一层，而不是底层的求解器。

很多团队做物理的时候容易犯一个毛病：一上来就拿了一个现成的物理库往里塞，然后发现子弹穿透、角色被卡墙角、移动平台抖动。这时候再去查底层算法，往往已经来不及了。物理库只是砖头，真正决定房子能住几层楼的，是你怎么设计物理世界和游戏逻辑的交互方式。

1.2 动画模块的核心职责

动画模块的职责范围常常被误解。很多人以为动画系统就是"把美术做的文件播放出来"，但在一款3A或者中等规模的游戏里，动画系统的职责至少包括：播放动画片段、做姿态混合、做状态管理、处理根运动、计算骨骼最终矩阵、处理IK和物理交互后的姿态修正。

这中间最容易被忽视的是"姿态修正"。纯播放式动画系统只能播已经有的内容，但真实游戏里角色会遇到地形起伏、被外力推挤、踩到不平整的地面等，这些情况动画资源里根本没有对应帧。动画系统就要有能力在特定骨骼上做附加修改，甚至把一部分骨骼的控制权让给物理结算。这就是为什么现代动画系统的架构会做成多层叠加的结构，而不是单层状态机。

再说数据流。骨骼动画的数据最终要流向渲染，但这个数据流的源头其实是多路的：美术资源提供了基础姿态，动画状态机决定了现在应该播放哪个片段，混合器决定了多个片段之间的权重，物理层还可能对末端骨骼做额外的偏移，最后由骨架系统统一算世界矩阵并送进蒙皮缓冲。每一路都有自己的更新节奏和触发条件，动画模块的架构本质就是在管理这一堆异步数据流的最终汇合点。

2. 物理系统的架构拆解

物理系统是那种"看起来简单、做起来到处是细节"的模块。这里我不谈具体某个引擎的API怎么调用，而是把拆解思路整理成可以迁移到任何引擎架构里的框架。

2.1 物理世界的两个运行模型

物理系统在引擎中常见的集成方式有两种，一种是每帧同步模拟，一种是固定步长累加模拟。每帧同步模拟的逻辑最简单：渲染一帧，物理也跟着更新一次，更新步长就是渲染帧间隔。问题也很明显，渲染帧率波动大的时候，物理步长忽大忽小，数值积分就不稳定，物体有时会突然跳动甚至穿透。

固定步长累加模拟是主流引擎的标准做法。物理世界不会因为渲染帧率变化跟着变，而是维护一个累计时间，每到一定阈值就固定推进固定步长。比如步长定成1/60秒，渲染帧跑120FPS时，物理每两帧才跑一次；渲染帧掉到30FPS时，物理每帧要跑两次甚至更多。这样做的好处是数值稳定、结果可预测，坏处是物理结果和渲染输出之间有时间差，需要额外做插值来消除视觉上的抖动。

我个人的经验是：自研引擎如果物理只是简单需求，每帧同步勉强能用；只要涉及角色控制、载具、多物体交互，立刻切到固定步长加插值。这个转换越早做越好，后期再改会牵扯到大量逻辑层的回调时序，成本非常高。

2.2 碰撞检测管线：broad phase、narrow phase 与 contact

碰撞检测不是"两个物体相交就报一下"这么简单。一个场景里可能有几千个动态物体和上万个静态物体，如果每对物体都做精确相交测试，计算量会直接爆炸。所以碰撞检测管线一般分两级。

宽阶段只做粗略的包围体相交判断，目的是快速排除绝不可能会碰到的物体对。常用算法包括均匀网格、四叉树/八叉树、动态AABB树，或者Sweep and Prune。这阶段的输出是一组"潜在碰撞对"候选集。宽阶段的优化收益是最大的，同样一万个物体，暴力法要做五千万次相交测试，而一个合格的BVH可以把这个数量降到几百次量级。

窄阶段对候选对做精确几何测试。球对球、球对盒、凸体对凸体，每种组合都有专门的算法，凸体相交测试常用的是GJK，穿透深度和接触点提取常用EPA，离散点采样则可以用SAT分离轴定理做快速排除。窄阶段不仅要回答"是否相交"，还要给出接触点和法线，这组数据直接决定了后面的求解器能不能稳定工作。

接触生成之后还有一道工序，叫contact persistence，也就是接触点缓存。很多新手看不懂为什么物理引擎里会有"接触点历史"这个概念。原因是纯靠单帧的碰撞计算结果不够稳定，物体略微旋转一点，接触点就会跳来跳去，导致堆叠物体摇晃甚至爆炸。缓存的接触点加上一定的裁剪策略，可以保证接触数据在几帧内连续稳定，这对堆箱子、人体堆叠这类场景是决定性的。

2.3 约束求解：为什么物体会抖动

物理引擎里最核心也最微妙的部分就是约束求解。碰撞接触本质上是单向约束：两个物体不能互相穿过，但它们可以分开。关节则是有向约束：规定两个物体之间的相对位置和旋转被限制在某条轴或某个点上。

主流物理引擎用的方法是顺序冲量法。基本思路是：每个接触点都有一个法线方向，计算这个方向上当前相对速度有多大，如果它表示两个物体正在靠近，就施加一个冲量把相对速度修正为分离方向。这个方法不是一步到位的，而是反复迭代多轮，每一轮都小幅修正。PC上常见的迭代次数是8到20轮，移动端可能降到4到8轮。迭代多了稳定但慢，迭代少了响应快但容易残留穿透，这中间的平衡值需要针对不同项目单独调。

抖动问题很多时候就出在迭代次数不足加上接触点缓存不稳定上。还有一个更隐蔽的原因：过大的穿透深度修正。当检测到物体已经嵌入很深时，求解器会用比较大的冲量强行推出去，这时物体不仅会弹起来，还可能出现高频抖动，视觉上就是"箱子在地面上疯狂颠簸"。经验值是：穿透深度一旦超过某一阈值，不要继续硬解，而是直接把物体位置修正到表面，或者降低这个接触的修正力度，宁可允许轻微穿透也不要让物体跳起来。

2.4 物理模块和逻辑层的接口设计

物理系统不是一个孤岛，它要跟游戏逻辑、渲染、动画都发生数据交换。接口设计的好坏，直接决定了你后面调试时的痛苦程度。

物理和逻辑层的交互通常有两种模型。一种是同步回调，物理在步进过程中直接触发碰撞回调，逻辑层来处理游戏规则；另一种是命令模式，物理步进完成后统一输出一组被修改过的刚体数据，逻辑层在固定时间点统一读取。前者实现简单，但很容易在回调里做复杂操作，导致物理步进被拖慢；后者更干净好调试，但需要额外注意异步反馈的延迟。

我的建议是：碰撞事件的回调尽量做轻量，不要在回调里直接创建对象、销毁对象或者做路径搜索。正确做法是把碰撞事件记录成队列，物理步进结束后统一处理。销毁物体这种操作尤其要滞后，物理引擎内部还在迭代求解时销毁刚体，轻则内存出错，重则整个物理世界直接崩溃。几乎所有物理引擎的文档里都会写：不要在回调里销毁物体，但几乎每个项目都有人犯过这个错。

3. 动画系统的架构拆解

动画系统听起来不如物理那么"高级"，但它涉及的数据量和状态量其实非常大。一个角色动作有几百帧，一套状态机有几十个状态，每个状态下面还有各种转换条件，处理不好很容易变成一团乱麻。

3.1 骨骼树与蒙皮数据流

骨骼动画的第一层是骨骼树。骨骼树是一个有层级关系的节点树，根节点一般是盆骨或者角色臀部的参考点，子节点从大腿、脊柱一路延伸到手指、脚趾。每个节点包含一个局部变换，它相对父节点的位置和旋转。最终骨骼世界矩阵就是沿树做一次从根到叶的矩阵连乘。

这一步看似简单，但树的结构和更新顺序直接影响性能表现。如果每根骨骼都单独算世界矩阵，一个100根骨骼的角色需要几十次矩阵乘法和模板更新，看起来还好。但如果你有100个角色在屏幕上，这背后就是一万根骨骼的连乘运算。所以现代引擎一定会做骨骼缓存、LOD、合批这些策略。动画LOD的策略是，当角色离相机远时，直接禁掉手指骨骼、头发骨骼这些细微节点，只保留上半身和下半身的主干的运算。

蒙皮数据流的终点是骨骼矩阵缓冲，这个缓冲最终会送给渲染层。渲染层做蒙皮有两种常见模型：GPU蒙皮和CPU蒙皮。GPU蒙皮把骨骼矩阵作为uniform传到顶点着色器，在GPU上做顶点变换，适合大量角色；CPU蒙皮则适合形状融合、布料模拟这类需要在CPU上操作顶点数据的场景。架构上要注意的是，一旦选择了GPU蒙皮，动画系统就不能随意修改顶点数据，这对物理布料和形变效果会有连锁影响。

3.2 动画片段、采样与混合

动画资源本质上是一堆关键帧数据。每个关键帧记录了某个骨骼在某个时间点上的transform，采样就是把时间t映射到两个关键帧之间，做插值得到骨骼的姿态。这一步似乎很直观，但实际上有很多细节。

比如不同骨骼的采样频率可以不一样。面部骨骼变化缓慢，可以隔几帧才采样一次；手部骨骼动作剧烈，需要更细的采样。部分引擎做的优化是"压缩轨"：一条骨骼轨道只存储有实际变化的关键帧，没有变化的骨骼直接标记为常量，不参与插值。动画压缩是一个专门领域，好的压缩方案能把动画内存从几十兆压到几兆，代价仅仅是肉眼几乎不可见的精度损失。

动画混合是把两个或多个动画片段按权重叠加成一个姿态。最简单的混合是线性插值，比如让一个角色的上半身在播放射击，下半身在播放走路，就是按骨骼分区混合，上半身骨骼全走射击动画数据，下半身骨骼全走走路数据。更复杂的混合是自由度的混合，比如角度和速度都作为混合参数，让角色在跑动转小圈时，姿态能平滑过渡。这就是混合空间技术，本质上是在多维空间里对多个动画做距离插值，是动作游戏角色的标配。

混合的架构要点是要区分"层"和"通道"。一个动画层是一组连续处理的动画混合，多个层可以叠加，比如基础层播走路、动作层播举枪、覆盖层加上呼吸起伏，最后按顺序合成为一个姿态。这个分层结构让动画系统具备了很强的扩展性，不用每加一个效果就推翻状态机。

3.3 动画状态机：设计模式还是反模式

几乎所有动画系统都有动画状态机，但它的名声其实是毁誉参半。

动画状态机的核心是状态和转移。每个状态对应一个或一组动画，转移条件是状态切换的触发规则。它非常直觉化，美术和策划都能理解，这也是它流行的原因。但状态机最大的问题是"状态爆炸"：动作数量一多，状态之间的转移条件呈指数级增长，最后谁都不敢乱动。

实际工程里要缓解这个问题，常用做法是分层状态机。把状态机拆成基础层和覆盖层。基础层管移动这类长期状态，覆盖层管开火、受伤、翻滚这类可打断状态。层与层之间各自独立，转移条件互相不干扰，这就把复杂拆成了简单。另一个做法是加全局过渡规则：不一个个写转移，而是用优先级去决定新状态是否可以打断当前状态。优先级机制在动作游戏里非常实用，比如受击的优先级通常高于走路，翻滚又高于受击，这些只要配置一个优先级表就行。

动画状态机还有一个经常被忽略的环节：转移时长。有些引擎在状态切换时直接瞬间切到新动画第一帧，结果就是"瞬移"。正确的做法是设一个transition duration，在一个过渡时间段内把旧动画和新动画按时间曲线混合，期间还要根据根运动和速度的差异做进一步修正。这部分处理得好不好，是区分动画新老手最直接的一块试金石。

3.4 Root Motion 与动画驱动的角色控制

角色移动有两种驱动方式。一种是程序驱动，代码直接设置角色的速度，动画系统播放对应的走动奔跑动画来匹配速度；另一种是根运动驱动，由动画本身的位移数据来推动角色往前。

根运动的本质是：动画数据里除了骨骼变换，还携带了一根"根骨骼"的位移和旋转增量。例如走一步的动画，根骨骼从头到尾平移了几十厘米，动画系统按这个位移去移动角色，角色的步伐和动画就能完全同步，不会出现脚在地上滑着过去的违和感。

根运动不是没有代价。动画驱动角色移动会让响应变钝，玩家按一下方向键，角色要先等动画播放侧步数据才开始动，动作游戏里这种延迟是致命的。所以动作游戏普遍采用混合方案：移动完全由输入控制，但把根运动的数值采样下来，用来调节动画播放速率和混合权重，让动画尽量匹配角色的实际移动速度。这套逻辑最大的难点在于，把根运动位移换算成动画速度的比例系数要反复调，调不好就会出现动画播放很快但角色移动很慢，或者反过来。

4. 物理与动画的联动机制

物理和动画单独看都挺清晰，但真正让引擎变复杂的是它们之间的联动。角色既要在物理上有碰撞，又要在动画上有姿态，两者的数据如何同步和权衡，是架构设计里最值得花心思的部分。

4.1 角色控制器的物理模型

多数动作游戏里的角色移动不直接用刚体物理，因为刚体模型太难控制，容易受到莫名的碰撞反弹和摩擦干扰，手感非常飘忽。标准方案是角色控制器：一个胶囊体或者圆柱体的碰撞体替身，它受物理世界的碰撞约束，但速度和加速度由动画系统或控制代码驱动，不受重力推动，也不会被普通推动完全带跑。

角色控制器的本质是把物理的碰撞检测功能保留，把物理的动力学求解功能拿走。好处显而易见：你不会走着走着被一块小石头绊飞，也不会因为地面上有细微台阶而疯狂抖动。代价是人被攻击时，角色的受击位移需要另外处理，不能靠物理自然产生。

这里有一个架构上的经典难题：当角色被一个巨大力量击中，物理系统可能会让角色胶囊体发生位移，而动画系统还在播放受击动画。两边的数据同时作用于角色最终位置，到底听谁的？我的经验是：分主次。角色控制器的位置是权威，动画系统只负责渲染姿态，受击位移通过修改控制器位置来完成。只有进入布娃娃或者特殊物理交互状态时，才把权威完全交给物理。

4.2 布娃娃与物理混合

布娃娃系统应该是物理和动画联动的经典场景。角色死亡后，骨骼的控制权从动画状态机切到物理引擎，每根骨骼变成一个刚体，关节之间由物理约束连接，整个人就靠重力瘫倒、摔落、翻滚。

布娃娃系统最大的坑是过渡瞬间的冲量突变。角色在动画状态下还有一定速度，切到物理时如果把动画速度直接转成刚体速度，整个人会像被爆炸炸飞一样剧烈弹射出去。正确做法是动画和布娃娃有一个混合过渡期：在过渡窗口内，骨骼姿态是动画姿态和物理姿态的加权混合，物理姿态逐步占据主导，同时物理刚体的初速度要和动画速度做某种平滑衰减。

另一个常见问题是布娃娃关节的约束强度。角色死亡掉落时，身体刮到台阶或者墙角，比重很大的关节可能被卡住导致整个人体扭曲得像麻花。缓解办法是限制每个关节的旋转范围，别把物理约束的参数调得太硬，关节的阻尼也尽量给大。这些调优工作通常在编辑器里靠经验反复试，架构上要保证调试工具能可视化看到每个关节的约束角度和受力状态。

4.3 动力学骨骼与程序化动画

布娃娃只管死亡，动力学骨骼则可以用来做"活着的时候的物理表现"。典型例子是角色的辫子、尾巴、胸部装饰、披风，这些部位如果用Keyframe硬做，动作会死板；交给物理引擎去模拟，就能根据角色运动惯性自然摆动。

动力学骨骼的架构思路是在动画骨架之外，再挂一套模拟对象，它跟随动画骨骼的目标位置做弹簧阻尼跟随。每帧拿到动画骨骼的目标变换，经过一个简化的弹簧模拟，输出一个更自然的跟随变换，再覆盖回骨骼树。这样实现成本不高，效果却非常好。

在自研引擎里做动力学骨骼，要特别注意更新顺序：必须先等动画骨骼更新完之后，再运行动力学模拟，否则会出现明显的抽动。不同骨骼之间还要注意隔离，头发的动力学不能影响到脊椎的动画姿态，所以这类系统通常只修改特定骨骼链的末端节点。

4.4 IK 与脚部匹配

角色上台阶或者走斜坡时，如果只靠动画状态机，很容易出现脚部悬空或者陷入地面。IK（反向动力学）就是解决这类问题的：动画系统先播放基础姿态，然后根据场景碰撞体检测，把脚踝骨骼的末端位置强制对齐到地面的接触点上。

脚部IK实现得好的话，玩家几乎不会注意到它；实现得烂反而比没有更糟。常见的坑是IK修正的响应速度和插值平滑没做好，脚会在台阶边缘抖动或者漂移。我会用射线检测来找落足点，加上一个时域上的平滑滤波器，同时只在进入和离开接触的短暂窗口内启用强修正，避免角色跳跃时脚还被强行"吸"到地面的诡异效果。

手部IK也常见，通常用于角色抓取场景里的物体。手部IK的难点在于，手要同时满足物理位置约束和动画姿态自然感这两个互相冲突的目标。折中办法是只对手腕做位置修正，手指继续保持原动画，这样既不会出现手悬空，也不会出现手指过度扭曲。这套逻辑如果嵌到动画状态机里做，state多了之后会非常难维护，更好的做法是作为一个独立的post-processing阶段放在动画管线渲染之前。

5. 调试、优化与常见问题排查

物理和动画系统的调试，比渲染调试还要让人头疼，因为问题往往体现在"手感不对"上，很难用截图来复现。这里我整理一些踩过的坑，用速查表的思路写出来，也方便你作为排查路线。

5.1 物体疯狂抖动是怎么回事

第一个要怀疑的就是物理步长和时间缩放。检查是不是用了不稳定的变步长，或者物理更新次数和插值没配合好。第二个怀疑对象是接触点缓存被频繁清空，导致每帧求解的数据都是全新的，约束求解反复震荡。第三个是迭代次数太高，对，你没看错，迭代次数太高有时候也会导致不稳定，因为过度修正引入了新的穿透。第四个是穿透恢复阈值调得过大，物体一被压深就强行弹开。

这些问题的特征不太一样。变步长导致的抖动能从根上体现在所有物体上，不管什么样的碰撞体都抖；接触点导致的抖动体现在堆叠物体上，表现为反复弹跳；迭代过量导致的抖动往往伴随轻微穿模和能量增加。定位方法是在物理引擎里打开调试可视化，把接触点和冲量画出来，看每一帧接触点是否连续移动，同时对比不启用插值和启用插值的结果，基本能锁定来源。

5.2 角色动画滑步怎么根治

滑步是动画和角色速度不同步的典型表现。排查思路不是直接调参数，而是先搞清楚谁是驱动源。根运动驱动模式下滑步，多半是动画的根位移数据和角色控制器的移动速度不一致，需要跑一遍Animation Clip里的根骨骼位移曲线，确认数据本身是否合理。速度驱动模式下滑步，多半是动画播放速度没有跟角色移动速度做动态匹配，需要根据实时速度去缩放动画播放速率或者调节混合权重。

滑步还常出现在角色的转身动作里。二维混合空间如果里的转向采样密度不够，角度落在两个采样点中间时，脚部就会滑动。解决办法是增加转向动画的采样密度，或者引入程序化脚部滑动修正，用脚部IK把跺脚的落点锁在原地。

5.3 性能预算怎么分配

物理和动画是CPU上的两头巨头，它们的性能预算分配是架构层面的硬约束。物理部分，优先保证宽阶段的剔除效率，这一层跑得越快，后面的窄阶段和求解阶段压力越小。在移动端尤其要控制动态刚体数量，离散网格的碰撞比凸包的碰撞贵得多，能不用复合体就不用。动画部分，骨骼矩阵的计算要做LOD，远处角色用低帧率骨骼更新，再把矩阵插值补回来，视觉差异可以做到几乎不可感知。

另一个有效手段是作业化。现代引擎普遍用Job系统把物理的步进、动画采样、蒙皮计算拆成多线程任务。但架构上要注意依赖关系：动画采样不能并行依赖物理结果，骨骼矩阵计算必须等动画混合结束，蒙皮要等骨骼矩阵就绪。把任务的依赖图理清楚，调度效率可以提升几个数量级，否则只是把并发跑成了顺序。

5.4 物理与渲染之间的先有鸡还是先有蛋问题

物理结果因为固定步长和渲染帧存在相位差，直接用物理数据去渲染往往会有明显的抖动。解决办法是渲染插值：在渲染时，把上一物理步和当前物理步的状态做线性插值，得到一个与渲染帧时间对应的平滑位置。这个插值在所有主流引擎里都有，但自研时很多人会漏掉。

需要注意，插值不是万能的。如果物理步长过大，插值出来的位置会和渲染画面严重错位，比如子弹明明已经打中了箱子，但箱子的渲染位置还在几步之前，玩家会感觉伤害判定不对。解决方案是减小物理步长，或者让逻辑反馈使用物理状态而不使用渲染状态，保证判定和表现分离。这个分离一旦在架构上明确，很多难题都会迎刃而解。

5.5 动画和物理不同步的排查路线

动画和物理不同步的典型表现是：动画显示角色站在台阶上，但物理胶囊体已经迈出去了，导致角色半个身子嵌在墙里。这时候先确认两个系统用的是不是同一套坐标和同一套碰撞体数据。形状、半径、偏移这些参数在物理和动画这头如果各维护一份，迟早要出线。正确做法是编辑器里只配置一份，动画系统和物理系统都从同一个基础数据派生。

另一个高概率原因是更新顺序。物理更新在动画更新之前还是之后，直接决定了角色控制器读到的碰撞结果是否包含最新状态。常见的正确顺序是：先输入采集，再物理步进，然后动画基于物理反馈和输入做状态更新，最后渲染。如果你发现动画姿态总比物理反馈慢一帧，可以检查一下是不是动画更新被排在了物理更新更靠前的阶段。

6. 工程落地经验与设计建议

最后再分享一些我在实际架构落地时总结下来的原则，这些原则不绑定某个引擎，但基本适合绝大多数中大型项目。

6.1 依赖关系怎么定

物理系统应该是底层被依赖方，动画系统是中间层，游戏逻辑层在最上层调用两者。物理系统绝对不能反向依赖动画系统，否则就会出现物理实体要等动画状态更新完才启动的循环依赖。动画系统可以依赖物理，比如读取地面上有没有支撑、是否被击中，但物理系统对动画系统只能通过"物理回调"间接影响，不能直接调用。

这个依赖方向一旦被打破，团队协作会立刻变得痛苦。表现为：负责动画的程序员改了姿态混合逻辑，物理角色突然全都飞了；负责物理的程序员改了碰撞体形状，动画状态机的过渡条件全部错乱。净化依赖层级，让每一层的职责边界清楚，是架构管理里最简单也最有效的手段。

6.2 Tick 顺序的最终方案

我这里给出一个我验证过很多项目的最终tick顺序，仅供参考：输入层先更新，然后跑物理步进（可能多次），物理步进过程中只收集碰撞事件不处理游戏逻辑；接下来动画系统读取输入和物理反馈，更新状态机，做姿态混合和IK；最后把最终骨骼矩阵和物理插值后的变换交给渲染层。

这个顺序有几个设计考量。第一，输入在最前面，保证物理和动画都能读到最新指令。第二，物理先于动画，让动画可以利用物理结果做响应，比如脚着地之后才能切换跑动状态。第三，逻辑事件处理放在物理步进后和动画更新前之间，避免逻辑修改物理状态的同时动画还在模拟同一个对象，引发不一致。

实际项目中总会出现一两个例外，比如粒子效果需要跟随物理物体、UIDirect要直接读骨骼位置，这些都按具体需求去微调。但大方向不要动，一旦动了，各种奇怪的时序问题会接踵而来。

6.3 自研还是集成第三方物理库

自研物理还是集成第三方，这几乎是每个引擎负责人都会纠结的问题。我的观点是：碰撞形状简单、物理需求不复杂的项目，完全可以用自研，并且自研可控性好，调试起来更顺手；一旦涉及复杂角色交互、载具、破碎仿真、大场景物理流式加载，第三方物理库的成熟度会节省你大量时间。

集成第三方物理库不意味着撒手不管。物理库的运行频率、同步机制、回调时机仍然需要引擎层去做桥接层。很多团队集成PhysX时习惯直接暴露它的API让游戏逻辑调，结果就是物理库和引擎深度耦合，后续想换或者做并行优化都非常痛苦。正确做法是做一个物理抽象层，定义一套引擎自己的物理接口，第三方库只是底层实现之一，这样哪怕将来换库，也不会伤筋动骨。

动画系统则不太建议完全自研底层，但也不太建议直接用商业引擎的现成方案，因为它和美术资源的绑定太深。比较务实的路线是：动画资源管理可以商业化方案，骨骼数据格式标准化，但状态机和混合逻辑自己做，因为这部分是游戏手感的核心竞争力，靠别人的通用逻辑取代不了。

6.4 编辑器与调试设施

物理和动画系统的调试设施，是自研引擎里投入回报比最高的部分。物理调试要把碰撞体轮廓、接触点、冲量方向可视化出来；动画调试要能把骨骼树、动画状态机的当前状态和转移条件、混合权重全部显示在面板上。我见过很多团队把这两块调试工具往后拖，然后线上排查问题时抓瞎。提前花两三周把这些工具做出来，后面省下来的解决问题的时间远远不止两三周。

工具设计上有一个重点：物理调试和动画调试最好能叠加显示。因为很多问题就出在"物理认为接触了，但动画没反应"或"动画显示在走，但物理位置没动"这类跨系统问题上。单独看任何一方都看不出毛病，叠加看才能一眼找出是谁背锅。把这个叠加显示做成引擎内置功能，你的团队在排查手感问题时的效率会高非常多。

说到底，物理和动画这两个系统不是靠一个漂亮的架构图就能跑顺的，它需要的是持续的参数调试和跨模块的沟通机制。架构只是把沟通的通道铺好，真正让游戏变得好玩，还是要靠一个又一个参数的耐心打磨。希望大家在自己的引擎或者项目里，都能少踩几个我踩过的坑。