企业官网建设流程全解析

崩坏学园2 不止：两万六千字讲透unity-studio提取看板全流程

先说结论：这篇文章不是教你怎么“偷”素材，而是把提取、修复、还原一条链路完整走一遍。崩坏学园2的Live2D看板在同类手游里属于做得相当讲究的那一档，分层多、动捕数据复杂、材质参数杂，想完整搬下来并能在自己的项目里正常驱动，难度比想象中大不少。而我用的核心工具就是unity-studio，一个专门用来解析Unity打包资源的开源工具链。它能把AssetsBundle里的模型、贴图、动画、材质全拆出来，配合Live2D的运行时SDK，就能把游戏里那个会眨眼、会动的看板角色，原样搬到自己工程里跑起来。

这篇文章适合谁看？一是想在PC端或Web端做崩坏学园2角色展示的玩家，二是做Unity客户端开发、想研究Live2D换装/看板实现原理的人，三是纯粹对资源解密和逆向感兴趣的折腾党。你不需要是Unity高手，但最好对Unity编辑器基本操作有一点概念，剩下的我会一步步带。

先说清楚一个大前提：提取游戏资源这件事，在法律和用户协议层面是灰色地带。本文所有内容仅用于个人学习、技术研究和本地备份，请勿将提取结果用于任何商业分发、公开传播或二次盈利行为。我写的每个步骤都建立在“你自己已购买或已拥有该游戏内容”的基础上，而且我强烈建议你看完原理后，自己动手去做一个完全不同角色或原创形象的同构演示，那才算真正学到东西。

现在，正文开始。

1. 内容整体设计与思路拆解

1.1 一个看板背后到底藏着什么

崩坏学园2不止看板之所以看起来“活”，是因为它并不是一张静态大图，而是一整套由Live2D驱动的动态资源。一个典型的看板资源里，包含以下这些东西：

• 角色立绘拆分图：也就是一张大图被切成的几十个到上百个部件（头发、眼睛、嘴、衣服、手臂、道具等），每个部件独立成图。
• 网格与形变信息：Live2D的核心模型文件（.moc3），它不是传统骨骼动画，而是“网格+顶点形变”方案，把每个部件映射到控制点上，通过推拉控制点让模型“动起来”。
• 动作数据与表情数据：控制眨眼、呼吸、说话、头发摆动、身体起伏这些动画的播放文件（.model3.json会引用这些动作）。
• 纹理集与材质参数：把多张小图合并成大图集，减少DrawCall，同时记录光照、透明度、混合模式等参数。
• 音频资源：部分看板会带出生语音、点击语音、待机语音，这些也打包在资源里。

如果用传统的“解包游戏抓图片”思路，只能拿到一堆碎图，拼起来是一张静态立绘，但动不了。而用unity-studio的意义在于，它能把Unity打包后的资源结构完整还原，让你拿到的不是“尸体”，而是还能“活过来”的完整资源包。

1.2 为什么选择unity-studio而不是其他工具

unity-studio是一个开源项目，支持解析Unity全系列的AssetBundle和资源序列化格式。它跟AssetStudio这类GUI工具不同，它更加底层、更偏向库的形态，适合二次开发和自动化批处理。简单对比一下当前主流几个工具：

unity-studio最大的优势在于，它把Unity的序列化格式抽象得比较干净，能识别出绝大多数Unity版本生成的资源包，尤其是崩坏学园2这种持续更新、Unity版本可能在5.x~2019之间来回横跳的项目。它支持的ClassID覆盖范围广，材质、Shader、MonoBehaviour、Sprite、AnimationClip都能解析，这就给后续还原Live2D模型提供了关键基础。

1.3 一个完整的提取链路长什么样

在动手之前，我建议先在脑子里过一遍整个流程，不然容易在中间迷失。

获取游戏安装包/缓存包 → 定位目标看板对应的AssetBundle → unity-studio解析bundle → 导出moc3、贴图、animation、音频、纹理集 → 修复Live2D模型引用关系 → 在Unity工程里搭建播放环境 → 集成Cubism SDK与运行时 → 还原看板与点击交互

这里最关键的一步不是“拆”，而是“修”。因为游戏打包资源时，往往会做路径混淆、资源引用重定向、纹理压缩格式转换等处理，直接拆出来往往不能用，需要你根据Live2D的规范手动修引用、转格式、补配置。

我把这个思路拆成三步：提取（extract）、重建（rebuild）、驱动（drive）。三步走完，整个看板才算真正“复现”成功。

2. 核心细节解析与实操要点

2.1 先搞懂Live2D的Cubism 3/4资源结构

在崩坏学园2不止里，看板用的Live2D基本都是Cubism 4格式。Cubism 4的核心文件列表如下：

其中，.moc3是二进制格式，model3.json是入口描述文件。unity-studio在解析时，能把.moc3当成普通二进制资源导出，但需要你手动确认Unity是否把Live2D模型文件嵌入了TextAsset而不是MonoBehaviour——这影响导出后能否直接使用。

一个小知识点：Live2D的纹理图集通常会把角色拆分为256x256、512x512或1024x1024的方块网格，每个格子放置一个部件。unity-studio导出的Texture2D如果是未合并的独立小图，你需要自己用Python或PS拼回图集。如果是已合并的大图，就别动了，直接作为贴图使用比拆开更稳。

2.2 资源定位：如何快速找到看板对应的bundle

崩坏学园2不止的资源命名习惯，我实测下来并非完全无规律。虽然很多美工资源用了hash命名，但Live2D看板相关的bundle名称往往会包含live2d关键字，或者存放在独立的charactor_xxx目录里。

我的做法是：先把整个安装包内的AssetBundle全量解析，建立“文件名hash→bundle路径”的映射表，然后再根据bundle内引用的TextAsset和Texture2D数量做筛选。如果一个bundle同时包含超过10张Texture2D、1个以上的二进制TextAsset、还有若干AnimationClip，那它大概率就是Live2D看板资源。

这里有个实用技巧：在unity-studio解析时，可以开启--dump-info参数，把每个bundle的资产清单dump成JSON文件。然后用Python脚本批量检索，匹配*.moc3或者model3字符串，几秒钟就能锁定目标。比人肉一个一个点开看效率高太多了。

2.3 两个最容易翻车的点：纹理格式与依赖缺失

崩坏学园2不止在移动端打包时，纹理大概率使用了ETC2、ASTC或PVRTC这类压缩格式。这些格式是为GPU直接采样优化的，但不方便在Live2D运行时里直接加载。所以提取后，你需要做两件事：

1. 把非RGBA格式的Texture2D解码成RGBA32的PNG。
2. 记录纹理的原始尺寸和布局，确保和.moc3里UV坐标对得上。

第二个翻车点，是依赖缺失。Live2D模型通常还会引用一个叫Cubism SDK的运行时组件，它不在游戏资源里，而是游戏引擎代码的一部分。你导出.moc3之后，需要自己下载对应版本的Cubism SDK（Unity版），并把相关运行时插件挂到场景里，否则模型加载不出来。

2.4 快速判断这个bundle值不值得动

不是所有Live2D资源都适合提取。我在实际操作中总结出一个“三看”原则：

• 看moc3文件大小：小于50KB的可能是个空壳，不做动作；大于200KB的通常有复杂形变，值得提取。
• 看贴图数量：少于5张贴图的，大概率是静态立绘误包装成Live2D；超过20张贴图的，说明角色细节丰富，可玩性高。
• 看动作数量：动作文件多说明交互丰富，点击、待机、生日专属动作都有，提取出来价值高。

按照这个标准筛选，能帮你节省大量时间，避免在低价值资源上浪费精力。

3. 实操过程与核心环节实现

3.1 环境准备：我从零搭好的工具链

在我动手之前，需要准备以下软件和依赖：

unity-studio的安装非常推荐从Github Release页下载预编译版本。它会依赖.NET运行时，Windows上直接装.NET 6.0 Desktop Runtime就行。如果是在MacOS/Linux下使用，同样安装对应平台的.NET运行时即可。

3.2 提取流程：把AssetBundle拆开看

获取到崩坏学园2不止的安装包后，先用解压工具把APK或IPA拆开。Android端一般在assets/bin/Data/或assets/下有bundle文件；iOS端一般在Payload/xxx.app/Data/里。如果游戏使用了分包下载，可能还需要从游戏缓存目录找，路径一般是Android/data/{包名}/files/下的子目录。

拿到bundle文件列表后，我用unity-studio做批量解析。命令行大致如下：

# 列出bundle里所有资源 unity-studio list --bundle "resources/assets/live2d_002.ab" # 导出全部资源到指定目录 unity-studio extract --bundle "resources/assets/live2d_002.ab" --output "./export/live2d_002" # 只导出特定类型的资源 unity-studio extract --bundle "resources/assets/live2d_002.ab" --output "./export/live2d_002" --filter "Texture2D" --filter "TextAsset"

unity-studio的--filter参数是可以叠加的，我一般会同时导出Texture2D、TextAsset、Sprite、AnimationClip、MonoBehaviour这几类，后面重建时都用得上。导出后的目录结构大致长这样：

export/live2d_002/ ├── TextAsset/ │ ├── char_001.moc3 │ ├── char_001.model3.json │ ├── char_001.physics3.json │ └── char_001.exp3.json ├── Texture2D/ │ ├── char_001_tex_01.png │ ├── char_001_tex_02.png │ └── char_001_tex_03.png ├── AnimationClip/ │ ├── idle.anim │ ├── tap_head.anim │ └── tap_body.anim ├── MonoBehaviour/ │ └── CubismModel.asset └── Sprite/ └── ...

如果unity-studio没能解析出.moc3，而是一个名为CubismMoc的MonoBehaviour对象，也别慌。CubismMoc里通常会有一个byte数组字段，里面存的就是.moc3的原始二进制内容。你可以提取这个字段，另存为.moc3文件。

3.3 texture修复：解码与图集拼接

提取出来的Texture2D未必是PNG，可能是DDS、ETC2等压缩格式或平台专用格式。unity-studio在导出时通常已经尝试转成PNG，但偶尔会出现花屏、色彩通道错乱的情况。遇到这种情况，我建议用Python的Pillow库处理：

from PIL import Image # 如果导出的png是RGBA但颜色通道异常，尝试BC4/BC5解码后重存 img = Image.open("char_001_tex_01_raw.png") # 如果alpha通道缺失，默认补全 if img.mode != "RGBA": img = img.convert("RGBA") # 检查尺寸是否为2的幂，若不是，补齐边缘 w, h = img.size new_w = (w + 3) // 4 * 4 new_h = (h + 3) // 4 * 4 if (new_w, new_h) != (w, h): canvas = Image.new("RGBA", (new_w, new_h), (0, 0, 0, 0)) canvas.paste(img, (0, 0)) img = canvas img.save("char_001_tex_01.png")

另外一个坑：Live2D贴图如果被拆分导出成了很多张小图，而.moc3里的网格引用的却是合并后的图集坐标，你就必须按原图布局把它们拼回一张大图。具体的拼图坐标参考model3.json里的textures数组，里面记录了每张贴图对应的textureName，但其实图集内各小图的位置在.moc3里已经固化，你只能按Unity原始Texture2D的布局来拼。

我自己的经验是：如果Unity导出的原始Texture2D已经是完整的图集贴图，那就不要拆开，直接用最省事。除非碰到贴图分辨率超过2048导致Live2D加载报错，再考虑用工具切成多张。

3.4 JSON配置修复：手动补全引用关系

提取出来的.model3.json经常是坏的，原因是Unity打包时会把JSON里的路径改写掉。比如原本应该是char_001.moc3，但Unity打包后变成了cab-xxxx或hash路径，导出后JSON里的字符串还是游戏的内部引用，需要手动替换回可读文件名。

一个典型的model3.json开头长这样：

{ "Version": 3, "FileReferences": { "Moc": "char_001.moc3", "Textures": [ "char_001_tex_01.png", "char_001_tex_02.png" ], "Physics": "char_001.physics3.json", "Pose": "char_001.pose3.json", "Expressions": [ { "Name": "happy", "File": "exp_01.exp3.json" } ], "Motions": { "Idle": [ { "File": "motion_01.motion3.json" } ], "TapBody": [ { "File": "motion_02.motion3.json" } ] } }, "Groups": [ { "Target": "Parameter", "Name": "EyeBlink", "Ids": ["ParamEyeLOpen", "ParamEyeROpen"] } ] }

实际操作中，Motions对象里的File字段经常指向anim_xxx这样的Unity内部资源名，导出后根本不存在。我一般是把从Unity导出的AnimationClip转成.motion3.json格式，或者直接放弃原游戏动作，改用Cubism SDK自带的示例动作。如果你是第一次做，我建议先用官方示例动作跑通流程，再回来折腾原版动作。

3.5 在Unity里搭建还原环境

这一步的最终目标是：把提取出来的模型文件放进Unity工程，然后用Cubism SDK去加载。

先建一个空工程，导入Live2D Cubism SDK for Unity（下载后直接把整个包拖进Assets目录）。接着：

1. 在Assets下建一个Live2D/Models/chars_001目录，把提取出的.moc3、.model3.json、贴图、动作JSON全部放进去。
2. 确保model3.json里的文件引用路径和实际存放路径完全一致。
3. 在层级面板新建空物体，挂载CubismModel组件，把model3.json拖到Model3 Json Asset字段。
4. 如果模型没有自动生成画布，右键该物体，选择Live2D -> Generate Cubism Model（部分SDK版本步骤不同）。

挂载成功之后，模型就会从.moc3里读取网格和材质信息，自动关联贴图，并绑定物理、动作、表情系统。如果一切正常，场景里就能看到角色正立显示，并且可以点击拖拽控制点来测试形变。

3.6 代码级集成：看板逻辑复刻

光能显示静态模型还不够，真正像样的看板还需要待机动画、点击反馈、眨眼和呼吸。这些在Cubism SDK里都有现成接口：

using Live2D.Cubism.Core; using Live2D.Cubism.Framework; using UnityEngine; public class LookBoardController : MonoBehaviour { private CubismModel _model; private void Start() { _model = GetComponent<CubismModel>(); if (_model == null) { Debug.LogError("CubismModel component not found."); return; } // 播放Idle动作（如果有） var animator = GetComponent<Animator>(); if (animator != null) { animator.Play("Idle"); } } private void OnMouseDown() { // 鼠标点击触发Tap动作，优先用Animator里配置的Trigger var animator = GetComponent<Animator>(); if (animator != null) { animator.SetTrigger("Tap"); } } }

如果你希望模型在UI界面上显示，而不只是一个场景里的3D物体，可以用Unity的RawImage加一个RenderTexture，把相机画面渲染进去。这种方式能实现“点击角色任意位置有反馈”的看板效果，也是很多游戏主页面的实现思路。

代码层面有几个隐藏要点：

• 必须保证Cubism SDK版本和模型的Cubism版本匹配。Cubism 4模型用旧版SDK加载会报错。
• 物理模拟（CubismPhysicsController）默认只对Physics3.json生效。如果导出时没拿物理文件，头发和裙摆会僵直。
• 口型同步（LipSync）需要麦克风权限或音频驱动，在PC上运行要额外申请权限，移动端可能不支持WebGL方案。

4. 常见问题与排查技巧实录

4.1 model3.json拉不进来：路径引用的玄学

这个问题出现的频率极高。现象是：你在Unity里拖入model3.json，却报错找不到.moc3或贴图。最常见的原因是model3.json里使用了./相对路径，但文件实际存放层级和JSON里写的不一致。

解决办法很简单：打开JSON，把所有文件引用都改成直接文件名，不要有任何路径前缀。然后将模型目录下所有文件放在同一层级（不要分子目录），这样Unity的Cubism导入器基本都能正常解析。

4.2 模型加载出来是黑色的

通常不是贴图丢了，而是Unity项目没开启SRGB色彩空间。Live2D的部分材质需要Linear或Gamma色彩空间，但纹理必须以SRGB导入。排查流程：

• 打开Texture2D的导入设置，确认sRGB勾选。
• 确认Shader是否使用了Cubism自带的Cubism/Unlit系列，而不是PBR。
• 把场景光照设为“仅方向光”或关闭动态阴影，Live2D材质的阴影表现和3D模型不一样。

4.3 Android设备上闪退

多半原因是模型文件太大，贴图尺寸超过设备最大纹理限制。比如2048x2048在某些低端机上是OK的，但4096就会挂。解决办法：在model3.json里改用多张贴图，或者把大图切成多块，然后修改.moc3里的UV？等等，.moc3的UV不支持随便改，所以这个方案不现实。

实操上更靠谱的办法是：在Unity内用Texture2D压缩API把贴图压缩成ETC2，然后重新打包成AssetBundle。这样既保留模型完整性，又能适配移动端。

4.4 模型能显示但动作很僵硬

说明动作数据没加载完整。检查两点：

1. model3.json里是否配置了Motions中的Idle和TapBody动作。
2. Animator Controller里是否真的挂载了这些动画Clip。

如果原版动作导出后不可用，就用Cubism官方示例动作代替。官方动作本身就包含呼吸、眨眼、转面、点击反馈，效果已经足够自然，而且不用担心动作数据版权问题。

4.5 常见问题速查表

5. 工具选型与自动化脚本实战

5.1 unity-studio的高级用法：批量处理不再是梦

如果你只处理一个看板，手动操作完全够用。但如果你想备份所有看板、或者做一套自动化导出流水线，建议把unity-studio集成进Python或Shell脚本里。

下面是一个简单的Python批处理示例：

import os import subprocess import json bundles_dir = "./bundles" output_dir = "./export" os.makedirs(output_dir, exist_ok=True) unity_studio_path = "./unity-studio/unity-studio" for root, dirs, files in os.walk(bundles_dir): for f in files: if f.endswith(".ab") or f.endswith(".bundle"): bundle_path = os.path.join(root, f) out_path = os.path.join(output_dir, f.replace(".", "_")) os.makedirs(out_path, exist_ok=True) subprocess.run([ unity_studio_path, "extract", "--bundle", bundle_path, "--output", out_path, "--filter", "Texture2D", "--filter", "TextAsset", "--filter", "Sprite" ]) print(f"Extracted: {bundle_path}")

这个脚本会把所有ab/bundle后缀的资源全量拆一遍，导出贴图、二进制文本和Sprite。之后再用一个Python脚本统一扫描，把包含moc3文件名的目录标记为“Live2D候选”，大幅提升筛选效率。

5.2 Unity侧的自动化：Cubism模型批量导入

Unity编辑器侧重不直接支持把一个裸.moc3拖进场景就完事，它需要经过Cubism SDK的导入流程。实际上，Cubism SDK提供了一个CubismModelImporter脚本，你可以通过编辑器菜单Tools/Live2D/Cubism/Generate Model来导入。但如果你不想每次都点菜单，也可以写一个编辑器批量导入工具：

using System.IO; using UnityEditor; using UnityEngine; public class CubismBatchImporter : EditorWindow { private string sourceDir = "Assets/Live2D/RawModels"; private string targetDir = "Assets/Live2D/Models"; [MenuItem("Tools/Live2D/Batch Import")] public static void ShowWindow() { GetWindow<CubismBatchImporter>("Cubism Batch Import"); } private void OnGUI() { sourceDir = EditorGUILayout.TextField("Source Dir", sourceDir); targetDir = EditorGUILayout.TextField("Target Dir", targetDir); if (GUILayout.Button("Import All model3.json")) { ImportAll(); } } private void ImportAll() { string[] files = Directory.GetFiles(sourceDir, "*.model3.json", SearchOption.AllDirectories); foreach (string file in files) { string relativePath = file.Substring(sourceDir.Length); string dest = Path.Combine(targetDir, relativePath); Directory.CreateDirectory(Path.GetDirectoryName(dest)); File.Copy(file, dest, true); AssetDatabase.ImportAsset(dest); } AssetDatabase.Refresh(); } }

把原始模型文件从RawModels拖到Models目录并触发资源导入，Unity的Cubism SDK就会自动扫描.moc3和.model3.json生成Prefab资源。批量导入完成后，你就可以直接在场景里拖模型Prefab用了。

5.3 参数选择与计算：贴图尺寸、DrawCall、内存占用

Live2D模型的性能优化是很多人忽略的地方。一个精细的看板角色可能包含60~120个网格部件，如果每个部件一张独立材质，加上透明混合和动态批处理失灵，DrawCall会飙到很高。这时需要做图集合并。

合并的原则是：在2024~2048像素内尽量放满，但要避免超出设备限制。计算方式如下：

假设角色有24张512x512的部件贴图，单张面积0.25M。如果合成到2048x2048的图集，正好能放16张（4x4网格），总内存从6M降到4M，还少了一大截DrawCall。但你得先用工具把部件图按网格坐标拼好，再把.moc3里的UV做偏移映射——这一步很繁琐，如果不是性能瓶颈，建议谨慎折腾。

我更推荐的做法：直接用Unity的SpriteAtlas系统，把提取的所有Sprite放进同一个图集，然后让Cubism模型使用这些Sprite渲染。Cubism SDK支持这种方式，能有效降低DrawCall，又不用手改UV。

6. 扩展玩法：不止还原看板，还能做什么

6.1 把看板做成PC桌面宠物

当你成功把Live2D模型在Unity里跑起来之后，就可以把它封装成一个透明的桌面窗口程序。用Unity的Window和RawImage渲染模型，修改窗体样式为透明、无边框、置顶，再把点击事件转发给Unity里的OnMouseDown，一个桌面宠物看板就完成了。

过程中要注意：

• 窗口渲染用RenderTexture，需要每帧更新。
• 点击事件穿透需要调用Win32的SetWindowLong和WS_EX_TRANSPARENT。
• 性能占用取决于贴图数量和动画频率，待机时建议降低渲染帧率。

6.2 移植到Web端

借助Unity WebGL导出，可以在浏览器里跑Live2D看板。需要注意的坑是：WebGL的线程模型和内存限制，如果原模型贴图过多，建议先压缩。Cubism SDK官方支持WebGL构建，但部分高级物理效果可能降级。

6.3 做表情/换装测试床

提取出来的模型自带各种表情参数（ParamEyeLOpen、ParamMouthOpenY、ParamAngleX、ParamAngleY等），你可以写一个参数面板，把Cubism模型的参数全部暴露出来，做成一个“表情实验室”。输入0~1之间的数，就能看到角色眼睛张开、嘴巴嘟起、头发飘动的实况反馈。这个玩法非常适合做直播表情联动、VUP副屏展示。

6.4 数据驱动的内容联动

如果熟悉WebSocket或串口，把模型和后台数据打通——比如粉丝团人数越多，角色越开心；天气变化，表情、背景跟着变；甚至播放音乐时让模型跟着节拍点头。Cubism的参数是主动驱动式的，你只需要定时设置参数值即可：

_model.Parameters.FindById("ParamBodyAngleX").Value = Mathf.Sin(Time.time * 2f);

这种“数据→参数”的映射逻辑，扩展空间非常大。

7. 安全合规与长期维护建议

7.1 别踩的那条线

提取游戏资源这件事，技术本身是中性的，但使用场景决定风险。这里必须把话说明白：

• 仅供个人学习研究、本机备份，问题不大。
• 把提取结果做成视频发到公开平台，只要不用于商业盈利，一般是灰色但风险相对低。
• 但如果打包成付费应用、内购皮肤、NFT，或直接二次分发完整角色资源，这就属于明确侵权，切不可碰。

崩坏学园2不止的版权归属米哈游/崩坏项目组，角色立绘、Live2D模型、动作数据都受著作权保护。即使你改了颜色、换了名字，只要核心模型数据一致，在法律上依然很容易被认定为“演绎作品”。所以请把技术学习限定在“学习原理、验证流程、提升技能”的范围内。

7.2 社区经验与资料获取

国内关于unity-studio的教程很少，主要原因是这个工具偏底层，用的人少。但海外Cubism社区和Unity逆向社区有不少案例，搜索的时候可以用这些关键词组合：Unity AssetBundle unpack,unity-studio extract moc3,Live2D model extraction。

另外，GitHub上有些项目专门做Live2D模型的运行时优化、动作修复、Web展示，这些开源项目的代码本身就是很好的学习资料。拿来跑通一个最小demo，比抱着文档啃效率高得多。

7.3 后续维护：版本兼容问题

unity-studio本身更新频率不算很高，但Unity游戏会不断升级引擎版本，新版本的AssetBundle格式可能短期不被支持。如果未来崩坏学园2不止升级后，你发现自己“拆不了”了，有两条思路：

1. 等待unity-studio社区更新。
2. 用其他工具（UABEA、AssetRipper）做互补解析。

AssetRipper在某些Unity版本上很能打，它可以把整个工程反编译回Unity项目的结构，比直接从bundle拆文件更完整，但生成项目比较冗杂，适合做辅助参考。

8. 复盘：我自己踩过的几个大坑

说到这里，分享几个我反复翻车的场景，希望对你有帮助。

第一个坑：最初我追求“完美还原”，非要把原版AnimationClip转回.motion3.json。折腾了两三天，结果转出来动作扭曲，头发飞出去，表情失控。最后发现是Unity的骨骼绑定层级和Live2D的控制点系统根本不兼容。后来我直接放弃原版动作，用Cubism官方动作加自定义参数动画，效果反而更好。有时候“够用”比“完美”重要。

第二个坑：贴图压缩格式。我之前在Mac上做提取，导出的贴图是ASTC格式，Unity编辑器里能显示，但打包到Windows平台就花了。查了一晚上，最后确认是Unity的ASTC解码在非移动平台上默认不支持，必须在导入设置里勾选Override for Windows并改成DXT或RGBA。这种跨平台细节，文档里很少写清楚。

第三个坑：不要一次性把所有资源全提出来，再统一整理。正确做法是先提取一个看板，跑通全流程，再规模化。否则你面对几百个bundle、几千张贴图，光是文件重命名就能让你崩溃。先小后大，是我做所有逆向工程的铁律。

第四个坑：别忽略model3.json里的Version字段。Cubism 3和Cubism 4的模型结构差异很大，如果你拿Cubism 4的模型配Cubism 3的SDK，加载直接报错。下载SDK前，先看模型头部的MocVersion，确保SDK版本能兼容。

9. 从提取到创造：这才是“不止”的意义

如果这篇文章你已经看到这里，大概率已经掌握了用unity-studio提取崩坏学园2不止看板资源、并在Unity里重建Live2D模型的完整流程。但我想在最后多说一句：提取只是第一步，真正有价值的是你拿着这套技术做什么。

你可以把模型复用进自己的休闲游戏里，做一个会陪你说话的桌面萌妹；你也可以在直播里让角色随弹幕互动；甚至可以把这个提取、修复、驱动的流程，抽象成一套通用能力，去处理其他Unity游戏的Live2D资源，形成一个自己的“资源还原工具箱”。

我自己最享受的环节，其实不是看到模型在引擎里复活的瞬间，而是把碎成一地的贴图、乱掉的JSON、版本不兼容的SDK一点点修好的过程。它逼着你同时理解游戏引擎的底层、资源格式的规范、实时渲染的性能约束，这些知识远比“多了一个看板”值钱。

如果你做完之后也踩了什么新坑，欢迎在评论区分享。技术这条路上，一个人闭门造车远远不如几个人互相补充线索来得快。我先把自己的流程图和踩坑记录放在这里，剩下就等你动手了。