OpenMontage Rig Plan Director 实战指南从角色设计到可动画装配与姿势库【免费下载链接】OpenMontageWorlds 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为versioncharacters[]每个角色条目必须包含字段类型说明character_idstring角色标识与character_design中的 id 对应parts[]array部件清单每项必须有id、kind部件种类、layer整数图层序号可选asset_path资源路径与parent父级部件用于层级关系jointsobject关节/枢轴定义每个关节键必须给出pivot2 个数字的数组即旋转中心坐标可选rotation、scale范围layers[]array图层顺序的命名列表views[]array所需视图如 front、3/4、side、back与角色设计阶段保持一致required_poses[]array必需姿势的命名列表required_actions[]array必需动作的命名列表risks[]array已知风险动作的标注如肢体反关节、透视穿帮rig_typestring枚举svg_rig、canvas_procedural、lottie、hybrid默认svg_rig注意该 Schema 对每个角色条目与部件条目都开启了additionalProperties: false这意味着任何未声明的字段都会被拒绝——这正是风险动作显式声明不许藏在自定义字段里的契约化表达。2.2pose_library.schema.json核心结构schemas/artifacts/pose_library.schema.json 定义pose_library为versioncharacters[]每个角色条目必须包含字段类型说明character_idstring角色标识posesobject命名姿势字典每个姿势可含description描述、parts部件状态快照、expression表情、hold_frames保持帧数非负整数、transition过渡提示mouth_shapesobject口型形状集供对白/口型动画复用action_cyclesobject动作循环定义仅在满足复用条件时才需要姿势条目允许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 PatternCharacter 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.jsonAgent 只选择命名动作、绝不手调运动。对于需要走路的普通角色Rig Plan 的关节 姿势插值才是主路径。五、质量检查清单Quality Checks装配计划提交前必须逐项通过以下四道质量检查每个可动部件都有枢轴——由rig_plan.schema.json的joints.*.pivot必填字段强制任何遗漏都会在校验阶段报错每个必需动作都有姿势或程序化策略——对应pose_library的required_actions与poses/action_cycles的覆盖关系即 manifest 成功标准Every required action has at least one pose or action strategy每个姿势都点名了它改变的部件——增量插值的前提保证姿势之间可平滑过渡风险动作必须被点名而不是被隐藏——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确定性执行与明确的资源画像ResourceProfileagent_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。也就是说完成装配计划与姿势库草案后先由 reviewer 依据审核焦点做自查部件/枢轴/图层/约束/视图/姿势是否完整、是否避免了逐角色代码路径、风险动作是否提前暴露通过后写入检查点write_checkpoint(..., stagerig_plan, statuscompleted, artifacts{rig_plan: {...}, pose_library: {...}})由于该阶段默认不需要人工审批检查点写入后自动进入下一阶段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 阶段用同一套数据驱动任何角色的表演。【免费下载链接】OpenMontageWorlds 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
