Evilom
4.6 KiB
4.6 KiB
B9Ofw7pPVix7FFk2XzOcyGoRnlc
Source: https://ocnmca6f1o0p.feishu.cn/wiki/B9Ofw7pPVix7FFk2XzOcyGoRnlc
工作内容概述
1、使用ComfyUI工作流通过AI对pose图片进行关节拆分 2.、通过AI生成序列帧
一、AI 序列帧
AI 出连续图 → 脚本整理图集 → 引擎伪装成 Spine 播放，这套方案落地最快，但也最容易在批量化时被脏数据卡死。
去绿幕：后期兜底与生成端脏数据
- 实测痛点： 边缘抠不干净，根本原因不在于后期去色算法不够好，而是大模型前置生成图的背景本身就不纯。
- 调参困境： 目前用的 精确颜色剔除 → 色相范围兜底 流水线，处理纯绿背景没问题。但如果角色身上有绿色系部件（服装撞色），参数就很难调：色相收窄漏背景残影，放宽就吃掉角色本体。边缘的半透明反光区更是自动化处理的死角。
- 核心判断： 靠后期脚本强行去绿幕是在给生成端的脏数据还债。长期的解法必须往上游走：优化生成端 Prompt 与模型约束 → 直接输出带透明通道的图。
切黑边：放弃固定阈值，引入动态扫描
- 实测痛点： 切割总对不齐，因为 AI 生成的分割线（黑边）完全缺乏物理规律，1 到 5 个像素的宽度甚至颜色渐变都有。
- 折中方案： 继续死磕固定阈值是不现实的，最终改成了：扫描单帧真实线宽 → 独立计算裁剪阈值 → 强制追加冗余像素。
- 核心判断： 面对非标的 AI 数据，宁可多切一像素，绝不漏留一条黑边。没有标准工程基准时，保守冗余是唯一的量产解法。
颜色闪烁：性能与品质的权衡
- 实测痛点： 同一个角色连帧闪烁，排查后确认这不是代码提取颜色的 Bug，而是扩散模型逐帧独立生成的必然现象。
- 策略演进： 之前用“第一帧”做基准取调色板，一旦首帧颜色不全，后续帧就会出现诡异的颜色替换。现在强制改为：全帧拼接成大图 → 提取全局统一调色板 → 映射回写。品质稳了，代价是处理耗时变长。
- 核心判断： 管线必须分级。少帧数的短动作走“全局拼接法”保品质；长序列动作走“第一帧法”保速度，后期加人工挑拣。
帧间对齐：修补横向位移的局限性
- 实测痛点： 连帧播放时的“重心微移”，本质是大模型缺乏对连续空间结构的理解。
- 核心判断： 纯靠后期脚本算重心来对齐，能救回大部分纵向浮动，但对于横向位移（尤其是攻击等大幅动作）极难找到视觉基准点。解决路径必须前置：生成端强制引入固定画布 → 添加居中约束 → 后期再做轻量微调。
二、AI Spine 动画
在尝试推进 AI 自动绑骨时，我之前的设想在调研行业现状后被完全推翻，整个管线的重心也随之调整。
认知转折：从“全自动绑骨”到“模板换皮”
- 碰壁与调研： 在跑通前端的 VLM 视觉分析 → SAM3 像素级分割 → 输出部位坐标 切图管线后，我本想继续让 AI 去算骨骼层级和权重。但在调研了其他做Ai spine的后发现，所谓的“AI Spine”，大家其实都在绕开物理绑骨。
- 行业真相： 当前的技术现状，并不是 AI 能凭空生成骨架，而是：先做前端切图剥离 → 然后将碎图映射套用到人工做好的现有骨骼模板上。
- 核心判断： 本质上都在做“高级换皮”。现阶段必须放弃“AI 直出可用 Spine 骨架”的想法，务实的解法是把精力全投入到 AI 辅助拆件切图上，后端复用人工模板。
路线抉择：开源重绘 vs 自主坐标分割
既然重心是拆件，我对比了主流的两条路：
- 重绘路线： 提示词 → 图像模型重绘平铺图 → 视觉切片 → 拼入骨骼。这套方案最大的问题是生成成本高，且重绘必然改变原画风细节，部件形变后极难对齐现有骨骼。
- 当前路线： 原图输入 → VLM 分析结构 → JSON 输出坐标 → 精确抠图 → 拼入骨骼。完全保留原图像素，算力成本低，坐标本身就是物理结构，对接下游更顺畅。
- 核心判断： 像素资产不能破坏源画风，且要控制成本，必须死守“坐标分析 + 精准分割”这条自主路线。
