DCC 与引擎同步

先把题目说成人话

制作软件里的椅子已经加粗了椅子腿，引擎里却仍是昨天的旧椅子。若工具在模型刚写到一半时就开始导入，还可能得到损坏文件；若模型与纹理分两次到达，又会短暂出现“新模型配旧材质”。

这题要设计的是一条可靠的交接流程：制作模型的软件叫数字内容制作工具（DCC），例如（Blender / Maya）；它先把同一版本的模型、纹理和说明清单全部准备好，再交给引擎（Unity）验货。只有整批内容都正确，正式资产才一起更新；途中失败则保留旧版本。

这是虚构教学故事，不是个人项目经历。

场景：先让问题变得看得见

制作软件（Blender）里有一把四条腿的木椅。美术缩短靠背，把原来的一个外观区域拆成“木头”和“金属螺钉”两个区域，然后点击“发送到引擎”。

（右脑）画面：按钮按下以后，椅子没有立刻冲进项目。工具先查看它有没有名字、大小是否异常、原点是否在预定位置、两种外观是否都能找到所需图片。检查通过后，椅子的形状、图片和一张写着“这一批共有些什么”的清单被放进同一个临时房间。所有东西到齐，门上才挂出“可以接收”的牌子。引擎把整批内容搬进一间与正式项目隔开的验货区：椅子大小正确、朝向正确、两种外观都接好以后，正式场景里的旧椅子才被这一版替换。若途中断线，旧椅子继续使用；同一批东西重新送达，也不会在项目里复制出第二把。

（左脑）对表：形状和动画可由模型交换文件（FBX / glTF / USD）承载，纹理保持为独立文件；结构化清单（JSON manifest）记录资产键、源版本、规则版本、单位、上轴、前轴、变换空间、材质槽、依赖路径和文件哈希。发布信号必须发生在全部文件完成以后。引擎先导入暂存区（staging）并校验，再提交正式版本；同一任务重复执行仍只产生同一份结果，称为幂等（idempotence）。

小明：先形成一个完整猜测

小明用文件监听器看到模型文件变化就立即覆盖 Unity 目录。一次导出只写到一半便触发导入，留下损坏文件；另一次模型先到、纹理后到，正式场景短暂出现新椅子配旧材质。重试以后，项目里又多出一套重复材质。失败说明：看见一个文件出现，不等于知道同一批内容已经全部完成。

小红：把猜测放回现实检查

小红保留现有模型格式，只增加清单和暂存目录。制作端先做导出前检查（Preflight），然后把所有产物写进临时目录；全部写完以后才发布清单。一次任务可以写成：

{
  "schemaVersion": 2,
  "jobId": "prop-chair:184:rules-5",
  "assetKey": "prop-chair",
  "sourceRevision": 184,
  "sourceApp": "Blender",
  "coordinates": {
    "sourceUnits": "m",
    "metersPerSourceUnit": 1,
    "sourceUpAxis": "+Z",
    "sourceForwardAxis": "-Y",
    "sourceHandedness": "right",
    "targetUnits": "m",
    "targetUpAxis": "+Y",
    "targetForwardAxis": "+Z",
    "targetHandedness": "left",
    "transformSpace": "local-to-parent",
    "axisAndPivotConversion": "baked-by-rules-5"
  },
  "mesh": { "path": "chair.fbx", "sha256": "…" },
  "materialSlots": ["Wood", "Metal"],
  "dependencies": ["tex/wood_basecolor.png"]
}

模型文件承载几何和动画，JSON manifest 承载版本、坐标约定、路径、哈希、材质槽和依赖。复杂的 Blender 节点网络不会自动变成 Unity Shader；清单只能说明材质槽需要哪些贴图、通道如何解释，以及 Unity 应该套用哪种项目材质模板。

引擎校验 schema、哈希、单位比例、坐标方向和依赖后，先在 staging 中导入并检查代表性 Prefab。小红再故意中断传输、重复投递同一 jobId，并发送一个较旧 revision：中断后可以继续，重复任务仍只有一份，旧版本则被拒绝覆盖新版本。

我：用检查结果修正模型

我先划清两边的所有权。DCC 负责网格、骨骼、动画、原点和材质槽；Unity 负责 Importer 设置、项目 Shader、Prefab 脚本、Collider、LODGroup 和运行时组件。重新同步网格时，不能把程序已经配置好的游戏逻辑一起覆盖。

任务状态记录为 exported / transferred / validated / committed，身份使用 assetKey + sourceRevision + ruleVersion。提交可以选择在稳定路径更新内容并保留原有 .meta 与 GUID，或让每版使用新路径、再通过统一注册表切换入口；不能把文件与 .meta 分开搬，也不能期待已有 Prefab 引用自行找到新版。

（右脑）画面修正：同步不再是“文件一出现就搬走”。制作端先把同一批模型、图片和说明单全部装好并封口；引擎在空房间里把椅子装起来，确认大小、方向、外观和依赖都正确，才替换正式场景中的旧椅子。途中断掉时旧版继续工作，再送一次也不会越堆越多。两边各自保管自己的东西，更新椅子形状不会顺手抹掉它在游戏里的碰撞和脚本。

（左脑）严格对表：流程为 DCC 预检 → 临时目录写入产物 → 完成后发布 manifest → Unity 拉取不可变 staging → 校验 schema、sha256、单位、上轴、前轴、变换空间、材质槽、依赖和 revision → 导入并验证代表 Prefab → 整批提交或拒绝。旧 revision 不能覆盖新版，同一任务重试必须仍只有一份结果；稳定路径方案要保留 .meta 与 GUID，版本路径方案则必须通过受控注册表切换引用。

你已经明确：你没有写过 Blender 到 Unity 的同步插件，只使用过两者，并把 Blender 模型和材质人工导入 Unity。本页不能替你补写真实插件经历；其中的自动同步只能标注为设计方案。

老师解惑

• 数据所有权：DCC 与引擎各自能修改什么必须唯一，否则双向同步会互相覆盖。
• manifest：描述任务和依赖，不替代 FBX/glTF/USD 的几何数据。
• 幂等：同一 revision 重试多次，最终结果仍只有一份且内容相同。
• 原子提交：验证全部通过才切换当前版本，避免“旧网格+新材质”的半状态。

工具分工

• Maya/Blender 插件：收集选择、预检、导出并生成 manifest。
• Unity Editor 导入服务：校验 schema/哈希，在 staging 导入后再提交。
• 队列或文件服务：传输任务和状态；不承担资产语义判断。
• 版本控制/对象存储：保存不可变产物、manifest 与回滚版本。

记忆钩子

先定谁拥有真相，再用 manifest 对账；同步要能重试，但不能重复生孩子。