1. 定位

AnimGraph 是 AnimBP 里"从若干动画算出最终姿势"的数据流图。它每帧求值一次，输出一个 Pose。

一句话定位：AnimGraph 是纯数据流，不是逻辑控制——逻辑判断放状态机，数值计算放这里。混着写会让图很快失控。

2. 节点分类与代价

类别	节点	代价
姿势来源	AnimSequence Player、BlendSpace Player、Pose Asset	低
混合	Blend、Blend by Bool/Int/Enum、Layered Blend per Bone、Blend Poses by Bool	低
叠加	Additive、Apply Additive、Make Dynamic Additive	中
状态	State Machine	见 `动画状态机`
骨骼控制	Two Bone IK、FABRIK、Transform (Modify) Bone、Look At	中—高（见 IK 与重定向）
过渡缓存	Inertialization、Blend Stack	低
缓存	Save Cache Pose / Use Cached Pose	负代价（省）
拷贝	Copy Pose from Mesh、Copy Bone	中
外部	Control Rig、Linked Anim Layer、Montage Slot	视内容

3. 三个最该会用但常被忽略的节点

Save Cache Pose / Use Cached Pose

把一段子图的结果缓存下来，在多处复用。典型："下半身姿势算一次，既用于基础又用于叠加层"。

这是 AnimGraph 里唯一能"省"的节点——其余节点都是纯开销。

Inertialization

用惯性过渡替代传统混合：不再需要真的混合两个姿势，直接从一个姿势"滑"到另一个，保留速度信息。

对比	传统 Blend	Inertialization
成本	需要同时求两个姿势	只求目标姿势
适用	长时间过渡	短促响应（受击、急停）
缺点	—	不适合长过渡（会失真）

Inertialization 是"短过渡"的性能正解，尤其配合 Blend Stack 用。

Layered Blend per Bone

按骨骼分层混合：上半身持枪、下半身跑步。用骨骼名 + 权重定义分层范围。

代价随层数与骨骼数上升；层数控制在 3 层以内。

4. 性能相关的写法

做法	影响
用 `Blend` 而非多个分支	分支会导致两条子图都求值（除非用状态机/Blend Stack）
Save Cache Pose	复用已算好的姿势
Inertialization	短过渡省一次求值
LOD 分支	远处用简化图（见动画性能）
骨骼 LOD	减少需要解算的骨骼
减少 Transform Bone 节点	每个都要遍历骨骼

最常见的浪费：同一个姿势在图上被算了三四次——用 Cache Pose 一次解决。

5. 代价与权衡

设计	收益	代价	什么时候不该用
分支（Blend by X）	直观	两条子图都可能求值	用状态机或 Blend Stack 更好
Additive	叠加层复用性强	需要构造 additive 动画	一次性动作不必
Layered Blend per Bone	上下半身独立	层数与骨骼数上升成本	层数控制在 3 内
Control Rig 节点	灵活	每帧解算	简单 IK 用节点更快
Transform (Modify) Bone	直接改骨骼	遍历骨骼，多了很贵	能用动画解决的别改骨骼
Inertialization	短过渡最省	长过渡失真	长过渡用普通 Blend

6. 踩坑与排查

坑	现象	怎么验证
分支导致两路都求值	性能翻倍	用状态机或 Blend Stack
姿势算了很多次	求值慢	加 Save Cache Pose
Additive 结果不对	没建 additive 动画	检查动画是否标记为 Additive
Layered Blend 范围错了	分层位置不对	检查骨骼名与权重
Transform Bone 太多	求值慢	合并或减少
Inertialization 用错地方	长过渡失真	长过渡改普通 Blend
图太大无法维护	—	拆成 Linked Anim Layer（见 AnimBP）
节点顺序导致结果异常	姿势被覆盖	按数据流逐节点观察（Pose Watch）

7. 排查顺序

1. 慢？→ stat anim；找被重复求值的子图 → Cache Pose
2. 姿势不对？→ 用 Pose Watch 逐节点看
3. 混合不对？→ 分支/Additive/Layered 的语义是否理解错
4. 过渡抖动？→ 过渡方式与时长
5. 图太乱？→ 拆 Linked Anim Layer