OpenMontage 手绘动画实战：用 AnimatedDrawings 让用户画作与照片随真实动作起舞

OpenMontage 手绘动画实战：用 AnimatedDrawings 让用户画作与照片随真实动作起舞

【免费下载链接】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 中/animated-drawing这条创意技能路径：它调用 Meta 开源的 AnimatedDrawings 工具，把用户提供的人形画作或照片自动绑定 16 关节骨架，再通过 As-Rigid-As-Possible（ARAP）网格变形将 BVH 动捕片段重定向到这张图上，输出透明 GIF 或 MP4。读完你将领会：如何在 OpenMontage 的 agent 工作流中正确选择角色来源、在「开箱即用」与「Docker 自动绑定」两种模式间取舍、为不同 BVH 骨架配对正确的 retarget 配置，并把动起来的角色经 HyperFrames 合成进一支完整视频，同时避开 GIF 冻结、字体回退、管线豁免等已知坑位。

适用场景与能力边界：先分清/animated-drawing与/ink-art

/animated-drawing是一条栅格（raster）路径，它的适用场景非常明确：

用户已经有一张人形角色的画作或照片，并且希望这张图本身动起来（跳舞 / 走路 / 跳跃 / 挥手），输出是把原画扭曲变形到动作上的透明 GIF 或 MP4。

其核心流程是：自动绑定（预测 16 关节骨架）→ 将 BVH 动捕片段重定向到骨架上 → 对扁平纹理做 ARAP 网格变形。它只负责让一张已经画好的图动起来，没有「边画边自我展示」的 reveal 效果——那是/ink-art（矢量、从零创作）的职责。

OpenMontage 把这两个命令定位为**创意入口（creative entry points）**而非 Rule-Zero 管线，这在 AGENT_GUIDE.md 中有明确记载：/animated-drawing与/ink-art是跨界工具入口，运行时不存在对应的.yaml清单，不要为了找清单而卡住流程（详见skills/creative/ink-theater.md中的「Pipeline-exempt」说明）。两者的对比关系如下：

若用户的诉求是「画一幅会自己动起来的矢量涂鸦」，应转用/ink-art与 Ink Theater 引擎；仓库中的ink-theater/mocap/catalog.json自带 12 个 CMU 来源的动作（walk、run、dance_spin、wave 等），正是那条路径的动作库。

选择角色来源：先问，绝不静默复用捆绑角色

该工具会动画化你给它的任何图，但它需要一张人形画作（有头、双臂、双腿、四肢分离、纯浅色背景）。正式动手前，agent必须向用户呈现以下选项并让用户选择其一（当用户没有任何素材时默认走「生成新角色」）。这一步既是需求澄清，也是避免每条视频都像同一个吉祥物的关键：

1. 用户上传自己的画作—— 效果最好，因为是用户自己的角色。
2. 用户上传照片 / 任意图片—— 先用image_selector（img2img，FLUX/Recraft）做「涂鸦化」：提示词如"turn this into a simple child's crayon doodle of a humanoid, full body, plain white bg"，然后再绑定。「手绘感」来自这一步——直接扭曲原始照片的效果很差。
3. 生成一个新角色⭐（推荐默认）—— 用image_selector（FLUX/Imagen）生成："a child's crayon drawing of a character, full body, front-facing, A-pose with arms and legs separated, plain white background, no shadow, no text"。每条视频都独一无二。
4. 抓取一个图库角色—— 用pixabay_image/pexels_image，过滤到「纯背景上的手绘人形」。命中率看运气（图库多为照片），优先推荐方案 3。

捆绑示例角色仅用于演示，不得作为用户角色对外交付。注意：选项 1–4 全部依赖下面的auto-rig Docker 服务；若该服务未启动，必须如实告知用户。这条「绝不静默复用捆绑角色」的纪律，与 Ink Theater 路径中「读catalog.json挑动作、绝不循环同一 clip」的原则一脉相承（见skills/creative/ink-theater.md）——区别在于前者约束角色来源，后者约束动作多样性。

两种运行模式：开箱即用 vs Docker 自动绑定

模式 A · 捆绑角色 + 预设动作（无需 Docker，Windows 已验证）

git clone --depth 1 https://github.com/facebookresearch/AnimatedDrawings.git && cd AnimatedDrawings # 仓库锁定 Python 3.8 + 旧 wheel；用 uv 装 3.8： uv python install 3.8 && uv venv --python 3.8 .venv uv pip install --python .venv -e . uv pip install --python .venv "setuptools<81" # 仓库 import 了 pkg_resources 但未声明依赖 .venv/Scripts/python -c "from animated_drawings import render; render.start('./examples/config/mvc/export_gif_example.yaml')"

关键点：仓库隐式依赖pkg_resources（来自旧版 setuptools）却未在依赖中声明，因此必须显式固定setuptools<81。纯 CPU 即可运行，每个片段约10–12 秒，无需 GPU、Docker 或模型下载。

模式 B · 自动绑定新画作（重量级：Docker + 约 670 MB 模型 + 约 16 GB 内存）

python image_to_animation.py drawing.png out_dir # detect → segment → rig → retarget → render

该模式需要仓库docker/目录下的 TorchServe 容器，容器会下载drawn_humanoid_detector.mar（311 MB）与drawn_humanoid_pose_estimator.mar（357 MB）两个模型。Windows 上只应通过该容器运行绑定链路（OpenMMLab 在实践中仅支持 Linux）。

这条「检测→分割→绑定→重定向→渲染」的流水线，与 OpenMontage 另一条手绘动捕路径在思想上一脉相承：ink-theater/mocap/bvh2clip.mjs同样在离线阶段把 3D BVH 动捕文件转换为紧凑的 2D clip（hips 相对姿态 + rootY 垂向根运动，按固定身高 520px 缩放），并通过ALIAS别名表兼容 fair1 / CMU / Mixamo 三套骨架——它证明了「BVH 动捕→2D 角色」这一技术路线在仓库中是经过真实工程化的，/animated-drawing只是其栅格版形态（详见ink-theater/README.md）。

输入要求（自动绑定模式）

一张清晰绘制的人形，大致呈 T/A-pose（四肢分离、不重叠），背景为纯浅色（分割基于阈值 + floodfill），图中恰好一个人物。

Agent 生成的配置（全部为 YAML）

自动绑定会产出一组 YAML 配置文件，理解它们是把控输出的关键：

• char_cfg.yaml（附带texture.png、mask.png，由image_to_annotations.py自动生成）—— 角色定义：纹理、遮罩与骨架映射。
• 运动（motion）配置—— 指定 BVH 文件、帧范围（frames）与地面平面（groundplane）。
• 重定向（retarget）配置—— 把 BVH 关节映射到角色关节；骨架无差异时可复用捆绑的fair1_ppf/cmu1_pfp。
• MVC 配置—— 渲染控制器：controller.MODE: video_render、OUTPUT_VIDEO_PATH，可选WINDOW_DIMENSIONS、CLEAR_COLOR、BACKGROUND_IMAGE、CAMERA_POS。

其中WINDOW_DIMENSIONS直接决定输出分辨率（示例为 500×500），CLEAR_COLOR: [0,0,0,0]则是后续 HyperFrames 透明合成的关键开关（见下文）。

预设动作 → retarget 配置：骨架必须匹配

每个捆绑 BVH 属于不同的骨架族，用错 retarget 配置会直接崩溃（ValueError: 'RightArm' is not in list）。必须严格配对：

其他 BVH 需自行匹配其骨架（或编写新的 retarget 配置）。另外两个实战提示：

• 用end_frame_idx截断长片段：例如wave_hello有 839 帧，不截断会让渲染跑好几分钟。
• 接地类片段（ground-contact，如dab、wave_hello）渲染约慢 8 倍，规划时长时需预留余量。

这条「不同骨架必须配不同 retarget」的教训，在仓库的bvh2clip.mjs中以另一种形式复现：其ALIAS别名表（hips: ["Hips", "mixamorig:Hips", "Hip"]等）就是为了让同一套转换逻辑能识别不同来源的关节命名，遇到未识别骨架会打印WARN ... unmapped joints ... (skeleton not recognized — extend ALIAS)——提前暴露问题，而不是在渲染时才崩溃。

角色多样性：动画化用户自己的画作

捆绑角色只是演示素材。真实使用中，角色就是用户提供的任何东西——每条视频都应独一无二。对于「随便帮我做个视频」且没有画作的请求：

1. 用图像生成创建新角色（提示词参考上文方案 3，输出为纯浅色背景上的 PNG）；
2. 走 Docker 路径自动绑定（auto-rig）；
3. 得到每次都不一样的角色。

绝不在多条视频间复用捆绑角色，否则所有输出都像同一个吉祥物。这条约束同样呼应 OpenMontage 整体的 taste 治理：AGENT_GUIDE.md中的「Composition Authoring Mode」明确反对复用会让视频千篇一律的创作组件，手绘角色同理。

合成进 HyperFrames：成为一支真正视频的后半段

AnimatedDrawings 只输出「动起来的角色」。要得到真正的视频（背景、气球、音乐），必须在 HyperFrames 中合成：

• 透明输出：在 MVC 配置中设置view.CLEAR_COLOR: [0,0,0,0]，渲染透明帧。
• GIF 会在确定性 HyperFrames 渲染中冻结：务必先转成带 alpha 的 VP9 WebM：ffmpeg -i char.gif -c:v libvpx-vp9 -pix_fmt yuva420p char.webm。注意ffprobe会误报为yuv420p——alpha 通道实际完好。
• 视频契约（linter 强制，运行npm run check）：
  • <video>必须是场景（stage）的直接子元素并带自己的id，不能嵌套在带计时的<div>里（嵌套会冻结）；
  • 每个片段需要独立的data-track-index；
  • 淡出需要末尾硬杀：tl.set(el,{opacity:0})。
• 文字 /气泡使用 HTML 覆盖层 div，并加载完整的ink-theater/assets/patrickhand.ttf字体（详见 Ink Theater 的字体内嵌陷阱：切勿用 Google Fontscss2API 的子集 woff2，其缺少 basic-latin 会导致全英文静默回退为衬线体）。
• 管线豁免：/animated-drawing与/ink-art是创意入口而非 Rule-Zero 管线，没有.yaml清单，不要在合成阶段寻找不存在的 manifest。

这段契约与skills/core/hyperframes.md中描述的确定性渲染规则完全一致：每条时间线必须同步注册到window.__timelines、禁用repeat:-1、先lint后validate再render。透明 WebM 角色以<video>直挂 stage 下的写法，正是 HyperFrames 播放带 alpha 媒体所要求的形态。

输出与诚实的限制

• 输出格式：GIF（透明）/ MP4（H.264，avc1）；分辨率由WINDOW_DIMENSIONS决定（示例 500×500）。
• 明确的边界：
  • 仅栅格：扭曲的是画作像素，放大可见纹理拉伸；
  • 仅人形：无法动画化非人形物体；
  • 无自绘 reveal：不做「边画边动」；
  • 背景简陋：角色背后是简单纯色背景，复杂场景需靠 HyperFrames 补。
• 它的定位是「让你的涂鸦活过来」的趣味能力，auto-rig 路径背后依赖 Docker 服务。它不是通用矢量引擎——需要白色墨线、自绘展开的矢量涂鸦时，请使用/ink-art（Ink Theater，见skills/creative/ink-theater.md与ink-theater/README.md）。

会话评估中的示例渲染产物位于.tmp/animated-drawings/out/（如char3_dab.gif、char1_zombie.mp4），可作为自检参考与验收基线。仓库层面，ink-theater/THIRD_PARTY_NOTICES.md明确注明不捆绑任何 Meta / FAIR（AnimatedDrawings）动捕数据——/animated-drawing是独立能力文档，与 Ink Theater 的 CMU 动作库互不混淆，授权边界清晰（CMU 数据免费可用于研究与商业，见ink-theater/mocap/NOTE.md）。

小结：一条完整的执行清单

1. 问用户：上传画作 / 上传照片涂鸦化 / 生成新角色（默认）/ 图库角色；
2. 选模式：捆绑角色走模式 A（10–12 秒/片段，无需 Docker）；新角色走模式 B（Docker + 670 MB 模型 + 16 GB 内存）；
3. 配参数：生成char_cfg.yaml、motion、retarget、MVC 四类配置，retarget 必须与 BVH 骨架配对，长片段用end_frame_idx截断；
4. 转透明素材：view.CLEAR_COLOR: [0,0,0,0]+ GIF 转 VP9 WebM（yuva420p）；
5. HyperFrames 合成：<video>直挂 stage 带独立id与data-track-index，淡出加硬杀，文字气泡用完整 patrickhand.ttf，运行npm run check；
6. 交付：透明 GIF / MP4，记住它「仅栅格、仅人形、无 reveal」的能力边界，需要自绘矢量动画时切换/ink-art。

【免费下载链接】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