OpenMontage Rig Plan Director 实战指南：从角色设计到可动画装配与姿势库

OpenMontage Rig Plan Director 实战指南：从角色设计到可动画装配与姿势库

【免费下载链接】OpenMontageWorld's first open-source, agentic video production system. 12 production pipelines, 100+ tools, 700+ agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage

导读

本文围绕 OpenMontage 角色动画流水线（character-animation pipeline）中的Rig Plan Director阶段展开，讲解如何把上一阶段的character_design（角色设计）转化为两件可被渲染器直接消费的产物：rig_plan（装配计划）与pose_library（姿势库）。读完本文，你将掌握拆解角色部件、定义枢轴（pivot）、图层顺序与约束、命名姿势与动作循环的完整方法论，理解"角色差异是数据"的运行时模式，并能结合仓库中的 JSON Schema 与契约工具，产出符合schemas/artifacts/rig_plan.schema.json与schemas/artifacts/pose_library.schema.json校验的结构化工件。

一、Rig Plan Director 在流水线中的定位

在 OpenMontage 中，rig_plan是 character-animation 流水线里承上启下的关键阶段。根据 pipeline_defs/character-animation.yaml 的定义，该阶段：

• 上游输入：character_design（由 character-design-director.md 产出）；
• 本阶段产出：rig_plan与pose_library两个工件；
• 下游消费：scene_plan（场景规划）、assets（资源制作）与edit（动作时间线）阶段都会引用rig_plan与pose_library；
• 可用工具：svg_rig_builder与pose_library_builder；
• 门禁策略：checkpoint_required: true、human_approval_default: false——即本阶段必须写入检查点，但默认无需人工审批，审核通过后即可自动进入下一阶段（与character_design等人工门禁阶段形成对比）。

Manifest 中为本阶段预设的审核焦点（review_focus）精确概括了它的质量目标：

- Parts, pivots, layers, constraints, views, and required poses are complete - Rig plan avoids per-character code paths; character differences are data - Known risky motions are surfaced before asset generation

对应的成功标准（success_criteria）是：rig_plan与pose_library均为 Schema 合法，且每个必需动作至少有一个姿势或动作策略。

二、阶段目标：一份可执行的数据契约

Rig Plan Director 的 Goal 只有一句话：从character_design产出rig_plan和pose_library。看似简单，实际上它完成的是从"视觉设计"到"可动画数据"的翻译：设计师给出角色的造型、情绪与动作清单，而装配计划必须回答渲染器真正关心的问题——这个角色由哪些可动部件构成？每个部件绕哪个点旋转？部件之间的遮挡顺序是什么？动作能被哪些姿势表达？

仓库用两套 JSON Schema 把答案固定为结构化契约，任何产出都必须在写入检查点前通过校验（tools/character/character_animation.py中通过schemas.artifacts.validate_artifact完成）。

2.1rig_plan.schema.json核心结构

schemas/artifacts/rig_plan.schema.json 定义rig_plan为version+characters[]，每个角色条目必须包含：

注意该 Schema 对每个角色条目与部件条目都开启了additionalProperties: false，这意味着任何未声明的字段都会被拒绝——这正是"风险动作显式声明，不许藏在自定义字段里"的契约化表达。

2.2pose_library.schema.json核心结构

schemas/artifacts/pose_library.schema.json 定义pose_library为version+characters[]，每个角色条目必须包含：

姿势条目允许additionalProperties: true，为具体渲染器保留了扩展空间，但character_id与poses是必须的。

三、六步装配流程详解

Rig Plan Director 的 Process 定义了六步标准动作，按顺序执行即完成从角色设计到装配数据的关键翻译。

步骤 1：把角色拆解为部件（rig parts）

将每个角色转换成一组可动画的部件，清单如下：

• body（躯干）
• head（头部）
• eyes/pupils（眼睛/瞳孔）
• brows（眉毛）
• mouth shapes（嘴型）
• limbs/wings（四肢/翅膀）
• tail/accessories（尾巴/配饰）
• props（道具）

这与下游 Asset Director 的资产组织一一呼应：asset-director.md 要求"只产出rig_plan所需的部件，且每个可动部件保持独立、保留透明背景"，资产统一存放于projects/<project-name>/assets/characters/<character-id>/parts/。换句话说，装配计划中的部件清单就是资源制作的采购清单——装配阶段少定义一个部件，资源阶段就不会产出它。

步骤 2：为每个可动部件定义枢轴（pivot）

枢轴是部件旋转/缩放的中心点。在rig_plan.schema.json的joints中，每个关节都必须给出pivot（形如[x, y]的坐标对），可选地声明rotation与scale的允许范围。例如一个点头的头部关节，pivot 应落在颈部而非头部几何中心；手臂关节的 pivot 应在肩、肘处逐级定义，并通过parent建立"上臂 → 前臂 → 手"的层级链。仓库的质量检查第一条就是"Every moving part has a pivot"（每个可动部件都必须有枢轴）——这条规则直接由 Schema 的required: ["pivot"]强制。

步骤 3：定义图层顺序（layer order）

部件之间的前后遮挡关系由parts[].layer（整数）与layers[]（命名列表）共同表达。典型例子：头发层应高于头骨层、手臂摆到身体前方时高于躯干层、尾巴通常垫在最底层。排序是否合理会直接决定动画过程中是否出现"穿模"，这也是后续 Browser QA 与视觉自检重点观察的内容之一（见 compose-director.md 的帧采样检查）。

步骤 4：定义约束，阻止部件旋转到不可能的位置

约束的目标是让肢体不会旋转进不可能的姿态。例如肘关节只能朝一个方向弯曲、头部旋转角应受颈椎活动范围限制。在 Schema 层面，这通过joints中每个关节的rotation（最小/最大角度对）与scale范围来表达。这一步的意义在于：把"物理合理性"从渲染器的一次性代码里抽出来，变成装配数据的一部分，让同一套插值逻辑对任何角色都安全。

步骤 5：为已批准场景定义命名姿势

命名姿势（named poses）是姿势库的核心单元：每个姿势在pose_library的poses字典中占一个键，值包含parts（哪些部件变了、变成什么样）、expression、hold_frames等。质量检查要求"Every pose names the changed parts"（每个姿势必须点名它改变的部件）——未列出的部件视为保持前一状态，这是实现姿势之间增量插值的前提。姿势命名应直接对应场景的情绪节拍，例如happy_jump、sad_shoulders、surprised_recoil，方便下游 action timeline 直接引用。

步骤 6：仅在复用时定义动作循环

动作循环（action cycles）只在满足以下条件之一时才定义：

• 该动作在片中至少复用两次；
• 该动作是故事核心（如主人公的标志性走路姿势）。

这一约束与角色设计阶段的约束一脉相承："不要发明超过已批准时长能使用的姿势数"（见 character-design-director.md）。它把装配成本锁定在故事实际需求上，避免为一次性镜头过度设计循环动画。

四、运行时模式：角色差异是数据，渲染器不做一次性代码

Rig Plan Director 文档中有一段关键的 Runtime Pattern：

Character differences are data. The renderer should not need one-off code for a mouse versus a bird. A bird may havewing_left; a mouse may havetail, but both feed the same pose interpolation and timeline compiler.

即：角色之间的差异应当全部由数据表达，渲染器不需要为"老鼠"和"鸟"分别写一次性代码。鸟有wing_left（左翼）关节，老鼠有tail（尾巴）关节，但两者都走同一条"姿势插值 + 时间线编译"路径。这正是rig_plan中parts、joints、layers等字段存在的意义：渲染器只需要读取统一的关节表，就能驱动任何由该 Schema 描述的角色。

该模式的好处体现在流水线两端：

• 资源侧：新增角色只需新增数据（新的一套 parts/joints/poses），无需改动渲染代码，character_animation.py中契约工具对多角色、多风格的处理都是同一套确定性逻辑；
• 运行时侧：compose-director.md 明确运行时按edit_decisions.render_runtime路由到 Remotion 或 HyperFrames，两者消费的都是同一份 rig/pose 数据——这也是 manifest 审核焦点中"rig plan avoids per-character code paths"的具体落点。

另外需要说明的是仓库中存在一个特化的例外路径：手绘墨线风格（Ink Sketch）角色（如会自己画画、行走、跳舞的火柴人）应走Ink Puppet系统（见 skills/creative/ink-theater.md 与 ink-theater/README.md）。这类角色比例无关、不做逐部件手调运动，而是通过InkPuppet.choreograph([{clip:'wave'},{clip:'twist'},…])直接回放真实的 CMU 动捕片段（12 个动作，来自 ink-theater/mocap/catalog.json），Agent 只选择命名动作、绝不手调运动。对于需要走路的普通角色，Rig Plan 的关节 + 姿势插值才是主路径。

五、质量检查清单（Quality Checks）

装配计划提交前，必须逐项通过以下四道质量检查：

1. 每个可动部件都有枢轴——由rig_plan.schema.json的joints.*.pivot必填字段强制，任何遗漏都会在校验阶段报错；
2. 每个必需动作都有姿势或程序化策略——对应pose_library的required_actions与poses/action_cycles的覆盖关系，即 manifest 成功标准"Every required action has at least one pose or action strategy"；
3. 每个姿势都点名了它改变的部件——增量插值的前提，保证姿势之间可平滑过渡；
4. 风险动作必须被点名，而不是被隐藏——rig_plan中risks[]数组的存在意义。例如"角色需要从高处跳落并翻滚"这类高风险动作，必须在装配阶段提前暴露给下游场景与资源阶段，而不是等到 compose 渲染时才暴露。

六、工具使用：svg_rig_builder与pose_library_builder

文档指定的工具用法很明确：

Usesvg_rig_builderto draft rig data andpose_library_builderto draft the initial pose library. The agent may revise their output before checkpointing.

即：用svg_rig_builder起草装配数据，用pose_library_builder起草初始姿势库；Agent 可以在正式写入检查点之前反复修订输出。

这两类工具都落在 tools/character/character_animation.py 这一契约工具模块中，该模块的设计哲学是"创意编排留在 skills 与 manifests 里，Python 只负责产出结构化工件与轻量预览/评审输出"。从源码可见其关键特性：

• 所有工具继承BaseTool，声明为ExecutionMode.SYNC、Determinism.DETERMINISTIC（确定性执行）与明确的资源画像（ResourceProfile）；
• agent_skills字段会声明配套的 Layer 3 技能，例如character-rigging、pose-library-design，供 Agent 在调用前阅读；
• 工件写出统一走_write_json，并经由schemas.artifacts.validate_artifact做 Schema 校验，非法结构会被拒绝；
• 对多角色场景内置了调色板轮换逻辑（_character_color）与风格归一化（_normalize_style），说明装配数据天然支持一个角色数组内多个角色的批量化处理；
• 预览能力方面，模块可通过 Playwright 截帧 + FFmpeg 合成预览 MP4（_render_preview_mp4），为 compose 阶段的浏览器 QA 提供素材。

阶段内还可用character_spec_generator生成结构化角色草案（源自上游角色设计阶段），以及action_timeline_compiler（在 edit 阶段）把姿势串成带时序的动作时间线——装配数据正是这些工具的公共输入契约。

七、阶段门禁与检查点交接

根据 skills/meta/checkpoint-protocol.md 与 manifest 配置，rig_plan阶段checkpoint_required: true、human_approval_default: false。也就是说：

1. 完成装配计划与姿势库草案后，先由 reviewer 依据审核焦点做自查（部件/枢轴/图层/约束/视图/姿势是否完整、是否避免了逐角色代码路径、风险动作是否提前暴露）；
2. 通过后写入检查点：write_checkpoint(..., stage="rig_plan", status="completed", artifacts={"rig_plan": {...}, "pose_library": {...}})；
3. 由于该阶段默认不需要人工审批，检查点写入后自动进入下一阶段（scene_plan）——但 manifest 的值是绑定性的，如果某个项目把该阶段改为需要审批，则必须遵守awaiting_human流程并 END YOUR TURN。

与上游形成鲜明对比的是character_design阶段（human_approval_default: true），它是装配数据的事实来源；装配阶段因此可以假定角色设计已经过人工确认。这也再次说明：装配计划的质量上限，由角色设计阶段把角色拆分得是否清晰决定（角色设计就绪的标准是"动画师或工具能据此推断必须存在哪些部件、表情与动作"）。

八、与下游场景规划的无缝衔接

rig_plan与pose_library产出后，会被scene_plan阶段直接消费：scene-director.md 要求每个场景用type: "character_scene"表达角色表演场景，并把逐场表演细节放入character_actions——这些动作正是从姿势库中挑选的命名姿势，配合 action timeline 完成"姿势 → 时序 → 动画"的最后一公里。若场景规划中发现某个动作在姿势库中没有对应姿势，就说明装配阶段漏掉了必需动作，需要回退补齐——这正是"每个必需动作都有姿势或策略"这条质量红线在流水线中的闭环体现。

结语

Rig Plan Director 的价值不在于炫技，而在于把角色动画的"手艺"沉淀为可校验的数据契约：六步流程给出稳定的装配方法，两套 JSON Schema 给出机器可读的产物格式，"角色差异是数据"给出可扩展的运行时哲学，四道质量检查给出可执行的验收标准。对于要在 OpenMontage 中制作本地可复用的卡通角色动画的开发者，遵循本指南即可产出结构合法、下游可无缝消费的装配计划与姿势库，并在 compose 阶段用同一套数据驱动任何角色的表演。

【免费下载链接】OpenMontageWorld's first open-source, agentic video production system. 12 production pipelines, 100+ tools, 700+ agent skill and production-knowledge files. Turn your AI coding assistant into a full video production studio.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMontage