1. 先把这个框架的边界画清楚第一次打开 Animation Blueprint动画蓝图的人十有八九会把它当成一个状态机编辑器——左边一张图拖几个状态进去连线跑起来角色能动能跳收工。等哪一天角色在高处落地时腿抖了一下、奔跑急停时下半身跟不上、战斗里技能位移和动画对不上才会慢慢意识到真正在背后干活的东西远不止一张图。Unreal Animation Framework 不是一个能单独打开的模块它是从资产定义、蓝图、C 节点一路延伸到 Skeletal Mesh Component、工作线程求值、最后到 GPU 蒙皮的一整条链路。这条链路上的任何一环出问题表现都是角色看起来怪怪的但病因完全在不同的地方。这篇文章面向的是已经能在 AnimGraph 里连出个能跑能跳的角色、却还说不清它为什么这么跑的开发者。我会把这条链路从头到尾拆一遍一帧动画是怎么算出来的、节点各自扮演什么角色、什么东西在偷偷吃帧率、上机之后该按什么顺序排查。不堆名词尽量讲清楚每件事为什么这么设计。1.1 四个层次各管各的事把整个框架按从下到上的顺序摊开大致是这么四层每一层你日常碰它的入口都不一样。层次代表对象你平时在哪碰它出问题时的典型症状资产层Skeleton、Skeletal Mesh、Anim Sequence、Blend Space、Montage内容浏览器、骨架树、序列编辑器重定向后滑步、蒙太奇播不出来逻辑层AnimInstance、AnimBP、状态机、Native C 节点动画蓝图编辑器、C 里的 AnimNode状态切不过去、变量读不到求值层AnimGraph 求值、快路径、线程安全更新、Pose编译输出、调试视图、Trace帧率断崖、游戏线程被堵组件层SkeletalMeshComponent、LOD、更新率优化、预算分配组件细节面板、项目设置远处 NPC 也在满速跑、偶发卡顿这张表看着朴素但它的价值在于当你遇到动画出问题了第一件事是判断问题在哪一层而不是盲目地去调混合时间。滑步是资产层状态卡死多半是逻辑层帧率是求值层和组件层。分层判断能省掉大量的无用试错。1.2 三个新手最容易混淆的概念第一个是Skeleton 和 Skeletal Mesh。Skeleton 是图纸骨骼层级、曲线、插槽、通知的定义都在它身上Skeletal Mesh 是实体网格顶点、蒙皮权重、材质。一个 Skeleton 可以被好几个 Skeletal Mesh 共享——这是重定向能成立的前提也是很多人第一次改骨骼时会踩的坑你只是想给某个角色加一根武器骨骼结果所有共享这个 Skeleton 的角色和动画全都被标记成了需要重建。第二个是Anim Sequence 和 Anim Blueprint。Sequence 是一段素材本质上是一段时间轴上的骨骼变换曲线集合Anim Blueprint 是播放器加混合器它决定什么素材在什么条件下、以什么权重、混合到哪一块骨骼上。素材本身不会动是蓝图让素材动起来的。第三个是State Machine 和 Montage。状态机管持续状态——站立、行走、奔跑、下落这些状态会一直存在直到条件变化。蒙太奇管一次性事件——挥刀、开门、受击播完就结束。用状态机去做一次性动作状态数量会迅速爆炸用蒙太奇去表达持续状态你会发现它没法自然循环。这个边界感一旦建立起来动画蓝图会干净非常多。1.3 引擎为什么非要拆成这么多层有人会问为什么不能像某些轻量引擎那样一个动画组件配一个播放列表就完事原因在于 Unreal 面向的项目规模。当项目里有几十个角色、几百段动画、多个职业体系、需要重定向、需要按平台裁剪质量的时候集中式的简单设计会立刻崩溃。拆层带来的直接好处有三个资产可以独立于逻辑迭代动画师改素材不需要程序配合逻辑可以共享Linked Anim Layer 让多个角色共用同一套上半身逻辑求值可以裁剪远处的角色不需要每帧算完整姿势。这三个好处对应的是三个真实的工程痛点不是教科书上的设计模式说辞。还有一个隐性的好处动画资产的格式被固定下来了所以压缩、LOD、流式加载这些东西才有统一的挂载点。你后面遇到的绝大部分性能优化手段都是建立在这个格式统一的前提上的。2. 一帧动画是怎么走完的理解了分层第二个关键问题是一帧之内这套链路到底按什么顺序跑。这个问题搞清楚了后面所有关于为什么慢为什么不生效的排查都会变得有方向。2.1 Update 阶段把游戏世界的数据搬进动画世界每一帧SkeletalMeshComponent 在 Tick 里会推一次 pose最终落到 AnimInstance 的更新逻辑上。这个阶段运行在游戏线程它的核心任务只有一件事把动画需要知道的外部信息从游戏世界搬进来。搬什么通常是速度、加速度、朝向与速度方向的夹角、是否在地面、是否在瞄准、是否被锁定、生命值区间、当前武器类型等等。这些数据来自 Pawn、CharacterMovementComponent、输入系统和你自己的游戏逻辑。写法上有两种一种是在动画蓝图里直接写蓝图逻辑去读另一种是在 C 里继承 AnimInstance重写NativeUpdateAnimation把数据算好之后赋值给UPROPERTY(BlueprintReadOnly)的成员变量。我个人偏向后者理由很直接这个阶段在游戏线程上做的事情越多主线程的余量就越少。蓝图逻辑虽然方便但每一次取值、类型转换、函数调用都要过一遍虚拟机。把它挪到 C 里做一方面编译期就能确定内存布局另一方面可以顺手把计算结果缓存下来供后面工作线程直接读。注意不要把需要每帧算的重活放在这个阶段。寻路、射线检测、遍历大量 Actor 这类操作一旦进了 Update 阶段就是直接往主线程上加担子而且这种开销在 Profile 里看起来会分散在各个地方很难一眼定位。2.2 并行更新与求值工作线程上的姿势计算数据搬进来之后真正算姿势的部分会被派发到工作线程上。这里有个非常关键、但文档里经常一笔带过的设计真正参与求值的对象不是 UAnimInstance 本身而是一个叫 FAnimInstanceProxy 的代理对象。为什么要多这一层代理因为 UAnimInstance 属于游戏线程的世界它持有 UObject 引用、参与 GC、可以随便访问 Actor而工作线程上不能碰这些东西。代理对象就是这两者之间的隔离带——游戏线程把数据写进代理的快照区工作线程只读代理算完姿势再把结果交回去。理解了这个你就能理解为什么线程安全更新会有那么多限制不是引擎故意为难你而是代理里根本没有那些数据。求值阶段会把 AnimGraph 从根节点往下走一遍每个节点在自己的Evaluate里拿到一个姿势上下文往里写骨骼变换。这里要注意一个容易忽略的细节图里流动的姿势默认是局部空间每根骨骼相对于父骨骼的变换不是组件空间也不是世界空间。这么设计是为了效率——局部空间的父子关系是固定的可以按骨骼索引顺序一次算完。但有些节点天生需要在组件空间里工作比如 IK、Look At、骨骼控制类节点。所以引擎会在遇到这类节点时做一次空间切换把局部空间姿势转成组件空间让这些节点处理完再转回去。现在版本里这类节点的基类已经帮你把转换封装好了但你写自定义节点时如果搞混了空间得到的结果会非常离谱——手臂会朝着一个完全不相干的方向指。另外每个节点上基本都有一个LOD 阈值属性。意思是当这个组件处在第 N 级 LOD 时这个节点可以被跳过不执行。这是个非常划算的优化手段——远处的角色不需要精确的手指 IK也不需要头顶的视线追踪。可惜很多人从来没动过这个值。2.3 从姿势到像素空间转换与蒙皮姿势算完之后还要走完最后一段路。局部空间姿势先合成到组件空间再乘上组件自身的世界变换变成世界空间的骨骼矩阵。这中间有一个很好用的机制叫主姿势组件当一个角色由多个 SkeletalMeshComponent 拼成时比如身体一个、衣服一个、武器一个可以让其他组件挂到主组件上直接复用主组件算出来的骨骼矩阵避免同一套骨骼被算好几遍。再往后就是蒙皮。这一步在现代平台上基本都交给 GPU骨骼矩阵被塞进一张纹理或者一块常量缓冲顶点着色器或者计算着色器根据每个顶点记录的骨骼索引和权重把顶点从绑定姿势变换到当前姿势。CPU 蒙皮只在少数平台或者少数场景下才需要。所以你会看到一种有意思的现象——动画求值和蒙皮的开销是分开的前者吃 CPU后者吃 GPU。排查的时候要分清是哪一头的问题不然调了半天压缩设置结果瓶颈在 GPU白忙。2.4 动画的时间跟游戏 Tick 不是一回事这里有一个很多人没意识到的点动画的时间推进是由 AnimInstance 自己管理的DeltaSeconds 从组件那边传进来。绝大多数时候它等于游戏帧的 DeltaTime但一旦你启用了更新率优化情况就变了。更新率优化的思路很朴素一个二十米外的角色没必要每帧算姿势。于是引擎把这类组件分成几组每组以不同的频率更新中间帧用插值补上。配合重要度管理器还可以按距离、可见性、屏幕占比动态调整更新频率。这套机制在有大场景和大量 NPC 的项目里收益非常可观。但代价也是真实的我踩过不止一次更新频率被降低之后DeltaSeconds 的语义变了。蒙太奇的时间推进、通知的触发时机都可能被跨过去。表现就是某些依赖精确时机的动作会偶尔不触发或者延迟一两帧才触发而且在编辑器里跑得好好的打包之后才出现。所以启用更新率优化之后一定要专门回归测试那些卡帧逻辑受影响的技能和演出。3. AnimGraph 里各个节点的真实身份节点面板里的东西看起来很多但真正日常高频使用的就那么十来个。我把它们按解决什么问题重新归一下类比按字母顺序背一遍有用得多。3.1 状态机管模式Blend Space 管连续量状态机擅长表达离散的模式切换站立、行走、奔跑、跳跃、下落、落地。它的每一次状态切换本质上是一次混合而混合是需要时间和权重的。这带来一个常被忽视的后果如果两个相邻状态会高频来回切换比如速度刚好卡在走和跑的边界上状态机就会疯狂地混合来混合去表现就是角色在抖。Blend Space 擅长表达连续量的插值速度从 0 到 600 之间连续变化、方向从 -180 度到 180 度连续变化它直接把二维坐标映射到几个样本动画的权重上不需要切换这个概念。所以正确的组合方式通常是用状态机决定当前属于哪一组素材用 Blend Space 在这一组素材内部做连续插值。走和跑如果确实需要分成两个状态那就把边界设置得足够宽再加一点滞后比如进入跑的阈值比退出跑的阈值高避免在临界点抖动。而对于那些必须硬切的过渡比如受击打断、突然变向现在更推荐用惯性化过渡。它不是把两个姿势按权重硬混而是把当前姿势的速度和角速度带着走用一段时间慢慢衰减到目标姿势。好处是不需要交叉淡化窗口切换瞬间就能反应同时看起来还很自然。这个节点在状态机的过渡规则里可以直接选用过一次基本就回不去了。3.2 保存缓存姿势把重复求值砍掉AnimGraph 是一张图图意味着同一个子图可能被多个分支共用。如果没有缓存机制共用就意味着重复求值——同一根骨骼链被算两遍浪费时间还可能因为状态不一致导致结果矛盾。保存缓存姿势就是解决这个的。你在某个位置把当前算出来的姿势存起来下游任何地方都可以直接取用不用重算。最常见的用法是把基础移动姿势存一份然后上半身取一份、下半身取一份各自叠加不同的层。但它有个必须记住的约束缓存下来的是局部空间姿势。如果被缓存的那段子图里包含了依赖组件空间的节点IK、注视、约束类缓存之后的行为可能就不符合预期因为它被拿到另一个上下文里重用了。这个坑我踩过一次表现是手臂 IK 的朝向会随另一条分支的姿态变化而漂移找了很久才发现是缓存边界划错了。3.3 同步组与同步标记走跑切换脚不滑的关键走和跑之间切换时如果两段动画各自从自己的第 0 帧开始混结果一定是滑步——因为左脚着地的时刻对不上。解决方法有两层。第一层是同步组。把参与同一套同步关系的动画序列归到同一个同步组里指定一个 Leader 和一个或多个 FollowerFollower 的播放进度会按归一化时间跟随 Leader。这样从走切到跑时新动画不会从头开始播而是接着当前进度往下走。第二层是同步标记。归一化时间对齐只能保证进度百分比一样但走和跑的周期长度不同百分比一样不等于落脚点一样。同步标记就是你在动画序列上打的命名时间点比如在左脚落地的位置打一个标记。切换时引擎会找目标序列里同名的标记把进度对齐到那个点上。这样切换才真正不滑。制作上有几个必须遵守的规矩违反了比不做还糟所有参与同步的序列都要在相同的相对位置打同名标记标记不能只在一半素材上打循环动画的第一个标记和最后一个标记的间隔要跟周期长度匹配。我见过最典型的问题就是只给跑的动画打了标记走的没打结果从跑切回走时跳得更厉害。3.4 分层混合与混合配置上下半身分离上下半身分离是几乎所有射击、动作游戏都要做的事下半身跟着移动走上半身跟着瞄准和射击走。实现方式是按骨骼分层混合。这个节点最容易被低估的是它那个网格空间旋转混合的选项。默认情况下旋转是在局部空间混合的也就是说只混相对于父骨骼的旋转。对于大多数骨骼没问题但对肩膀、上臂这种父骨骼本身也在大幅旋转的部位局部空间混合出来的结果可能是手腕扭曲、手肘反关节。把相关骨骼的选项切到网格空间混合的是世界朝向结果就正常了。配套的还有混合配置资产。它是一张按骨骼定义的权重曲线用来控制过渡时哪些骨骼参与混合、以什么权重参与。做上下半身分离时典型配置是让脊柱以下权重为 0完全不受上层影响、脊柱以上权重为 1。这里有个小坑骨盆和根骨骼的处理。如果你把骨盆也排除在外上半身的旋转不会带动骨盆看起来会像上半身浮在腰上如果全带上下半身的动作又被拖走。通常的做法是把骨盆留在下半身从脊柱某一节开始接管。3.5 用叠加动画处理叠加态有些东西不适合做成独立状态因为它们不是模式而是在某套模式上再加一层。比如瞄准时的上半身偏移、受伤时的轻微佝偻、持不同武器时的姿态差异。这类需求用叠加动画加瞄准偏移来做。叠加动画的核心是基准姿势的概念叠加动画记录的是相对于基准姿势的差值播的时候把这个差值加到当前姿势上。瞄准偏移本质就是一个二维的叠加动画横轴是水平瞄准角度纵轴是垂直瞄准角度。这里最常见的错误是基准姿势不统一。叠加层的差值只有在基准姿势一致的时候才有意义如果你一边用 A 姿势做基准生成的叠加动画一边在 B 姿势上应用它结果就是整体姿态偏移、比例失调。制作规范上要写死某套叠加动画只能用在同一个基准姿势上跨角色使用必须重新生成。4. 快路径与线程安全动画开销的分水岭前面几节讲的是怎么用这一节讲的是为什么同样的图别人跑 60 帧你跑 40 帧。答案大概率就在快路径和线程安全这两个词上。4.1 快路径到底快在哪Animation Blueprint 本质上是一张由蓝图层和原生节点层混合组成的图。图里每一个引脚要取值传统路径是调用一个函数拿到返回值这个函数可能是蓝图节点执行要走虚拟机压栈、参数搬运、类型转换、出栈。节点少的时候你感觉不到节点一多、角色一多这笔开销就非常可观。快路径做的事情是在编译期就把能确定的东西确定下来。如果某个引脚的取值方式是一个可以静态解析的属性路径编译器就能把它编译成从某个内存偏移读一个 float完全没有函数调用。骨骼索引的查找同理——如果每帧都要按名字去哈希表里查一次骨骼索引那是纯粹浪费快路径下这些索引会被提前缓存好。那么什么会破坏快路径以下几种情况很典型图里出现了必须走蓝图虚拟机才能求值的节点引脚绑定到了一个自定义的蓝图函数而不是属性路径节点在运行时被动态创建或替换。只要图里有一处走了慢路径整张图的求值效率都会受影响因为它没法用统一的快速上下文来跑。4.2 属性访问把函数调用换成属性路径属性访问就是配合快路径的取值方式。引脚绑定的时候不再选调用某个函数而是选一条属性路径从拥有者出发经过若干层属性最终落到一个具体的值上。比如速度大小可以表达成取拥有 Pawn → 取速度向量 → 取二维长度。这样做的好处有三层。第一层是省掉了虚拟机编译器可以直接展开成内存读取加一次长度计算。第二层是它天生是线程安全的因为只读属性、不执行任意逻辑所以可以在工作线程上安全地跑。第三层是可读性好属性路径在图上直接能看出来不像自定义函数那样得点进去才知道干了什么。要注意的是属性路径能访问的范围有限制。它只能走标记为可访问的属性碰到需要调用复杂逻辑的 getter 就走不通了。这时候的替代方案是在游戏线程的 Update 阶段把结果算好存进一个变量工作线程只读这个变量。4.3 线程安全更新把更新逻辑也挪出主线程在动画蓝图的类设置里有一个蓝图线程安全更新动画的开关。勾上之后更新阶段的逻辑会从游戏线程挪到工作线程去做。收益很直接主线程的压力小了。但限制也很硬你只能调用纯函数和明确标记为线程安全的函数不能碰 Actor 上那些没有线程安全保证的数据不能生成或销毁对象不能做任何会触发 GC 的事情。于是常规的做法变成这样一套组合拳在游戏线程的NativeUpdateAnimation里把这一帧需要的所有数据从游戏世界摘出来写进成员变量或代理的快照区。打开线程安全更新在NativeThreadSafeUpdateAnimation里只读那些已经摘好的数据算出状态机需要的所有判断量。AnimGraph 里的引脚尽量用属性访问直连到这些变量上避免再走一层函数。这三步做完你会发现原本堵在游戏线程上的动画开销被拆成了很轻的摘数据和很重但可以并行的算姿势。在角色数量多的场景里这个改动的收益通常是肉眼可见的。提示能不能开线程安全更新取决于你的项目能不能接受每帧数据都必须显式摘出来这个约束。这不是一个能渐进迁移的功能开了之后图里所有违规调用都会报警告所以最好在项目早期就把规范立起来。4.4 怎么确认自己有没有走快路径编译动画蓝图的时候输出面板会给出相关提示不同版本的措辞不太一样有的版本会明确列出哪些节点破坏了快路径有的只给一句笼统的警告值得把编译输出完整翻一遍。运行时想看节点级别的耗时可以用动画蓝图的调试视图它能显示每个节点的求值时间和调用次数也可以配合控制台里的动画相关统计命令——命令名字各版本有出入直接输stat加 Tab 补全找动画那一组把最耗时的几个组打开看就行。再深一层就是走Trace把动画通道打开配合回放工具看时序。这个在后面单独讲。5. 蒙太奇、通知与同步标记一次性动作的处理是动画蓝图里最容易被写乱的地方。它牵扯到槽位、段落、通知三套机制每套都有自己的隐性规则。5.1 槽位机制蒙太奇到底插在哪一层蒙太奇能播前提是 AnimGraph 里有一个槽位节点而且槽位名字要对得上。这一点看似简单实际上很多人第一次播不出蒙太奇就是因为名字写错了而且错了之后没有任何报错就是音讯全无。一个图里可以有多个槽位比如一个全身槽位、一个上半身槽位、一个叠加槽位。它们在图里的位置决定了层级上面的槽位覆盖下面的。所以通常的排布是——最底下是基础移动姿势中间是上半身槽位最上面是叠加槽位受击、呼吸之类的修饰。层级顺序错了表现就是明明播了蒙太奇但被别的姿态盖住了。5.2 段落与跳转连招怎么接蒙太奇里的段落就是时间轴上的命名区间。攻击连招的典型做法是第一段播到某个时间点如果玩家在这一小段时间内又按了攻击就跳到第二段没有按就播完收尾。这里有个容易忽略的参数——段落跳转的混合时间。默认值在连招里往往偏长导致每次接招都有一个明显的软过渡手感很肉。做动作游戏的时候我一般会把跳转混合时间压到很短甚至设成 0靠动画本身的设计来衔接。另一个细节是跳转的目标时间点。跳转时可以指定跳到目标段落的哪个归一化时间这样不同时长的招式也能对齐到同一个发力点。如果你的连招总觉得后一段起手太快八成就是这里没设。5.3 通知与通知状态通知是一个时间点上的触发播到那里执行一次。通知状态是一段区间有开始、有逐帧、有结束。选择哪个纯粹看需求脚步声、粒子特效、伤害判定这类瞬时的用通知进入无敌、持续位移、持续消耗这类有区间的用通知状态。性能上要注意通知的派发成本。通知是在动画求值过程中触发然后派发到游戏线程执行的。数量一多这个派发本身就有开销。我做过一个项目某个动作上挂了几十个细碎的粒子通知结果在低端机上这个动作会掉帧最后是合并成几个通知状态解决的。5.4 被跳过的通知一个真实存在的老问题前面提过动画时间不完全等于游戏帧时间。当更新频率被降低、或者蒙太奇的播放速率被改过、或者某帧掉得特别厉害时理论上应该依次触发的若干通知可能会被合并成一次或者被跳过。这个问题的麻烦之处在于它不可复现——编辑器里跑一百次都没事真机上偶尔出现一次。表现可能是伤害没结算、特效没播、音效缺失而且往往出现在最不该出问题的时候。我的处理办法有两条。第一条对必须发生的逻辑用通知状态而不是时间点通知。通知状态有区间只要区间被跨过就一定会有一次结束回调不会丢。第二条把伤害结算、状态变更这类关键逻辑从通知里挪出来改成由动作的播放进度或专门的时间线来驱动通知只负责表现层的东西特效、音效。这条原则一旦确立很多随机出现的诡异 bug 就消失了。5.5 蒙太奇与状态机的边界要守住我见过不少项目一开始蒙太奇用得很克制后来需求越来越多受击、闪避、技能、交互全塞进蒙太奇同时状态机里也有一堆类似的状态两边开始打架蒙太奇还在播的时候状态机切了或者状态机切了好几次但蒙太奇的槽位权重还没衰减完结果就是一个角色同时在播两套动作。比较稳妥的划分是移动相关的持续状态留在状态机里一次性动作全部走槽位并且在游戏逻辑层设置一个明确的当前是否处于不可打断动作中的状态让移动输入在这个状态下被过滤掉而不是让两层各自为政。听起来是游戏逻辑的活儿但它在动画这边的收益非常直接——你不再需要去猜这一帧到底是谁在控制姿势。6. 骨架、重定向与压缩资产侧的成本前面讲的都是运行时。真正在大项目里反复折磨人的很多时候是资产侧的几件事。6.1 Skeleton 是图纸改图纸要付代价骨架树里除了骨骼还有两类东西容易被忽略虚拟骨骼和曲线。虚拟骨骼可以建立额外的父子关系最经典的用法是手部 → 武器挂点——让武器骨骼挂在手部下方但不参与蒙皮这样武器可以跟着手走又不会影响身体的网格。曲线是骨架上的额外通道动画序列可以往里写值运行时读出来驱动各种逻辑比如左脚着地程度上半身扭转量。用它来驱动 IK 的权重、脚步的落地判定比用时间点通知要稳定得多因为它每帧都有值天然不会丢。但要注意共享骨架的代价一旦你改了骨架层级加骨骼、改父子关系所有引用这个骨架的网格、动画、蒙太奇都要重新构建而且重定向关系可能全部失效。所以骨架层级这种东西项目早期就要尽量定死后期改动是真正的伤筋动骨。6.2 重定向从老的流程到新的流程重定向是把一套骨架上的动画搬到另一套骨架上的过程。老流程是在重定向管理器里互设基准骨架新流程是IK 绑定加 IK 重定向器后者可以更精细地控制每根骨骼的朝向和位置偏移处理比例差异的效果好很多。无论用哪套流程重定向之后必须检查这几件事基础姿势是否一致。T-Pose 和 A-Pose 之间重定向肩部会出现明显偏差。手指和脚的长度比例。源角色和目标角色手指长度差异大的时候抓握动作会穿模脚长差异大的时候会滑步。双脚的接触点。走路动画重定向之后一定要逐帧看脚底和地面的接触很多滑步问题在这一步就能发现。我的习惯是重定向完先做一段原地走 原地跑把角色固定在原地看脚步感觉对了再进游戏里测。直接在游戏里测会被镜头和特效干扰反而看不清楚。6.3 压缩误差阈值调大之后会发生什么动画序列的压缩本质是用关键帧减少加误差容限来换体积。误差阈值调大体积小、内存友好但姿态会发飘——尤其是快速动作的中间帧可能会出现不自然的抖动或者穿模。曲线压缩是另一个独立的坑。驱动 IK 的曲线、脚步落地的曲线如果被压得太狠会出现权重跳变表现就是脚突然一沉或者手臂突然一僵。关键曲线一定要单独保护不能跟着骨骼一起压。高要求的项目可以考虑专门的动画压缩库插件来替换默认压缩方案代价是包体和构建时间。这个取舍要按项目的动画数量和目标平台内存来定没有普适答案。6.4 LOD 与骨骼裁剪网格的 LOD 会裁剪骨骼数量低级别 LOD 上某些骨骼会被合并或者丢弃。这在纯表演的动画上没问题但如果你在运行时还需要对这些骨骼做操作比如手部 IK、武器挂点就得把这些骨骼加进优先保留列表里否则低 LOD 下会出现武器挂不上手这种奇怪现象。再加上前面提到的节点 LOD 阈值这两者配合起来是一套相当有效的组合远处角色的骨骼数量少、执行的节点也少只在近处才把精度堆满。7. 上机排查从回放调试器到排查顺序理论讲完了最后聊实操。动画问题最难的地方从来不是不知道原理而是不知道这一帧到底是谁改的姿势。7.1 用回放调试器把时间倒回去Trace 系统里有一个动画通道配合时间轴回放工具使用效果非常好。它能让你像看录像一样倒回任意一帧看清那一帧里哪些动画实例在更新、状态机停在哪个状态、哪些槽位有权重、哪些蒙太奇在播、哪些通知被触发了。排查随机出现的姿势异常时这个工具几乎是唯一有效的手段。因为问题发生的瞬间你没法按暂停只能靠事后回放。我排查过一次角色偶尔会摆出一个奇怪的扭曲姿势最后就是靠回放发现在某一帧里两个槽位的权重同时是 1叠加出了畸形姿态——纯靠肉眼永远找不到。7.2 性能没达预期时的排查顺序动画掉帧的原因有好几种排查顺序很重要顺序对了能省掉大量时间。先数一数同时在更新的骨骼网格组件有几个。很多时候问题不在单个角色的动画有多重而在同屏组件太多。分清是游戏线程重还是工作线程重。是更新阶段的数据收集拖了后腿还是求值阶段本身太重。前者要精简游戏逻辑后者要看图里的节点和快路径。再看蒙皮开销。这是 GPU 侧的事和前面两步是分开的。如果 GPU 蒙皮是瓶颈调动画图是没用的。最后看通知派发。通知数量多、每帧都在往游戏线程派发的项目这一块的开销会出乎意料地大。顺着这个顺序查绝大多数动画卡的问题都能定位到具体某一环。反过来如果一上来就去调压缩设置、改混合时间基本是在瞎猜。7.3 几个我踩过的坑挨个说蒙太奇和状态机抢控制权。表现是动作播到一半被截断或者播完了姿态不回去。根因是两层各自以为自己说了算。解决方法是在游戏逻辑层明确仲裁别让两层同时活跃。开了更新率优化之后通知延迟。这个前面提过重要逻辑别依赖时间点通知。当时我们的解决方案是把伤害判定挪到了独立的时间线上。缓存姿势的边界划错。表现是 IK 结果漂移而且和另一条分支的状态相关。这类问题极其难查因为图里看起来完全合理。重定向完没看脚。跑起来挺好看一进游戏就滑步回头改又把别的姿势弄歪了。教训是先原地对脚再进游戏。叠加动画的基准姿势不统一。表现是整体姿态矮一截或者驼背而且只在特定角色上出现。这个纯属于制作规范问题前期定死能省很多事。7.4 后面还能往哪走这条链路摸熟之后往上还有几块值得看的方向。想让角色和场景做精确交互的可以看运动扭曲它能把根位移在运行时弯向一个目标点让开门、翻越、处决动作自动对准。想做程序化姿态的可以看控制绑定它把骨骼变成可编程的控制器配合后处理动画蓝图可以做基于物理的布料、头发、肌肉。再往后还有基于姿态搜索的运动匹配和数据驱动的动画选择机制这两块是近几年引擎侧比较活跃的方向。但无论往上做多花哨的东西底下的这条链路是不会变的游戏线程摘数据、工作线程算姿势、GPU 做蒙皮、组件层按重要度裁剪。我现在回头排查任何一个动画问题脑子里都是按这条线走一遍——大多数时候问题就藏在其中一个环节里只是被上层那些花哨的节点挡住了视线而已。
