AIGC标识 角色拆部件与素材生产路线调研

角色拆部件与素材生产路线调研

本文档整理「单图角色拆部件」当前的开源实现方案，并据此说明本项目（Meowcute / pixelforge）
现阶段选择的生产路线与边界。

重要声明：https://github.com/fs7744/meowcute 仅是一次个人实验，用于验证「本地模型能不能低成本做出
能用的游戏素材」，不具备任何商业变现价值，也不会用于任何商业用途。它存在的意义，是让后来者
能以更低的试错成本，踩在开源前辈的肩膀上做自己的尝试。

0. 写在前面：致谢

整条「把一张静态二次元立绘变成可动、可进游戏的角色资产」的技术链路，没有任何一步是凭空来的。

今天我们能在一台普通电脑上，用本地模型把一张图拆成几十个语义图层、甚至自动猜出骨架、再导出成游戏引擎
能吃的格式，是因为前面有一长串开源前辈把最难、最枯燥、最烧算力的部分先啃下来了：

  • Lvmin Zhang（张吕敏） 的 LayerDiffuse，把「透明图层扩散」这件事变成了现实，See-through 的图层
    生成就是站在它肩上；
  • Marigold / SAM / Grounding DINO / LaMa / AnimeInstanceSegmentation 这些基础模型与工具，分别解决了
    深度估计、分割、检测、修复里的一个个硬骨头；
  • shitagaki-lab（See-through） 把这些零件拼成了「单图 → 分层 PSD」的完整流水线；
  • MangoLion（Stretchy Studio） 进一步尝试把分层结果自动绑骨、变形、导出 Spine，把「AI 拆图」往
    「真能动起来」又推了一步。

没有这些人的免费公开，后来者根本不可能用这么低的成本去折腾「游戏素材自动化」这种好玩但非刚需的事情。
本文档及 Meowcute 项目，都是站在上述工作的肩膀上，做的一次轻量实验。再次向所有开源作者致谢。

1. 现状：See-through 的单图部件分解方案

仓库：https://github.com/shitagaki-lab/see-through
论文：See-through: Single-image Layer Decomposition for Anime Characters（ACM SIGGRAPH 2026 Conference Papers）

1.1 它解决什么问题

把一张静态二次元插画，自动拆成多个语义独立、且已被完整修复（inpaint）的图层，
并推断出图层之间的绘制顺序（drawing order）。产出的不是一堆粗糙的抠图块，而是
「可以直接拿去当 2.5D 模型用」的分层资产——最多可拆到 23 个语义层（头发、脸、眼睛、衣物、
配饰等）。

1.2 核心实现思路（三段式）

整个方案是多个扩散 / 分割模型的组合拳，而不是单个端到端网络：

模块 模型 作用 来源
透明图层生成 LayerDiff 3D（基于 SDXL 的 LayerDiffuse 改造） 生成带透明度的独立图层 layerdifforg/seethroughv0.0.2_layerdiff3d
伪深度估计 Marigold Depth（针对 anime 微调） 给每个图层估计深度，用于判定前后遮挡 24yearsold/seethroughv0.0.1_marigold
语义身体解析 SAM Body Parsing（detectron2 / SAM2 / mmdet 三档） 把角色按身体部位做语义分割打标 24yearsold/l2p_sam_iter2

要点：

  • LayerDiff 3D 负责「把一张图里的某个部件，补全成一张独立、透明、背景干净的图层」——
    这是整条链路里最吃算力的部分，也是 LayerDiffuse 思路的直接延伸。
  • Marigold 微调版 提供伪深度，用来给 23 个图层排序（谁盖谁），形成可操纵的 2.5D 层次。
  • SAM 身体解析 提供 19~23 个部位的语义标签，作为分层的语义依据。
  • 论文提到头身是两个连续阶段分别拆的，所以整体耗时比论文原模型更长（这是已知代价）。

1.3 主流程与产物

屏幕截图 2026-10-25 232036

核心脚本是 inference/scripts/inference_psd.py：

# 单张图 → 分层 PSD
python inference/scripts/inference_psd.py --srcp assets/test_image.png --save_to_psd

# 整个文件夹批量处理
python inference/scripts/inference_psd.py --srcp path/to/image_folder/ --save_to_psd

产物默认落在 workspace/layerdiff_output/，包含：

  • 一张分层 .psd（每个语义部件是独立、已修复的图层）；
  • 中间的深度图与分割掩码。

当前最新模型为 V3，即 23 个身体部位标签训练版。

1.4 拆完之后的二次分层

PSD 出来后，还可用 inference/scripts/heuristic_partseg.py 做启发式再拆分：

# 按深度进一步切分
python inference/scripts/heuristic_partseg.py seg_wdepth \
  --srcp workspace/.../PV_0047_A0020.psd --target_tags handwear

# 左右拆分（处理左右手/左右发等对称件）
python inference/scripts/heuristic_partseg.py seg_wlr \
  --srcp workspace/.../PV_0047_A0020_wdepth.psd --target_tags handwear-1

这一步对「想做 Live2D 式分层」的人很关键——自动语义分层通常只保证语义正确，
而 Live2D 更讲究按变形行为切层，所以往往要再手工/启发式细分一次。

1.5 它的边界（作者自述）

See-through 自己在 README 里明确写了「Is this Image-to-Live2D? We don't think so — not yet」：

  1. 更细的艺术化分解缺失——自动分层优先语义正确，而 Live2D 艺术家会按「怎么动才自然」来切层；
  2. 绑定（Rigging）未覆盖——分层之后还需要变形网格、物理参数、动作曲线，这一步被作者称为
    「最关键的、也最耗人工的一步」，本项目完全不做；
  3. 艺术意图无法自动还原——专业 Live2D 是分层、修复、绑定整体设计的产物。

作者的定位是：把最枯燥的「人工抠图 + 遮挡修复」替掉，给 Live2D 创作者一个可用的起点。

对动漫人物的拆部件效果：从公开 demo 与论文看，确实相当不错——语义分层干净、遮挡修复完整，
是现阶段单图拆部件里最可用的一档。

2. 进阶实验：Stretchy Studio 的自动骨骼绑定

仓库：https://github.com/MangoLion/stretchyStudio
协议：MIT

2.1 定位

Stretchy Studio 是一个 FOSS 2D 动画工具，目标是「把静态插画变成可网格变形的角色」，
并把自己定位为 See-through 的动画引擎——专门补上 See-through 没做的「绑定 + 动画」环节。

2.2 做法：DWPose 自动骨架 + 网格变形

  • Magic Auto-Rigging：用 DWPose（AI 姿态检测） 自动给角色生成骨架；也提供「启发式」方法秒出骨架；
  • Organic "Stretchy" Motion：不靠旋转图层，而是直接变形网格顶点做有机运动
    （呼吸、飘发、Live2D 式微表情）；
  • 附带眼睛自动裁剪、四肢顶点蒙皮弯曲、Blender 式形变键（shape keys）、音轨同步等。

2.3 导出能力

  • 支持 Spine 4.0 导出（Spine JSON），可直接进游戏引擎与专业管线；
  • 原生读取 See-through 的分层 PSD，自动处理遮挡、深度分层与网格生成。

2.4 现实评估：效果还不够好

从项目提交历史看，作者自己也在反复试错（例如「removed puppet pins, it sucked」、
不断尝试对接 Live2D warp 参数）。对普通用户、非美术背景而言：

  • 自动绑骨（DWPose）对非常规姿势、复杂遮挡、非标准比例的角色，骨架常对不准；
  • 网格变形需要手动调密度与权重，仍然有学习曲线；
  • 整体「开箱即动」的成品率，离「稳定可用」还有距离。

结论：它是非常有想象力、也很有价值的实验，但就当前版本，作为「非专业人士零成本产出稳定动画」
的方案，效果还谈不上好。

3. 现实约束：为什么先暂停骨骼路线

综合 1、2 两节的现状，本项目当前主动暂停「骨骼 / 网格动画」路线，原因明确：

  1. 骨骼动画本人尚未学习——不会手动调权重、改蒙皮、做动作曲线；
  2. 手动调整与制作动画的成本很高——即使自动绑骨，修正与精修仍要专业知识和大量时间；
  3. 自动绑定效果暂不达标——见 2.4，开箱即用的稳定率不足；
  4. 在「先验证端到端可行性」的阶段，骨骼路线属于高成本、高风险、长反馈周期，不符合「先跑通最小闭环」的优先级。

暂停 ≠ 否定。Stretchy Studio 这类方案是明确的技术演进方向，待「序列帧闭环」跑通、
且本人补齐骨骼动画知识后，可再回头接入。

4. 当前路线：本地模型 → 视频 → 游戏素材 → 序列帧 → 简单游戏 Demo

既然骨骼路线先放一放，现阶段的策略是先验证那条「看似最简单」的路能不能走通，
毕竟它的反馈周期最短、对专业知识要求最低。

4.1 路线全景

文字 / 参考图
      │
      ▼
[本地模型生成图]  ── Meowcute 文生图 / 图生图（Qwen-Image-2.1 底座，本地推理）
      │
      ▼
[本地模型生成视频]  ── 图生视频底座（HunyuanVideo-1.5 / Wan2.2-TI2V-5B，本地推理）
      │
      ▼
[视频转游戏素材]  ── 抽帧 / 抠图 / 去白边，得到透明底序列帧（见《本地视频转序列帧精灵图-科普》）
      │
      ▼
[简单序列帧精灵图]  ── 拼成 sprite sheet + 帧描述，进引擎
      │
      ▼
[简单游戏 Demo]  ── 用序列帧驱动一个可验证的小 demo（如角色 idle / walk 循环）

4.2 每一步与 Meowcute 的关系

  • 生成图 / 生成视频：正是 Meowcute 的核心能力——本地模型 + 确定性后处理，全程离线、不按量计费；
  • 视频转序列帧：对应 docs/本地视频转序列帧精灵图-科普.md、docs/Meowcute 视频生成序列帧方案分析.md
    里已梳理的抽帧、抠图、去白边、拼精灵图流程；
  • 游戏 Demo：仅作为「端到端可行性验证」，不追求美术质量，只验证「本地产出的素材真能进引擎动起来」。

4.3 为什么这条「看似最简单」的路值得先验证

  • 反馈最短：从文字到能动的小人，闭环在一台本地机器内完成，不依赖任何外部服务；
  • 知识门槛最低：不需要先学会骨骼动画、蒙皮、动作曲线；
  • 风险最可控：任一步失败都能独立定位，不会像骨骼路线那样「要么全成要么全废」；
  • 价值可累积：即使 Demo 很粗糙，生成的序列帧、精灵图、后处理脚本，都是后续接骨骼方案时的现成资产。

5. 风险与下一步

风险 说明 缓解
视频底座运动幅度不可控 图生视频的循环、抖动可能影响序列帧质量 先用 idle 类小动作验证，后处理做循环对齐
抠图白边 / 透明底不准 历史已踩坑，需用混合比例去白边 沿用已验证的 `
序列帧连贯性不足 抽帧间隔、运动模糊导致跳帧 控制帧率、做帧间对齐与裁剪
骨骼路线未来接入成本 当前资产未必适配 Spine 先产出标准精灵图，格式中立，后续可重排

下一步优先级：

  1. 先把「图 → 视频 → 序列帧」的单图闭环在 Meowcute 内跑通；
  2. 产出一个最小游戏 Demo（序列帧驱动）验证可行性；
  3. （条件成熟后）再评估接 Stretchy Studio / Spine 的骨骼方案。

6. 开源致谢清单（再次）

  • LayerDiffuse — Lvmin Zhang（张吕敏）：透明图层扩散的奠基，See-through 的核心底座。
  • Marigold — 基于扩散的单目深度估计，本项目用作 anime 伪深度。
  • Segment Anything (SAM) / SAM2 — 分割基础模型，身体部位语义分割的关键。
  • Grounding DINO — 开放集检测，辅助定位。
  • LaMa — 大掩码修复，遮挡区域补全。
  • AnimeInstanceSegmentation — 二次元专属实例分割。
  • shitagaki-lab / See-through — 把上述零件拼成「单图 → 23 层 PSD」的完整流水线。
  • MangoLion / Stretchy Studio (MIT) — 把分层结果往「自动绑骨 + 网格变形 + Spine 导出」推进的实验。

没有上述每一份公开的代码与权重，就没有后来者低成本尝试「游戏素材自动化」的可能。
Meowcute 仅是站在这些肩膀上的一次轻量实验，仅此而已。

posted @ 2026-10-26 21:49  victor.x.qu  阅读(14)  评论(0)    收藏  举报