从 AnimBP
到 UAF

先放下骨骼和四元数，看一个具体的场景。后面每一章都会回到它。

假设你在做一个开放世界，有一座集市。集市里有两类角色：

两百个 NPC。摊贩、路人、巡逻的卫兵。他们要走、跑、转身、停下来交谈，用 Motion Matching 让移动自然。镜头里同时能看到几十个，远处还有上百个在动。他们几乎不播蒙太奇，也不需要网络同步。

一个主角"猎人"。玩家操作。攻击、闪避、处决、攀爬，大量用蒙太奇的分段和分支点；近战位移靠根运动；要支持联机。

用 Anim Blueprint 做这两类角色，问题分别出在两个地方。NPC 的问题是量：每个 NPC 都是一个完整的 UAnimInstance，事件图在游戏线程上跑，两百个加起来，游戏线程被动画吃掉一大块。主角的问题是结构：一个蓝图里塞着状态机、几十个蒙太奇插槽、IK、修正和一堆数据读取，谁都不敢动。

UAF 想同时回答这两个问题：把动画搬离游戏线程、让实例变轻，解决量；把逻辑拆成可叠加的小单元，解决结构。但读完全篇你会看到，它目前对 NPC 的帮助远大于对主角的帮助，因为主角依赖的蒙太奇、根运动、网络，恰好是 UAF 最不成熟的部分。第 8 章会把这个结论落到具体的试点方案上。

整份讲解都围绕三个问题：谁描述一帧动画要做的事、谁执行、在哪个线程执行。

开场的小人只有十几根骨骼，但它已经包含了动画运行时要做的全部基本动作。每根骨骼存的不是一个位置，而是相对父骨骼的旋转（再加上平移和缩放）。从骨盆出发，沿着骨骼链把这些相对旋转一层层乘下去，才得到每根骨骼在模型里的位置。这一步叫前向运动学（FK）。

把权重拖到 0.5。在"局部空间混旋转"模式下，每根骨骼的角度各取一半，再做 FK，四肢长度始终不变。切到"组件空间直接插位置"，同样是各取一半，但取的是关节的最终位置：手腕会从两套姿态的连线中间穿过去，前臂明显变短。这就是动画系统几乎总在局部空间里混合旋转的原因。

再打开上半身遮罩。下半身照常在两套关键帧之间混，上半身换成第三套姿态。每根骨骼有自己的混合权重，这就是分层混合（Layered Blend）。UAF 用 Hierarchy Table（一种按骨骼层级存数据的通用资产）来存这样一份按骨骼的权重表。

一帧动画就是把很多这样的操作按依赖关系串起来：采样几段动画、按权重混合、叠加修正、做 IK，最后写给网格。集市里的每个 NPC，每一帧都要把这串操作做一遍；两百个 NPC 就是两百遍。

一个骨骼网格有一棵骨骼树。每根骨骼存一个变换：旋转、平移、缩放。动画片段在每个关键帧上给每根骨骼一组这样的变换，运行时按时间采样，得到这一帧的姿态。

同一个变换可以放在三种空间里表达：

局部空间：相对父骨骼。动画数据就是这么存的，混合也在这里做。组件空间：相对网格的根，也叫模型空间。IK、瞄准、脚步贴地这类"要知道手在哪儿"的操作需要它。世界空间：再乘上组件在世界里的变换，物理和碰撞用它。

从局部到组件空间要沿骨骼链一路相乘，代价和骨骼数成正比，反过来也一样。所以运行时会尽量在一个空间里把能做的事做完，再统一转换一次。UAF 的求值任务里有专门的 ConvertRotationsToMeshSpace 和 ConvertRotationsToLocalSpace，就是这一步。

还有一个容易忽略的细节：不是每一帧都要算所有骨骼。远处的角色可以只算几十根主干骨骼，手指和面部全部跳过。这份"这一帧要算哪些骨骼"的清单，在 ABP 里叫 Required Bones，在 UAF 里体现为 LOD 姿态和骨骼映射（第 5.5 节）。

加法动画存的不是姿态，而是相对某个参考姿态的差。比如"呼吸"：用呼吸动画的每一帧减去它的第一帧，得到一组小小的偏移，可以叠到任意站姿、跑姿上。

Additive = Pose_anim ⊖ Pose_refResult = Base ⊕ α · Additive旋转的"减"是乘以逆四元数，"加"是相乘；α 缩放这份偏移

加法有局部空间和网格空间两种。局部空间加法把偏移加在每根骨骼自己的旋转上；网格空间加法把偏移加在组件空间的朝向上，适合"整个上身往左倾"这种不受下身朝向影响的修正。UAF 的 Apply Additive Trait 两种都支持，还有一个按骨骼遮罩的版本。

骨骼遮罩就是开场的"上半身遮罩"：每根骨骼一个 0 到 1 的权重。ABP 里它叫 Blend Profile 或 Layered Blend per Bone 的设置；UAF 用 Hierarchy Table 存它，这是一个通用的"按层级存数据"的资产，Blend Mask 只是它的一种用法。

还有一种特殊的加法叫动态加法：不预先存差值，而是运行时拿两个当前姿态相减。UAF 里有 Make Dynamic Additive Trait 和对应的任务，可以把一段普通动画当成加法用。

把走路和跑步按 0.5 混合，如果两段动画各自按自己的时间播放，会出现左脚还在走路的第 0.3 秒、右脚已经是跑步的第 0.1 秒，画面上就是一顿乱踩。

同步组的做法是选一个领头（通常是当前权重最大的那段），其他成员不按自己的时间走，而是按"归一化进度"跟随：领头走到 40%，大家都在 40%。走路一个周期 1.2 秒、跑步 0.8 秒也没关系，它们会被同时拉伸或压缩。

只按百分比对齐还不够，因为两段动画的左脚落地点不一定都在 0%。同步标记在动画上打"左脚落地""右脚落地"这样的标签，同步时按标记区间对齐，领头处在"左脚落地到右脚落地的 30%"，跟随者也被拉到它自己那一段的 30%。

UAF 把这件事拆成了一个独立的 Trait（Trait 是 UAF 里最小的逻辑单元，第 4 章细讲）：Synchronize Using Groups，按组名把时间线同步起来。时间线本身由 ITimeline 接口（Trait 之间协作用的接口之一，第 4.5 节）暴露，每个能报告进度的 Trait（比如 Sequence Player）都实现它，同步 Trait 通过接口读写，不需要知道下面挂的是什么。这是"组合"思路的一个典型例子。

从一段动画切到另一段，最朴素的做法是交叉淡化：在过渡时间里两段都算，权重从 1:0 渐变到 0:1。它的问题有两个。第一，过渡期间要同时采样两段动画，层层嵌套时代价成倍增长。第二，如果切换很频繁（比如 Motion Matching 每几帧就换一段），会同时挂着好几段在淡出。

惯性化（Inertialization）换了一个思路：切换的瞬间只记下旧姿态和新姿态之差，以及差值的变化速度，之后只算新动画，再把这份差值按一条平滑曲线在过渡时间内衰减到零。每帧只采样一段动画。

先看"走 → 跑"，速度调到 0.25×。硬切在切换那一帧，手脚的轨迹直接折断，这就是"跳帧"。交叉淡化的轨迹最圆滑，但过渡期间"采样"变成 2。惯性化和 Dead Blending 的轨迹同样没有折断，采样却一直是 1。

再切到"频繁切换"：交叉淡化的采样数会涨到 3 甚至更多，因为上一段还没淡完，下一段又来了。Motion Matching 每隔几帧就可能换一段，这就是它几乎都配惯性化的原因。最后看"挥臂反向"，打开"目标姿态虚影"：惯性化的前臂带着旧速度冲过虚影再拉回来，Dead Blending 冲得更少。

下面这张曲线图把同一件事压成一根骨骼的角度，能读出具体的过冲量。

切到"惯性化"，过渡期间底部的条只剩一格，因为只算 B；实线从 A 的值出发，带着 A 的速度，平滑地落到 B 上。切到"交叉淡化"，过渡期间是两格。

惯性化有一个已知的弱点：差值曲线只看切换瞬间，如果 B 的运动方向和 A 相反，衰减曲线会冲过头。Dead Blending 是近几年的改进：不再记录"差值"，而是把旧动画 A 按切换时刻的速度向前外推，速度逐渐衰减，再和 B 做普通的交叉淡化。它仍然只采样一段真实动画，外推几乎不要钱，结果对方向相反的情况更稳。

UAF 三种都有：Blend Two Way 这类 Trait 做交叉淡化，Blend Inertializer 做惯性化，Dead Blending 有专门的过渡任务和应用任务（DeadBlendingTransitionTask / DeadBlendingApplyTask）。

角色往前走，可以有两种因果关系。

胶囊体驱动：移动组件按输入算出速度和位置，动画系统读这个速度，挑一段合适的走路动画来播。脚和地面可能对不上（滑步），需要靠步幅调整、Stride Warping 之类的手段修。

根运动驱动：动画里根骨骼的位移被提取出来，交给移动组件，角色按动画走。脚步自然贴地，但响应慢，网络同步也更麻烦，因为移动结果取决于动画状态。

实际项目多是混用：日常移动用胶囊体驱动，翻越、攀爬、处决这类精确动作用根运动。Motion Matching 让这个界线更模糊：它用轨迹（角色过去和未来几秒的位置朝向）去搜动画，动画天然贴合预测的移动。

这件事对 UAF 有直接影响。根运动意味着动画结果要回流给移动组件，而 UAF 想在游戏线程之外算动画；两者之间的时序必须被显式安排。这就是为什么 UAF 组件上有一个 bSetupCharacterMovementDependency，以及为什么 5.8 的 Mover 和 UAF 有一个专门的桥接插件（第 6.11 节）。

把胶囊体速度拖到和动画自带速度差不多，左边的点就重合了；拖快或拖慢，点就拉成一串。这就是"胶囊体驱动会滑步"的直观样子。右边永远不滑，但它的速度是动画决定的，玩家推摇杆的力度改变不了它，除非换一段动画。

下面按时间排了几条线索。UE 自己的一条在上面，业界的做法在下面。它们最后汇到同一个方向：逻辑和求值分开、逻辑可组合、求值离开主线程。

表里最值得注意的一行是 UE 5.0 到 5.4。Pose Search、Chooser、Blend Stack 都是塞进 ABP 里的独立部件：它们已经按"数据驱动、可组合"的方式设计，只是宿主还是 ABP。UAF 做的事，某种程度上是把宿主也换掉。

ABP 每帧分两步走。理解这两步，是理解 UAF 一切设计的前提，因为 UAF 保留了这个划分，只是把每一步的做法换掉了。

Update：推进时间、读取游戏数据、决定权重。事件图里的 Blueprint Update Animation 先跑，把角色速度之类的值写进动画蓝图的成员变量；然后动画图从根节点往下走一遍，每个节点调用自己的 Update_AnyThread，播放器推进时间，混合节点算权重，状态机判断要不要转换。

Evaluate：真正算姿态。动画图再从根往下走一遍，每个节点调用 Evaluate_AnyThread，播放器采样关键帧，混合节点把子节点的姿态混起来，结果一层层返回到根。

注意第 3 步的形状：Evaluate 是递归的，每个节点调用子节点的 Evaluate，拿到一个姿态对象，处理完再返回。这意味着姿态在调用栈上层层传递，每个节点都持有自己的临时姿态，算什么和怎么算混在同一个函数里。UAF 把这一步拆成了"先写程序、再跑程序"（第 5 章）。

把上面几节合起来，ABP 的问题可以归成五条。它们都不是 bug，而是结构决定的。

最后一行值得多说一句。ABP 的每个实例都是一个完整的 UObject，带着整个类的成员变量和节点结构。UAF 把一张图分成共享的只读部分（节点描述、Trait 的配置）和每个实例的可写部分（时间、权重之类），几百个角色共用前者（第 4.4 节）。这是巫师 4 演示里"几百个角色"的结构基础之一。

ABP 的问题在于它是一个什么都能做的对象。UAF 的思路是把能做的事收窄，换取可组合、可并行、可共享。

把 UAF 的设计压成三个词：

数据流。输入是显式绑定进来的值，输出是写给网格的姿态。中间每一步读什么、写什么都在图上看得见。插件描述里那句"功能性数据流"指的就是这个。

组合。最小单元是 Trait，Trait 叠成节点，节点连成图，图可以嵌套成子图，也可以由代码按需生成。复用靠组合，不靠继承。

离开游戏线程。System 的事件可以被安排在指定的 Tick Group 里，在工作线程上运行。这是 UAF 的设计目标，但证据目前偏少：最直接的一条来自社区教程，作者报告配好之后角色做 Motion Matching 时不再占用游戏线程的时间；Epic 员工只说"性能是首要目标，会尽量并行"。所以本文把它当作"结构上可信、有待你自己测"的结论。

按 Eyad 的整理，这条链可以写成：输入 → 绑定 → System → 图 → Trait Stack → 最终姿态。后面两章就沿着这条链一段段拆。

在内容浏览器的 Animation 分类下，启用插件后会多出一个 Animation Framework 子菜单。5.8 里常用的资产有这几种：

几点说明。

System 是根资产。API 里 UUAFSystem 的说明是"组件实例化时所代表的根资产"，它的显示名是 "UAF System"，类声明却仍在 Module/AnimNextModule.h 里。看到旧教程里的 Module，在 5.8 里对应 System。

共享变量的名字变过。5.6 的资产菜单里有 "UAF Data Interface"；5.8 的 UUAFSystem 继承自 UUAFSharedVariables，图工厂的参数也用 "Public Variables Asset" 的说法。本文推断 Data Interface 演变成了共享变量，具体名称以你用的引擎版本为准。

可以用向导一次生成。社区教程提到 5.8 有一个 UAF Asset Wizard：选模板、角色蓝图和骨骼网格，自动生成 Workspace、System、Graph 和角色设置，命名形如 UAF_W_Character、UAF_S_Character、UAF_AG_Character。

一个最小的 System 只有两个事件：

Initialize：调用 Make Reference Pose，生成参考姿态，作为图的初始状态。PrePhysics：调用 Run Graph 跑一遍动画图（内部就是 Update 和 Evaluate 两次遍历），再调用 Write Pose 把结果写给网格。如果要做 Motion Matching，还要在 Run Graph 之前先生成轨迹。

事件不是固定的几个。System 里的每个事件都是一个"用户事件"，带着三样东西：名字、它要在哪个 Tick Group 结束（end_tick_group），以及同一 Tick Group 内的先后顺序（sort_order）。PrePhysics 和 PostPhysics 是两个预设好的事件，分别在世界物理更新之前和之后运行。

切到"ABP · 事件图"，游戏线程上有一段明显的事件图开销，动画图的 Update 要等它跑完。切到"ABP · 线程安全更新"，事件图挪到了工作线程，游戏线程只剩准备和收尾。切到"UAF"，游戏线程上只剩一段很短的"拍快照"：绑定的变量在这里被读出，之后 System、两次遍历、求值 VM 和写姿态都在工作线程上。

放回集市的例子：两百个 NPC，在 ABP 下是两百段游戏线程上的事件图；在 UAF 下是两百段很短的拍快照，加上两百个可以在工作线程上并行的 System。主角"猎人"如果还留在 ABP，他的那一段照旧。

要注意两点。第一，这张图的长度是示意，不是测量值；真实开销取决于图的复杂度和角色数。第二，"在工作线程上"不等于"不要钱"，它只是把开销从最容易成为瓶颈的游戏线程挪开，并让多个角色可以并行。

ABP 的事件图可以随手调用 GetVelocity()。UAF 不让动画线程直接碰游戏对象，数据必须通过三条路之一送进来：

变量绑定：在 System 里声明一个变量，比如 Velocity，把它绑定到"当前 Actor → Get Velocity"。编译器会为这些绑定自动生成两个执行单元，一个在游戏线程跑（ExecuteBindings_GT），一个在工作线程跑（ExecuteBindings_WT）。需要碰 UObject 的读取放在前者，纯计算放在后者。

组件上的 Set Variable：游戏代码通过 UUAFComponent::SetVariable 或蓝图节点写值。写入不会立刻被动画线程看到，而是进入一个代理，每帧把"变脏"的变量拷过去。5.6 的源码笔记里这个代理叫 PublicVariablesProxy，作者提到计划改成类似骨骼网格组件那种双缓冲。

输入绑定到组件：BlueprintSetInputBinding 可以把一个类型为 FValueBundle 的输入变量绑定到某个组件，由那个组件按值提供一包数据。5.8 的 UAF Anim Node 里有一个 Input Value 节点，就是在 PreUpdate 时从图变量里读出这样一包值，压到求值栈上（这是 5.8 新出现的另一套节点系统，第 6.13 节）。

这就是开场比喻里的"快照照片"：动画线程开工前拿到一张照片，之后世界怎么变都不影响这一帧。代价是动画总是基于这一帧开头的数据，如果移动组件在同一帧稍后又改了速度，动画看不到。需要严格先后关系的地方，要靠下一节的 Tick 依赖来保证。

Epic 员工在 2026 年的论坛回复里也提到，游戏数据会在图运行的线程上可访问，但这部分设计还在变化。所以这一节的细节请以你手上的引擎版本为准。

让一个角色用上 UAF，需要两步：在 Actor 上加一个 UAF 组件（5.8 里类名是 UUAFComponent，头文件仍叫 Component/AnimNextComponent.h），并关掉骨骼网格组件自己的动画。社区教程特别提醒：骨骼网格上的动画不完全关掉，UAF 不会运行。

组件上值得认识的字段和函数：

这张表里最能说明设计取向的是那一组 Prerequisite / Subsequent。ABP 的时序大多是隐式的：动画在移动之后、物理之前，引擎替你安排好了。UAF 把每个事件都暴露成可以挂依赖的 Tick 函数，时序由你声明。好处是可以把多个角色、多个系统的先后关系精确地排出来（比如骑手的动画要在马之后）；代价是你要自己想清楚。

还有一个细节：组件实现了 ISystemOutputAdapter 接口。输出不一定是骨骼网格，人群可以写到实例化蒙皮网格（第 6.10 节）。

按 RemRemRemRe 的源码笔记，Trait 是一个可复用的动画逻辑单元，大致相当于 ABP 的一个节点，但粒度更小。在类层次上：

FTrait 是基类。具体的 Trait 继承 FBaseTrait 或 FAdditiveTrait 之一，再加上若干个 ITraitInterface 接口。前者是"基础 Trait"，能独立构成一个节点；后者是"加法 Trait"，只能叠在基础 Trait 上面，去覆盖或修改它的行为。

和 ABP 节点最大的区别有三个：

无状态。Trait 对象本身不存任何每实例的数据，因为同一个 Trait 要在很多线程上被很多角色同时调用。状态放在别处（第 4.3 节）。

按接口协作。Trait 之间不直接调用对方的函数，而是通过接口：一个 Trait 说"我实现了 ITimeline"，需要时间线的 Trait 就向它所在的栈查询这个接口。

可以叠。同一个节点上，基础 Trait 负责主要行为，加法 Trait 负责修改。开场比喻里的乐高积木就是指这个。

最后一行有个细节：编辑器里的 Trait Stack 节点只用于显示。编译时它被序列化进图的数据里，运行时不会执行这个节点本身。

一个节点里的 Trait 从下往上排：最底下是基础 Trait，上面是加法 Trait。当有人对这个节点调用某个接口时，调用从栈顶开始：栈顶的 Trait 如果实现了这个接口，就由它处理，它可以选择再把调用转给下面的 Trait（类似调用 Super）；如果没实现，就直接落到下一个。

试试选 IEvaluate，再把"镜像"和"曲线修改"都勾上。调用先到镜像：它在子节点求值之后要加一个"镜像"任务，所以它把调用往下转，最后由 Sequence Player 压入采样任务，回来时镜像再追加自己的任务。再选 ITimeline，调用会直接穿过两个加法 Trait 落到 Sequence Player，因为只有它知道播放进度。

官方 API 对 IEvaluate 的说明正是这个顺序：节点被访问时，先调用栈顶 Trait 的 PreEvaluate，它再转给栈里下一个实现了 IEvaluate 的 Trait；然后通过 IHierarchy 查询子节点并求值；最后在原来那个 Trait 上调用 PostEvaluate。

所以加法 Trait 能在不改动基础 Trait 的前提下，在它前后插入自己的行为。这就是 UAF 的扩展方式。

Trait 无状态，可一个 Sequence Player 总得记住播到第几秒。UAF 把数据分成三类，各放各的地方：

共享数据（Shared Data）：只读、可序列化，通常是在编辑器里配好的参数，比如播放哪段动画、播放速率、是否循环。同一张图被一百个角色使用，共享数据只有一份。源码笔记把它比作 ABP 里的 FoldProperty。

实例数据（Instance Data）：每个图实例一份，原生 C++ 数据，比如当前播放时间。类似 State Tree 的实例数据。

潜在属性（Latent Properties）：那些既属于配置、又需要每实例单独求值的成员，比如"混合权重"这个参数连到了一个变量，每个角色的值不同。它们定义在共享数据里，但运行时的值存在实例数据后面。

这个划分的意义在角色数多的时候才显现。一百个角色用同一张图，只读部分只占一份内存，每个角色只多出一组紧凑的实例数据。这和 ABP"每个角色一个完整 UObject 实例"形成了鲜明对比。

写自定义 Trait 时，这三类数据各有对应的宏和结构（附录 A.4 有一个代码骨架）。最容易犯的错，是把应该放在实例数据里的东西写成了 Trait 的成员变量：它在单线程测试里看起来正常，一上多角色就会互相覆盖。

上一节的三类数据，落到运行时是三个对象。它们的关系是理解 UAF 内存布局的关键：

节点模板（FNodeTemplate）："一个节点由哪几个 Trait、按什么顺序组成"。它是共享的、只读的，同样组合的节点只存一份模板，模板后面紧跟着每个 Trait 的 FTraitTemplate。全局的模板注册表把所有模板放在一块连续内存里。

节点描述（FNodeDescription）：图里一个具体节点的只读数据。对象本身 8 字节，后面跟着各个 Trait 的共享数据。多个节点描述可以指向同一个模板（比如图里有十个 Sequence Player）。它们都存在图资产的 SharedDataBuffer 里。

节点实例（FNodeInstance）：运行时为每个图实例分配的数据。对象本身 16 字节，带引用计数，后面跟着实例数据和潜在属性。

运行时查询 Trait 的入口是两个"绑定"对象：FTraitStackBinding 指向一个节点的整个 Trait Stack，FTraitBinding 指向其中一个 Trait，带类型的版本是 TTraitBinding<接口>。前一节交互图里"调用沿栈往下走"，在代码里就是从一个 Trait Binding 拿到"栈里下一个实现了这个接口的 Trait"的 Binding。

注意节点实例是引用计数的。一个节点在混合中淡出、权重变成零之后，它的实例可以被释放；重新变得"相关"时再分配，并收到 OnBecomeRelevant 回调。这和 ABP"整个实例常驻"的做法不同，也是 UAF 能做轻量实例的原因之一。

接口是 Trait 之间唯一的协作方式。每个接口类 ITraitInterface 只有一个方法：返回自己的唯一 ID。ID 由类名的 FNV1a 哈希在编译期算出，用 DECLARE_ANIM_TRAIT_INTERFACE 声明，用 AUTO_REGISTER_ANIM_TRAIT_INTERFACE 注册到全局表里。

5.8 的 API 参考里列出了这些接口，按用途分组如下：

两点值得注意。

混合被拆成了好几个接口。"离散混合"（在几个子节点之间选一个，比如按布尔值切换）和"连续混合"（按权重混合）是不同的接口，平滑和惯性化又是另外的接口。一个 Blend Smoother 加法 Trait 只要找到下面那个实现了 IDiscreteBlend 的 Trait，就能给它加上平滑，不管它是按布尔、按枚举还是按整数在选。

IUpdate 携带一个状态对象往下传。FTraitUpdateState 里有本次推进的时间、累计权重、累计轨迹权重，以及"正在淡出""刚变得相关"两个标志。它的修改方法都返回新副本，比如 WithTimeScale、WithWeight，所以父节点可以给每个子节点派生一份不同的状态，而不影响自己。第 5.1 节会看到它怎么在遍历里流动。

下面是社区教程按用途整理的 Trait 列表，和 5.8 API 里的共享数据结构基本对得上。这张表也是第 8 章"哪些可以先试"的原材料。

从这张表能读出几件事。没有"状态机"Trait：状态逻辑交给了 State Tree。没有"蒙太奇"Trait：临时插入动画靠 Injection Site（第 6.7 节）。没有"计算方向"：社区教程提到 UAF 里没有现成的 Calculate Direction 节点，要自己用速度和朝向算。这些"没有"是迁移时最先要面对的。

Update 遍历的任务是让每个相关的 Trait 推进时间、更新权重、决定子节点里谁还相关。按源码笔记，FUpdateTraversalContext 用一个在 MemStack 上分配的后进先出栈做深度优先遍历，不用递归。

每访问一个节点，先调用它的 IUpdate::PreUpdate，然后把它的子节点压栈；子节点都处理完之后，再回到这个节点调用 PostUpdate。一个节点刚变得相关时，还会收到 OnBecomeRelevant。

看右边每个节点收到的更新状态。根节点收到 dt = 1/60 秒、权重 1。混合节点的 alpha 是 0.3，它给走路派生一份权重 0.7 的状态，给跑步派生一份权重 0.3 的状态。这就是第 4.5 节说的"按副本派生"。Blend Two Way 自己不管同步；如果要让走跑的脚步对齐，节点上还要叠一个 Synchronize Using Groups Trait（第 1.4 节），由它通过时间线接口调整跟随者的进度。

为什么不用递归？递归的调用栈深度由图的深度决定，栈帧里还藏着各个节点的临时变量；显式的栈只存"接下来要访问谁"，大小可控、分配在线程局部的内存栈上，遍历过程也更容易在中途检查和调试。

Evaluate 遍历的顺序和 Update 相同：进节点调用 IEvaluate::PreEvaluate，处理子节点，回到节点调用 PostEvaluate。区别在于这两个函数不返回姿态，而是往一个 FEvaluationProgram 里追加任务。

对我们的小图，遍历会这样写程序：走路播放器追加"采样走路第 t 秒"，跑步播放器追加"采样跑步第 t 秒"，混合节点在 PostEvaluate 里追加"按 0.3 混合栈顶两个姿态"，镜像 Trait 最后追加"镜像栈顶姿态"。（5.8 的公开任务清单里没有镜像任务，它来自 UAF Mirroring 插件，演示里的 Mirror* 是示意名。）

注意任务的顺序正好是后序遍历：先子节点、后父节点。这不是巧合。父节点的操作要用到子节点的结果，而 VM 是栈式的，子节点的结果按顺序压在栈上，父节点的任务执行时正好从栈顶取。这和逆波兰表达式 3 4 + 是一回事。

权重为零的子节点在 Update 时就已经被判为不相关，Evaluate 不会走进去，程序里自然没有它的采样任务。ABP 里同样有"权重为零就跳过"的优化，但它是每个混合节点自己判断；在 UAF 里，它是遍历结构的一部分。

程序写好之后，交给 FEvaluationVM 执行。VM 里有若干个按名字和类型区分的栈（FEvaluationVMStack），最主要的一个放的是关键帧，也就是整套骨骼的姿态。每个任务从栈上取输入，把结果压回去。

逐步执行一遍：两个采样任务各压入一个姿态；混合任务弹出两个、压回一个；镜像任务弹出一个、压回一个。程序结束时，栈上正好剩一个姿态，就是这一帧的结果。

5.8 的任务清单（第 8 章的准入表里也会用到）大致分这几类：

注意"混合"有两种：Overwrite 是"栈顶 × 权重 覆盖进累加器"，Add 是"栈顶 × 权重 加进累加器"。多路混合（比如 Blend Stack 里五段动画）不是两两混合四次，而是先用 Overwrite 放第一段，再用 Add 依次加上其余各段，最后统一归一化旋转。这正是第 1.2 节说的"加权求和后统一归一化"。

还有一个枚举 EEvaluationFlags，API 说明是"控制求值一个节点时要计算哪些东西"。可以理解为：如果这一帧不需要曲线或属性，任务可以跳过它们。

栈上的"关键帧"在代码里是什么？公开资料能确定的有这几点：

姿态带着 LOD。System 和图之间传递的姿态类型叫 AnimNextGraphLODPose（在 Python API 里可见，比如"写姿态到实例化蒙皮网格"的节点就以它为输入）。也就是说，姿态从一开始就知道自己处在哪个 LOD、包含哪些骨骼，而不是一套完整骨架再加一个"需要哪些骨骼"的掩码。

有专门的骨骼映射。API 里有 FAnimNextBoneMapping，以及一个"重映射姿态"的 RigVM 单元 RigUnit_AnimNextRemapPose。这和跨骨架使用动画有关：动画资产的骨骼顺序和目标网格不同，需要一张映射表。

变换数组有 AoS 和 SoA 两种写法。源码笔记提到，TransformArrayOperations.h 里每个工具函数都有"结构体数组"和"数组结构体"两个版本。SoA 把所有骨骼的旋转放在一起、平移放在一起，更适合批量数值运算；笔记作者观察到当时的代码仍偏向 AoS。

附录 B 的迷你实现会直接用 SoA，并在里程碑 2 解释为什么。

UAF 不再依赖骨骼网格组件的 Tick。System 里的每个事件都会变成一个可调度的单元：

Tick Group 与顺序。每个用户事件指定它要在哪个 Tick Group 结束，以及同组内的排序值。源码笔记提到，事件的基类还控制"是否给模块单独建 Tick 函数""放在哪个 Tick Group""是否在游戏线程上运行"。

显式依赖。组件上的 AddPrerequisite / AddSubsequent 把任意 Tick 函数挂到某个事件之前或之后；AddComponentPrerequisite 针对组件的主 Tick；AddModuleEventPrerequisite 针对另一个 UAF 组件的事件。FindTickFunction 可以按事件名找到对应的 Tick 函数。

插队的任务。QueueTask 把一段 lambda 排到指定事件上，并用 ETaskRunLocation 指定它在事件之前还是之后之类的位置运行。这是游戏代码在动画线程上"顺手做点事"的正规入口。

ABP 时代，这类依赖大多由引擎在幕后安排（移动 → 动画 → 物理），少数特殊情况才需要手动处理。UAF 把它们全部摆到台面上。对小项目这是额外的工作；对角色互相依赖的大项目，这是一个早该有的控制面。

二十个插件按名字排没有意义。按"一帧动画要回答的问题"来排，它们会自然落进六组。读这一章时，可以随时回到这张表。

对照最后两列就能看出第 8 章结论的来源：集市 NPC 用到的几行（播什么、怎么接上、结果给谁）恰好是社区验证最多、官方已经在用的部分；主角用到的几行（临时插入、根运动、大量通知与 IK）恰好是缺口最大的部分。

混合在 UAF 里被拆成了几层，对应第 4.5 节的几个接口：

选谁：Blend by Bool 这类 Trait 实现离散混合，按条件在几个子节点间选一个。按权重混：Blend Two Way、Blend Layer 实现连续混合。怎么过渡：Blend Smoother 系列给离散混合加上平滑过渡，Blend Inertializer 改用惯性化，Dead Blending 有专门的任务。栈式混合：Blend Stack 系列实现第 2.7 节的后进先出混合栈。

这种拆法的好处在组合时体现。比如"按布尔切换、用惯性化过渡、只作用于上半身"，在 ABP 里要么找一个恰好有这些选项的节点，要么嵌套三层；在 UAF 里是一个 Blend by Bool 基础 Trait，上面叠一个惯性化 Trait，再叠一个按骨骼的平滑 Trait。

有一个容易踩的点：惯性化需要知道"切换发生了"，以及切换前的姿态和速度。它通过接口从下面的离散混合 Trait 得到切换事件，再用 Pose History（保存最近几帧姿态的 Trait）拿到速度。如果你的图里没有这些部件，惯性化就无从下手。这和 ABP 里"必须在上游放一个 Inertialization 节点"是同一类约束，只是表现形式不同。

Motion Matching 是目前社区里用 UAF 做得最多的事，也有比较完整的教程。按 5.7 的一篇设置教程，图里的做法是：先求值一张 Chooser 表，选出要用的 Pose Search 数据库；再把数据库和预先算好的轨迹喂给 Motion Matching 节点。

需要三样东西：Pose Search 数据库（动画素材）、Pose Search Schema（比较哪些骨骼和哪些轨迹点）、Motion Matching Trait。轨迹由 System 在跑图之前生成，有两个现成节点：Generate Trajectory from Character Movement Component 用于标准角色移动组件，Generate Trajectory from Mover 用于 Mover。社区教程里的一组参数是：历史采样 30 个、预测采样 15 个、预测采样间隔 0.1 秒。

5.8 有两条相关的更新。GASP 的 Mover 角色换用了一个新的 Chooser，带改进后的 Pose Match 列，可以在多个内部 Pose Search 数据库里做匹配，Blend Space 也能放进 Chooser 和 Blend Stack。ChaosMover 增加了供 Motion Matching 用的轨迹预测。这两条都是在 ABP 上做的，但它们用到的 Chooser 和 Pose Search 正是 UAF 也在用的同一套。

社区教程报告了一个让人振奋的结果：这样配好之后，角色做 Motion Matching 时不再占用游戏线程。但同一篇教程也提到，图在编辑器里显示为半透明的"非激活"状态，作者认为是功能还在开发中。

ABP 的状态机长在动画图里：状态、转换条件、每个状态播什么，全画在一张图上。UAF 没有状态机 Trait，状态逻辑交给引擎通用的 State Tree，通过 UAF State Tree 插件接入（API 里仍叫 AnimNextStateTree）。

5.5、5.6 的 API 参考把它的结构说得比较清楚：

把这几条拼起来，就能看出"状态"在 UAF 里是怎么变成姿态的：

图里有一个 State Tree Trait，它持有一棵状态树，并在 Update 时让它 Tick。状态树进入某个状态时，状态上的 "AnimNext Graph" 任务把一张动画图压到混合栈顶；混合栈负责把新压上来的图和下面正在淡出的图接起来（惯性化或交叉淡化）。转换条件和任务可以用 RigVM 写，所以它们和 System 一样能在工作线程上跑。

这个设计的含义是：ABP 里"状态 + 转换"两件事被拆开了。状态树只决定"现在该在哪个状态、该播哪张图"；"怎么过渡"统一交给混合栈。ABP 状态机里每条转换线上配的混合时长、混合曲线，在 UAF 里不再挂在转换上，而是由混合栈或惯性化 Trait 的设置决定。迁移状态机时，这是最需要重新想的一点。

另外两个好处：状态可以嵌套，有进入条件、任务、转换和评估器，比扁平的状态机更适合表达"战斗中 → 持枪 → 瞄准"这样的层级；动画和 AI、玩法共用同一种状态工具。

仍然缺的信息：5.8 版本的类名是否已改为 UAF 前缀、任务实例数据里有哪些字段（图资产、混合设置）、能否从状态树向图传参数。这些 API 页没有写，需要在引擎里确认。

蒙太奇是 ABP 里"临时播一段动画"的主力：攻击、受击、交互，都是往某个插槽里插一段蒙太奇。UAF 目前不支持蒙太奇，Epic 员工在 2026 年 5 月的论坛回复里说，以后是否支持也还不确定，有讨论和实验，但没有定论。

UAF 的替代机制叫 Injection，对应开场比喻里的"插播广告"。图里预先放一个 Injection Site（插入点）Trait，运行时可以往这个点注入东西，用完再撤掉。

插入点用 FAnimNextInjectionSite 指定：一个指向图变量的引用（期望的插入点），加一个"找不到时是否退回模块默认插入点"的开关。也就是说，一个 System 可以有一个默认插入点，调用方不指定时就插到那里。蓝图侧有 UUAFInjectionLibrary 和对应的异步节点。

和蒙太奇比，Injection 缺了不少东西：没有分段、没有分支点、没有"跳到某段"、没有内置的插槽组互斥，也没有和网络复制的现成整合。它更接近一个底层原语："在这个点把这段东西混进来，结束时告诉我"。你项目里用到的蒙太奇特性越多，迁移成本越高，这是评估 UAF 时最该先盘点的一项。

人群是 UAF 最有说服力的场景。巫师 4 技术演示（UE 5.6，基础版 PS5 上 60 帧）里有大量 NPC，CD PROJEKT RED 的博客把 UAF 和 Mass 都列为演示展示的工具，Unreal Fest 2025 还有一场专讲 UAF 在演示中应用的演讲。

5.8 里和人群相关的几块：

UAF Mass 插件："UAF 的 Mass 集成"，依赖 MassGameplay、UAF 和 UAF Anim Graph。

写到实例化蒙皮网格：有一个 RigVM 单元 UAFWriteInstancedSkinnedMeshPose，把姿态写到实例化蒙皮网格组件（ISKM）。ISKM 继承自蒙皮网格组件而不是骨骼网格组件，不支持 Anim Blueprint，Epic 员工在论坛里说得很明确。所以在 ISKM 上用"图驱动"的动画，UAF 是现在唯一的官方选项。

MetaHuman Crowd：5.8 版本说明写到，MetaHuman 人群"按距离使用 Unreal Animation Framework 或简单序列来应用动画"。远处的角色用 ISKM，并且不运行后处理 Anim Blueprint。

Epic 员工对"Hitman 式人群"的建议是 5.8 起用 Mass + ISKM + AnimSequenceTransformProvider（一种生成 GPU 格式动画数据的方式，比 AnimBank 更灵活）。那条建议没有提 UAF，说明"简单序列"这一层完全可以不用 UAF；UAF 的位置是在中间那一层，需要混合和逻辑、又不值得一个完整 Actor 的角色。另外论坛上有人报告 5.8 中 Mass + ISKM 反复生成销毁时动画轨道池持续增长，评估时要盯一下显存。

先按人分。下面的分工是本文的建议，不是 Epic 的规定；它的依据是每个旋钮存在哪种资产、改它需要什么技能、改错了影响多大。

程序握着"系统怎么跑"：自定义 Trait 和任务、System 事件的线程与时序、变量绑定读哪些游戏数据、组件上的依赖、Injection 的调用、规模档位怎么触发。改这些需要写 C++ 或理解线程，改错了会崩溃或出现数据竞争。

技术动画师握着"图怎么搭"：Trait 怎么组合、插入点放在哪、Chooser 表的列、Pose Search 比较哪些骨骼、State Tree 的状态和条件、混合时长，以及决定把哪些参数开放给动画师。改错了画面会不对，但不会崩溃。

动画师和美术握着"内容和取值"：动画素材与同步标记、数据库里收哪些动画、遮罩里每根骨骼的权重、人群的距离和数量档位、过场里的混合，以及技术动画师开放出来的那些变量的值。

和 ABP 比，最大的变化在中间那一层。ABP 里，技术动画师和程序常常在同一个蓝图里工作：事件图归程序，动画图归技术动画师，但它们是同一个文件。UAF 把 System（程序的地盘）和 Anim Graph（技术动画师的地盘）拆成了两个资产，中间用变量连接。变量清单就成了两类人之间的接口约定，这一点在第 7.7 节展开。

"这个效果作用在哪"可以沿五个方向问。每个方向在 UAF 里都有对应的设置位置：

两个观察。第一，骨骼范围从骨架资产里搬了出来：ABP 的遮罩存在 Skeleton 里，改一次遮罩就是改一次骨架资产，多人协作时很容易冲突；UAF 的遮罩是独立资产。第二，时间范围是目前最大的空白：ABP 有成熟的降频和预算工具，但它们挂在骨骼网格组件的 Tick 上，公开资料没有说明它们对 UAF 组件是否有效（第 7.5 节）。

开场的"上半身遮罩"在 UAF 里落成一个具体资产：UUAFBlendMask。API 的说明是"定义分层时混合包含哪些部分的资产"。它有三个字段：一个 Skeleton（只读，标明它属于哪套骨架）、一个 Table（一张 Hierarchy Table），以及一份运行时用的扁平缓存，避免每次都遍历树。它对外提供三组权重：按骨骼的、按曲线的、按属性的。

也就是说，一份遮罩不只决定"哪些骨骼参与"，还决定"哪些曲线参与"。比如上半身换成举弓姿态时，面部曲线要不要一起换，在同一份遮罩里设。

试试"渐变"预设：spine 0.3、chest 0.7、手臂 1。上半身是逐渐"拧"过去的，而不是从腰部突然断开。这是分层混合里最常用的技巧：权重在脊柱上分几段过渡，接缝就看不出来。

美术怎么编辑。ABP 时代是在骨架树的 Options 里加 Blend Mask，然后在 Blend 列里拖滑块，可以右键"递归设置"给子骨骼；遮罩和 Blend Profile 共用一列，都存在 Skeleton 资产里。UAF 的遮罩存在 Hierarchy Table 里，按层级编辑，思路相同，但它是一个独立资产，可以按用途建多份（"举弓上半身""受击左臂"），不会互相覆盖，也不用改骨架。

谁在用遮罩。Blend Layer Trait 按遮罩把一层姿态混进输入；Apply Additive 有按骨骼权重的版本；混合平滑有按骨骼的版本（ISmoothBlendPerBone），对应 ABP 的 Blend Profile：同一次过渡里，腿可以比上身切得快。

设计建议。遮罩按"身体区域 × 用途"命名，比如 BM_UpperBody_Aim、BM_LeftArm_Hit；脊柱至少分三段过渡；手指、面部这类细骨骼用递归统一设置；每份遮罩只给一种用途，宁可多建几份，也不要一份遮罩被三个地方共用、谁都不敢改。

离相机越远，角色占的像素越少，花在他身上的动画计算就该越少。"按距离分层"有三种粒度，从细到粗：

骨骼数随网格 LOD 减少。UAF 在 System 和图之间传的是 LOD 姿态（第 5.5 节），写姿态的单元 WriteSkeletalMeshComponentPose 也以 LOD 姿态为输入。网格降到低 LOD、骨骼变少时，姿态里需要算的骨骼也随之变少。这一层由美术在网格的 LOD 设置里决定。

部分功能按 LOD 关闭。RigLogic 的 UAF Trait 有一个 LODThreshold："在哪一级 LOD 以内才求值"。面部 RigLogic 很贵，远处直接关掉。可以照这个思路给自己的 Trait 加同样的阈值，比如 Control Rig 的脚步 IK 只在 LOD 0–1 运行。

整个表示方式按距离切换。这是人群的做法。以 MetaHuman 人群为例，它的 Mass 可视化 Trait 上有：完整 Actor 的距离、切到实例化表示的距离、停止渲染的截断距离、每一级的数量上限；动画上还有时间错开、同时混合的数量和混合时长。实例化 LOD 还可以按屏幕尺寸设置。

把"近"的上限调到 10、"中"调到 60，再把近界拉远：近档很快满了，多出来的人被挤进中档，最近的那十个才是完整 Actor。数量上限比距离更能保住帧率，因为人群会聚集，单靠距离，一群人走近时成本会突然翻倍。

这张图里的三档是本文建议的 UAF 用法：近处完整 Actor（ABP 或 UAF 驱动骨骼网格），中间 Mass + UAF 写到实例化蒙皮网格，远处实例化网格直接播简单序列。MetaHuman 人群的官方配置和它对应，但官方文档描述的实例化角色用的是预烘焙的 GPU 动画，并没有说中间那一档用 UAF；5.8 版本说明里"按距离使用 UAF 或简单序列"那句话，是中间档存在的依据。

谁设。距离和数量由美术或关卡设计在 Mass 实体配置里设，因为它们和场景密度、镜头构图有关。不同平台用不同档位，由程序用可扩展性设置去缩放，比如在低配平台上整体乘一个系数。

"这个修正只作用于跑步，不作用于待机""受击动画只盖上半身"，这类范围由东西放在图的哪个位置决定。UAF 里有四种工具：

Trait 叠在哪个节点上。加法 Trait 只影响它所在节点及其子树。把侧倾 Trait 叠在"跑步"那个 Blend Space Player 上，它就只在跑步时生效；叠在根节点上，就对全身全状态生效。这是 UAF 最细的范围控制，也是它和 ABP"在线上串一个节点"最大的不同：范围跟着节点走，不跟着连线走。

Sub Graph。把一段逻辑封装成子图，范围就是这个子图的输出。适合"上半身层"这样自成一体的部分。

Injection Site 放在哪一层。这决定了插进来的动画能盖住什么。插入点放在最终输出前，注入的动画覆盖全身；放在上半身层的输入处，再经过上半身遮罩，注入的受击就只影响上半身，腿照常跑。一个 System 可以有多个插入点，加上一个默认插入点（调用方不指定时用它）。

作用域接口。API 里有 IScopedTraitInterface 和 IScopedTagInterface，含义是"在一棵子树范围内生效的接口或标签"。按名字推断，它们允许一个节点给它下面的整棵子树提供某种上下文，比如"这个子树处于瞄准状态"。公开资料没有用法说明。

设计建议。插入点按"能盖住多大范围"命名并成对设计（全身 / 上半身），由技术动画师维护一张"插入点清单"，程序调用 PlayAnim 时只认清单里的名字；修正类 Trait 尽量叠在它真正要影响的那个节点上，而不是一律叠在根上，否则以后想排除某个状态就得重构。

System 和 Anim Graph 拆开之后，两者之间只剩变量。变量清单就是程序、技术动画师和动画师之间的合同。UAF 提供的暴露手段有这几种：

System 变量与绑定。程序在 System 里定义变量，绑定到游戏数据。这一层只读游戏状态，不该放"手感"参数。

共享变量资产。多个 System 或图共用的一组变量，比如"NPC 通用参数"。按角色类型建一份，美术改值不用碰 System。

Trait 参数连变量。Trait 的共享数据里标成潜在属性的成员（第 4.3 节）可以连到变量，代码建图时用 AddVariableMapping，也可以用 AddVariableMappingToAll 把一个变量映射到所有同名属性。连了变量的参数就能按实例、在运行时变化。

组件上的读写。游戏代码和蓝图通过 SetVariable 改值，适合关卡或玩法临时调整（比如"这个卫兵受伤了，侧倾加大"）。

暴露得好不好，看下面这张清单有没有写全：

三条经验：按意图命名，不按实现命名（叫 LeanAmount，不叫 AdditiveAlpha_03）；每个开放给动画师的变量都写范围和单位，否则就会有人把角度当弧度填；绑定变量和手感变量分开放，前者在 System 里由程序管，后者在共享变量资产里由动画师管，两边改动互不冲突。

最后把这一章的东西落到贯穿案例上。下面两张表回答同一个问题：这个角色的每个旋钮，在哪设、谁设、作用多大范围。

对照两张表能看到试点的边界：NPC 用到了全部五个维度，正好能检验 UAF 的控制面是否顺手；主角只用到骨骼和图内两个维度，而且都在 ABP 托管的那一块里，出了问题不影响主角的其余部分。

控制面设计的目标：每个旋钮只有一个主人，每个主人只改自己的资产。

先把官方口径列清楚，这是所有决策的基础。

插件状态：UAF 插件版本 0.1，在 5.7 和 5.8 中都是实验性，默认不启用，两个版本之间状态没有变化。所有 "UAF xxx" 插件的索引页都带着"发布时请谨慎"的提示。

Epic 员工在 2026 年 5 月的论坛回复（"General questions on UAF"）里说了这几件事：

有两点要放在一起看。一方面，官方态度明显保守：没有文档、没有样例、没有日期。另一方面，5.8 里 UAF 已经被用在了 MetaHuman 人群和 Sequencer Anim Mixer 这些官方功能里，插件数量也在增加。合理的解读是：UAF 已经在 Epic 内部的特定场景里使用，但对外的 API 和工作流还不稳定，Epic 不愿意为外部项目背书。

这也解释了一个现象：很多文章说"UAF 是 Anim Blueprint 的继任者"，这个方向没有疑问，但"继任"的时间点在 5.x 的范围内看不到。Epic 在 State of Unreal 2026 上说，5.8 是 UE5 最后一个计划中的大版本（必要时保留 5.9 的可能），UE6 的目标是 2027 年底推出抢先体验版。本文推断，UAF 的稳定化更可能与 UE6 这个节点相关，而不是某个 5.x 版本；Epic 的那篇新闻稿本身没有提到 UAF。

UAF 的名字、资产和 API 在几个版本里变化很大。读老教程时，先对一下它是哪个版本写的。

两条读资料的经验：

类名前缀混用是正常的。5.8 里 UUAFComponent 住在 AnimNextComponent.h，UUAFSystem 住在 AnimNextModule.h，大量 Trait 共享数据仍叫 FAnimNext...，新加的则叫 FUAF...。改名是渐进的，搜源码时两个前缀都要搜。

先看是不是改过名的同一个东西。旧教程里"把 Module 拖进 Workspace""创建 Data Interface"，在 5.8 里对应 System 和共享变量。有些字段会留下 _DEPRECATED 后缀，比如 UUAFSystem 上的 DefaultState_DEPRECATED、PropertyBag_DEPRECATED，这是读懂迁移路径的好线索。

下面是本文对各模块的分档建议。分档标准只有一条：出了问题能不能在一天之内退回去。能退回去的先试，退不回去的等。

几条总体建议：

不要迁移主角。主角用到的蒙太奇、根运动、网络同步最多，恰好是 UAF 最不成熟的部分。

先在 ABP 里托管 UAF 图。第 6.12 节的方式，让团队在不改变宿主的情况下熟悉 Trait、Workspace 和 System 的工作流。

给 UAF 的部分单独建插件或模块。所有自定义 Trait、System 资产放在一个独立的插件里，引擎升级时 API 变了，影响面可控。

别在 UAF 上堆厚封装。API 在 UE6 之前大概率还会变，薄薄一层适配比一套"自研 UAF 框架"好维护得多。

回到集市。两百个 NPC 落在"可试"的三行里：Motion Matching、ABP 托管、人群中间层，而且它们不用蒙太奇、不需要联机，出问题可以按角色退回 ABP。主角"猎人"同时踩中"暂不"的两行：主角、重度蒙太奇，外加根运动和联机两项未知。所以试点从 NPC 开始，主角保持 ABP，只用托管 UAF 图的方式让动画程序熟悉 Trait。下一节把这个决定写成一个四周的计划。

准入表回答了"试什么"。这一节回答"怎么试、试多久、什么算成功"。计划以集市 NPC 为对象，每周都有可以测量的退出条件；任何一周不达标，就停下来记录原因，而不是硬推。

三条执行纪律：

主角不动。四周里主角只允许以托管方式使用 UAF 图，组件、System 一律不碰。

每个 NPC 保留 ABP 版本。同一个角色蓝图上两套组件，用开关切换，所有对比都是同一角色、同一动画、同一场景。

提前写好停止条件。第 2 周如果一帧延迟或崩溃问题解决不了，第 3 周的规模测试就没有意义，直接进入第 4 周写结论。负面结论同样有价值：它告诉你要等哪一个版本。

下面是按 5.7–5.8 的社区教程整理的最小步骤。版本之间菜单名可能有出入，按意思找即可。

1. 启用插件并重启编辑器。至少要 Unreal Animation Framework 和 UAF Anim Graph 两个；只启用前者不够。做 Motion Matching 再加 UAF Chooser、UAF Pose Search；需要 IK 加 UAF Control Rig；需要状态加 UAF State Tree；需要 Warping 加 UAF Warping。
2. 创建资产。内容浏览器 → Animation → Animation Framework，建 Workspace、System、Animation Graph。或用资产向导一次生成。
3. 组装 Workspace。把 System 和 Graph 加进 Workspace，在 System 的 Graph 字段里选中这张图。
4. 写 System。Initialize 里调用 Make Reference Pose；PrePhysics 里调用 Run Graph，再调用 Write Pose。
5. 写最小的图。输出接一个 Sequence Player，选一段待机动画。
6. 挂到角色上。角色蓝图里加 UAF 组件（旧版叫 AnimNext Component），选择 System；把骨骼网格组件上的动画完全关掉。
7. 运行验证。角色应该播放待机。播不了，先查第 6 步。
8. 接上数据。在 System 里加一个 Vector 变量 Velocity，绑定到当前 Actor 的 Get Velocity；图里取长度得到速度，把 Sequence Player 换成接速度的 1D Blend Space Player（0 = 待机，1 = 走）。

第 8 步有一个已知的小坑：UAF 里没有 ABP 那个现成的 Calculate Direction 节点。要做八方向移动，得自己用速度和角色朝向算方向角，社区教程就是这么做的。复刻第三人称模板时，教程绑定了 ActorRotation、Velocity、CurrentAcceleration、OrientCharacterToMovement、IsFalling 五个变量，再在图里算 GroundSpeed、ShouldMove、Direction。

迁移不是逐节点翻译。下面这张表告诉你 ABP 里的每样东西在 UAF 里"去哪了"，以及有没有现成的对应。

迁移的顺序建议反过来做：先盘点项目里没有对应和不支持的那几行用了多少（尤其是蒙太奇），再决定迁不迁。如果一个角色用了大量蒙太奇分段和分支点，现阶段的答案基本是"不迁"。

对做联机游戏的团队，这是除蒙太奇之外最大的未知数。先说结论：截至本文，没有找到任何关于 UAF 与网络复制的官方或社区资料。Epic 员工在论坛回答问题时也没有涉及网络。下面能做的，是把问题拆清楚，告诉你要测什么。

ABP 时代的网络是怎么做的（背景知识）。动画本身一般不复制，每个客户端根据复制下来的游戏状态（速度、是否蹲下、武器）各自算动画。例外有两个：蒙太奇的播放状态通过角色的复制数据同步给其他客户端；根运动蒙太奇的位移被并入角色移动组件的网络预测和校正。

放到 UAF 上会怎样。第一条"各自根据复制状态算动画"和 UAF 的快照模型完全契合：只要快照里的值来自复制状态，各客户端算出的动画自然一致。麻烦在第二条：UAF 没有蒙太奇，于是"蒙太奇播放状态的复制"这条现成通路不存在；Injection 也没有公开的复制支持。一次性动作（攻击、受击）需要你自己把"开始了什么动作"做成复制状态或 RPC，再在每个客户端上各自注入。根运动则取决于 Mover 与 UAF 怎么交换位移，而 Mover 5.8 有自己的网络更新，二者的组合没有资料。

这一节也解释了为什么主角"猎人"被放在"暂不"：他同时依赖蒙太奇复制和根运动预测，而这两条在 UAF 上都没有现成通路。集市 NPC 不受影响，它们不需要联机，或者只需要"按复制状态各自算"这一条。

"UAF 更快"是最常听到的说法。按证据强弱排一下：

结论是：没有官方基准，也没有可复现的公开对照数据。结构上的收益（离开游戏线程、轻量实例、共享只读数据）是确定的，但具体快多少取决于你的图、角色数和平台。

自己测时建议这样做：同一个角色、同一组动画，分别用 ABP（开启线程安全更新）、ABP 托管 UAF 图、UAF 组件三种方式驱动；角色数取 1、50、200 三档；用 Unreal Insights 分别看游戏线程时间、动画相关工作线程时间和总帧时间。只看总帧时间会错过最重要的信息：UAF 的收益主要体现在游戏线程变轻，而不一定是总 CPU 时间变少。

下面是从社区教程、论坛和 API 结构里整理出的常见问题。第一列是你看到的现象。

这张表里的问题大致分三类：没接上（插件、网格动画、引用）、时序（快照、事件、通知）、还没做（缺节点、缺暴露、API 变化）。下一节的交互图按这三类倒推。

选一个症状，按顺序检查。每一步都给出"看什么"和"说明什么"。

排错时的一个原则：先确认快照，再怀疑图。UAF 把数据输入收窄成了快照，这让很多问题变得容易定位：快照对、结果错，问题在图；快照错，问题在绑定或时序。

下面是 UAF 一帧的系统流图，角色和人群各一张。点任意模块看它读什么、写什么、在哪个线程；点"按一帧的顺序播放"看数据怎么流动。

粗看只记三列：输入在游戏线程上被拍成快照；System 和图在工作线程上把快照变成一段求值程序；求值 VM 执行程序，结果写到网格。切到"人群"，输入换成 Mass 实体，输出换成实例化蒙皮网格，中间部分不变。

UAF 插件本身有四个模块：UAF（运行时）、UAFEditor、UAFUncookedOnly（编辑器下的编译与资产处理）、UAFTestData。它依赖十个插件，被二十个插件依赖。

两个观察。第一，IK Rig 和 AnimGen 也依赖 UAF，说明 UAF 的基础设施已经开始被其他动画系统复用。第二，UAF Anim Node 是很多功能插件的依赖（Chooser、Pose Search、State Tree、Warping、Shared Assets），所以它不是一个边缘实验，而是 5.8 里功能层的底座之一。

按一帧的执行顺序列出关键的类和函数。点开每一层看它在哪个文件、做什么、讲原理的是哪一节。路径以 5.8 的 API 参考为准，前缀 AnimNext 与 UAF 混用是正常的。

读源码时建议的顺序：先读 IUpdate 和 IEvaluate 两个接口的头文件，再读一个最简单的 Trait（Sequence Player），然后读 FEvaluationVM，最后才读组件和调度。和执行顺序相反，但这样每读一层都知道它在为谁服务。

下面是一个加法 Trait 的代码骨架：它叠在任意节点上，在子节点求值完之后给上身加一个平滑的侧倾。它覆盖了第 4 章的全部要素：共享数据、实例数据、潜在属性、两个接口、注册宏，以及"先转给下一个、再做自己的事"的调用约定。

这是结构示意，不能直接编译。宏的参数和部分函数名在 5.6 到 5.8 之间有变化，命名空间也从 UE::AnimNext 逐步改成 UE::UAF。写之前请打开引擎里的 FBlendTwoWayTrait 或 Apply Additive 的实现对照。

写自定义 Trait 时最容易出错的三件事：

把状态写成成员变量。Trait 对象被所有实例共用，成员变量会被多线程互相覆盖。状态一律放 FInstanceData。

忘了转给下一个。加法 Trait 不调用 IUpdate::PreUpdate / IEvaluate::PostEvaluate 往下转，下面的基础 Trait 就不会被更新或求值，表现为节点"冻住"。

在求值里碰 UObject。求值任务在工作线程上执行，任务里只能用值类型的数据。需要资产（比如曲线资产）时，在共享数据里引用，并通过 IGarbageCollection 接口报告引用，防止被回收。

目标不是复刻 UAF，而是用最少的代码把它的四个核心想法各实现一遍：SoA 姿态与 LOD、栈式求值 VM、可叠加的 Trait 与接口、非递归的两次遍历。做完之后，再加上混合同步和多线程。

语言不限。下面的伪代码是 C++ 风格，但没有用任何 UE 的类型。一个能跑的版本大约一两千行，可以用任何能读 glTF 或 FBX 骨骼动画的库来加载素材，用最简单的线框画骨骼。

先不做：压缩动画、根运动、IK、物理、编辑器、网络。它们都很重要，但和这四个核心想法无关，会把注意力带偏。

每个里程碑都写了"做完应该看到什么"。看不到就别往下走，后面的每一步都建立在前面正确的基础上。

先把内存布局定下来。三个决定会影响后面所有代码：

骨骼按拓扑序排列：保证每根骨骼的父骨骼下标比它小。FK 就变成一次顺序循环，不需要递归或栈。

姿态用 SoA：旋转一个数组，平移一个数组，缩放一个数组。混合、归一化这类"对每根骨骼做同一件事"的循环，访问连续内存，编译器容易向量化。

LOD 是前缀：把重要的骨骼排在前面，LOD n 只算前 N 根。一个姿态只存它需要的那么多。对应 UAF 的 LOD 姿态（第 5.5 节）。

"LOD 是前缀"和"拓扑序"有时会冲突：一根重要的骨骼的父骨骼必须也在前缀里。离线排序时先按 LOD 分组，组内再按拓扑序，最后检查每根骨骼的父骨骼所在的 LOD 不高于它自己。

第一个里程碑只做一件事：给定一段动画和时间，产出一个姿态，画出来。

做完应该看到：骨骼线框播放待机动画，循环处没有跳变。切换 LOD 时远端的骨骼（手指）停在参考姿态，而不是飞走。

常见坑：一，忘了同一半球检查，在某些帧上骨骼会转一大圈。二，循环动画的最后一帧和第一帧相同（很多导出器会这样），直接取模会在循环点停顿一帧，要用 numKeys - 1 作为周期。三，没有轨道的骨骼没有初始化成参考姿态，表现为随机朝向。

第二个里程碑把"怎么算"抽成一台栈机。先手写一段程序，不要图，验证 VM 本身。

做完应该看到：手写程序 Sample(Walk) Sample(Run) Blend2(0.3) Normalize 的结果，和直接调两次 SampleClip 再手动混合的结果逐骨骼一致（误差在 1e-5 以内）。

为什么姿态内存要从池里拿：每帧会压入、弹出几十个姿态，用通用分配器会成为瓶颈，而且碎片化。池按 LOD 大小切好块，Alloc / Free 都是常数时间。UAF 在遍历里用 MemStack 也是同样的考虑。

常见坑：一，Blend2 里取栈顶两个的顺序弄反，alpha 的含义就反了；约定"先压的是 A"，写进注释。二，多路混合时每一步都归一化，结果和"加权求和再归一化"不同，而且更贵；只在程序末尾归一化一次。三，程序结束时栈上不是一个元素，说明某个任务的输入输出数量写错了；加断言。

第三个里程碑实现"节点 = Trait 栈"。关键是让 Trait 无状态，并且通过接口找到彼此。

实现三个 Trait 就够验证：SequencePlayer（基础，实现 IUpdate、IEvaluate、ITimeline）、Blend2（基础，有两个子节点）、Mirror（加法，只实现 IEvaluate，在 PostEvaluate 里先让下面追加任务，再追加一个镜像任务）。

做完应该看到：同一个 SequencePlayer 节点，叠上 Mirror 后动画左右翻转；去掉 Mirror 恢复。问 Mirror 所在节点的 TimeLeft，得到的是下面 SequencePlayer 的值。

常见坑：一，在 Trait 里加了成员变量存播放时间，单角色正常，两个角色用同一张图时一起抽搐；所有状态进实例数据。二，加法 Trait 忘了调 Next，下面的节点不更新。三，实例数据的对齐没处理，SIMD 读 quat 时崩溃；每个 Trait 的实例数据按 16 字节对齐。

第四个里程碑用显式栈替代递归，把 Update 和 Evaluate 串起来。

做完应该看到：图 Mirror+Blend2(α){Walk, Run} 产出的程序打印出来是 Sample(Walk) Sample(Run) Blend2(α) Mirror；α 设为 0 时程序里没有 Sample(Run)；α 从 0 拖到 1 时，Run 节点在离开 0 的那一帧收到 OnBecomeRelevant，它的播放时间从同步位置开始，而不是从 0 开始。

常见坑：一，子节点按顺序压栈，弹出时顺序反了，导致程序里 Run 在 Walk 前面；压栈时倒序压。二，Update 和 Evaluate 对"哪些子节点相关"判断不一致（比如 Evaluate 又读了一次 α，而 α 在两次遍历之间变了），程序里出现没被更新过的节点；Evaluate 只走 Update 记下的相关集合。三，"刚变得相关"没处理，新淡入的动画从第 0 帧开始，脚步对不上。

第五个里程碑让切换看起来对：同步组让脚步对齐，惯性化让切换不跳。

同步组：在 Update 遍历里，Blend2 的 PreUpdate 找出权重最大的子节点作为领头，先推进它，拿到它的归一化进度，再用 WithTimeScale 或直接设置进度的方式让其他成员跟随。需要先实现 ITimeline 的"设置进度"方法。

做完应该看到：走跑按 0.5 混合时脚步不乱；按布尔切换待机和跑步，惯性化下没有跳变，而且过渡期间程序里只有一个 Sample 任务。

常见坑：一，领头在混合过程中换人时进度跳变；换领头时把新领头的进度设成旧领头的进度。二，惯性化需要前两帧的姿态算速度，第一次切换时没有历史；没有历史就把速度当 0。三，衰减曲线用了线性函数，结束时有"顿"一下的感觉；要用起点和终点导数都可控的五次多项式，或者直接实现 Dead Blending。

最后一个里程碑把动画搬离主线程。前五步的设计（无状态 Trait、实例数据、按值的程序）已经为此铺好了路，这一步主要是划清边界。

做完应该看到：200 个角色时主线程上只剩拍快照和收尾两段；用 ThreadSanitizer 跑一遍没有数据竞争报告；关掉多线程（所有作业在主线程顺序跑）结果逐位相同。

常见坑：一，在作业里读了角色对象上的字段而不是快照，偶发抖动，而且只在多核机器上出现。二，通知在作业里直接调用了播放声音的函数；通知只收集，回到主线程再分发。三，快照不是双缓冲，主线程在作业还在读的时候写了下一帧的快照。四，作业之间其实有依赖（骑手和坐骑），被当成独立作业并行了；用显式依赖表达，对应 UAF 的 AddModuleEventPrerequisite。

把六个里程碑里的坑按症状合起来。这张表也适用于读 UAF 源码时理解"为什么它这么写"。

UAF 的很多看起来繁琐的设计，都是这张表里某一行的答案。

动画的 bug 常常"看起来差不多对"。下面四件事值得在写对应功能的同一天就做出来。

一，参考实现对照。保留一个最笨的递归版本：每个节点直接返回姿态，混合就地算。每次改 VM 或遍历，跑一遍逐骨骼对比，误差超过 1e-5 就报警。

二，程序打印。每帧可以把求值程序打出来，带上每个任务的参数。90% 的"动画不对"看程序就能定位。

三，单线程与多线程逐位对比。同一段输入录下来，单线程跑一遍、多线程跑一遍，输出姿态逐位相同。不同就是有数据竞争或顺序依赖。

四，压力场景。

先有尺子，再写系统。UAF 自己也是这么做的：引擎里的 UAFTestSuite 就是它的尺子。