Orbit Motion Matching：动作、数据库与测试关卡怎样协作

发表于 分类于 阅读次数： 本文字数： 3.2k 阅读时长 ≈ 3 分钟

在 Orbit 的动作测试关卡里，操作角色向前、侧移、走跑或停下，Motion Matching 会从已有动作中寻找适合当前运动和姿态的片段，再衔接到角色身上。理解这套结构，需要把动作素材、搜索配置、动画执行和测试环境分开。

本文以 2026 年 10 月 10 日的 UE 5.8 工程代码及原生资产引用检查为依据。文中的“当前位置”已经存在；“整理方案”已经采用，尚未执行迁移。具体参数和最新路径仍以工程内容为准。

从屏幕上的角色开始

角色模型描述身体形状，骨架描述关节关系，动画序列保存随时间变化的骨骼姿势。动画蓝图把动画处理结果交给角色网格，网格根据骨骼姿势变形，随后由材质和引擎渲染成画面。

Motion Matching 的作用在动画选择阶段：按照角色的运动与姿态信息，在数据库中搜索合适的动画姿势。Schema 定义比较的信息，Database 提供可搜索的动作数据，动画蓝图执行搜索与衔接。UE Motion Matching 官方说明。

Orbit 当前测试的完整关系是：

1
2
3
4
5
6
7
按键 / 手柄输入
  → 测试角色与 CharacterMovement 更新运动
  → 姿态历史和轨迹预测提供搜索信息
  → Motion Matching 按 Schema 搜索 Database
  → 动画蓝图输出骨骼姿势
  → Manny 网格变形
  → 材质、灯光与 UE 渲染器生成画面

角色的实际位移由 CharacterMovement 管理。当前动画实例使用 IgnoreRootMotion；动作副本中的根轨迹用于搜索数据准备，动画输出与角色移动各有职责。

三个核心动画资产

资产 回答的问题 当前连接
PSS_Locomotion 怎样比较姿势和运动？ 指定模板骨架、轨迹及脚部特征
PSD_Locomotion 去哪些动作里搜索？ 使用上述 Schema，引用 17 段动作
ABP_MotionMatching 每次更新怎样得到角色姿势？ 使用 Database，并连接姿态历史收集节点

PSS 是 Pose Search Schema，即搜索规则。当前配置采样双脚的位置和速度，以及轨迹中的水平速度。选择哪些骨骼和运动信息，会影响搜索结果；具体权重由资产和编写代码维护。

PSD 是 Pose Search Database，即动作数据库。它为动作建立搜索索引；动作文件仍是独立的 Animation Sequence，数据库通过引用组织它们。

ABP 是 Animation Blueprint，即动画蓝图。当前 AnimGraph 的姿势连接为：

1
Motion Matching → Pose History Collector → 最终姿势

History Collector 保存后续查询需要的姿态信息，当前也启用了轨迹生成。Graph 中的连线表示姿势流；查询时还会使用历史和预测信息。

实际使用的模型与动作

测试角色借用 UE 模板的 Manny 网格与 Mannequin 骨架。它们位于：

1
Content/Reference/UnrealTemplates/Characters/Mannequins/Meshes/

数据库引用的 17 段动作是八个方向的行走、八个方向的慢跑和一段待机，位于：

1
Content/Reference/UnrealTemplates/MotionMatching/Animations/

这些 AN_MM_* 是从模板动作生成的测试副本。现有准备入口为副本添加搜索所需的根轨迹，保留模板原动作。模型、骨架和动作继续由测试资产引用，无需在测试目录再复制一套。

这套数据库当前服务于模板角色的动作实验。正式角色接入时，需要核对骨架、动作、运动方式和搜索规则，再决定哪些配置可以复用。

让实验能操作、能观察的文件

当前 Characters/MotionMatching 中有 14 个资产。其中三个是上述核心配置，其余十一项提供独立测试环境。

文件 责任
BP_MotionMatchingTestCharacter 配置测试身体、动画蓝图、摄像机和输入资产
BP_MotionMatchingTestHUD 显示操作说明、当前状态及实际选中的动画
BP_MotionMatchingTestMode 为测试关卡选择默认角色和 HUD
IA_TestMove、IA_TestLook、IA_TestRun 移动、视角和跑步操作
IA_TestReset、IA_TestFacing、IA_TestSlowMotion 重置位置、切换朝向方式和慢放观察
IMC_MotionMatchingTest 将键盘、鼠标和手柄按键映射到这些操作
M_M_TestFloor 测试地面的外观

L_MotionMatchingTest 是额外的一张关卡，用来摆放地面、灯光、出生点，并指定测试 GameMode。GameMode 在这里负责选择关卡使用的角色和 HUD。

对应源码分为两部分：

代码 运行时机与职责
Source/orbit/Private/Core/Debug/MotionMatchingTestCharacter.* 游戏运行时：处理测试输入、重置、慢放及读数
Source/orbitEditor/Private/Player/Characters/MotionMatchingAuthoringLibrary.* 编辑器编写时：准备动作数据、配置 Schema/Database/AnimGraph、构建索引

Scripts/Art/ImportArtRevision.py 的 motion-matching 入口负责调用现有编写能力并连接测试内容。生成完成后，UE 使用保存下来的资产运行。

当前位置与已采用的整理方案

当前动画配置和测试辅助资产位于 Content/Orbit/Characters/MotionMatching，关卡位于 Content/Orbit/Maps/Tests/L_MotionMatchingTest.umap。

已采用的方案将整套实验收拢到测试关卡旁：

1
2
3
4
5
6
7
8
9
10
11
12
Content/Orbit/Maps/Tests/MotionMatching/
├── L_MotionMatchingTest.umap
├── BP_MotionMatchingTestCharacter.uasset
├── BP_MotionMatchingTestHUD.uasset
├── BP_MotionMatchingTestMode.uasset
├── Animations/
│   ├── ABP_MotionMatching.uasset
│   ├── PSD_Locomotion.uasset
│   └── PSS_Locomotion.uasset
├── Input/
│   └── 六个 IA_Test* 与一个 IMC_MotionMatchingTest
└── M_M_TestFloor.uasset

这里的 Animations 包含动画执行与搜索配置。实际动作序列仍留在模板参考来源中。测试目录保存当前实验需要的内容；正式角色采用时，再按实际使用关系提取配置。

文件先归对象或功能，子目录按需要建立。成组的动画配置和输入适合分组；单个测试地面直接并列，借用的模型保持原引用。

怎样检查这套结构

先看 L_MotionMatchingTest 是否配置测试 Mode，再沿 Mode → Character → ABP → Database → Schema 检查引用。然后检查数据库动作是否存在、骨架是否匹配、索引是否构建成功，以及输入是否能驱动角色。

当前可用入口为 Scripts/Start-Development.ps1 -Map /Game/Orbit/Maps/Tests/L_MotionMatchingTest；迁移后该路径需要同步更新。

原生资产审核确认了这套引用链。运行行为由现有 Orbit.Player.MotionMatching 自动化覆盖，手感、脚步滑动和画面衔接需要在实际关卡中观察。本文写作没有重新执行完整动作测试。

动作经过骨骼变形后，还需要材质与灯光形成外观，这部分见角色着色与渲染结构。