一个8万个零件的模型与长达九年的维护：i3 Corps的经验
为美国政府客户制作虚拟训练系统的美国公司 i3 Corps 介绍了自家3D管线的运作方式。该公司通过 Unity Addressables 把装备模型与应用程序分开存放。它起初自行搭建资产目录，后来放弃了继续开发，转而在政府云中部署了 Unity Asset Manager。如今 i3 Corps 正与 Unity 一起探讨，对于像自己这样的管线，这项服务应当变成什么样子。
该公司面对的任务在普通3D制作中颇为少见。这里的模型是真实装备的数字孪生，应用程序发布之后，针对它的工作并不会结束。一个模型的维护可能持续八到九年，而每年还会新增十到十五个。市场总监 Daniel Starkey 与系统架构师 John Thornton 在2026年11月10日 Unity 博客的一篇客座文章中分享了这些经验。
比采购项目活得更久的资产
该公司在 Unity 中制作了数百个训练场景。它们覆盖了 i3 Corps 所支持的大部分航空训练，以及海军平台和地面装备。应用程序通过一个分发平台送达全国各军事设施的教室。该平台由 i3 Corps 自行搭建，归政府所有，运行在受保护的政府云中。
作者们表示，最困难的部分位于应用程序之下的3D资源库。装备在不断变化：新部件列装，制造商重新设计某个零件，客户送来最新的CAD数据包。每一次都得有人弄清楚哪些零件被替换、这会影响哪个模型，以及教室里的哪些应用程序依赖于它。
«我们的一个飞行器模型有8万个部件——细到螺母和螺栓»。
— Daniel Starkey 与 John Thornton，i3 Corps
源数据同样如此。模型由来自不同渠道的CAD数据包和自家的摄影测量成果拼装而成。一次拍摄出行就可能产出同一台装备的数百万张照片。几年之后，同一平台的新CAD送达，就需要弄清旧模型是由什么做成的，才能把两者作比较。作者写道，这样的答案很容易丢失，而重新找回的代价很高。与此同时，这些资产多年间由十个美术团队修改——每周一次，有时每天都改。
一种机体，多种直升机
作者以 UH-60 Black Hawk 为例展示规模。仅美国陆军就拥有 UH-60A、L、M 和 V，医疗后送型 HH-60M，以及用于特种作战部队和其他任务的专用机型。再加上海军、空军和外国用户，需要训练的构型数量便迅速增加。其中大多数使用相同的机身、尾梁、旋翼系统和起落架。UH-60V 保留了 L 型机体的大部分，并换装数字化座舱。HH-60M 以 UH-60M 为基础，配备医疗设备和任务系统。
如果每个版本都从零开始建模，同样的零件就得反复建造、检查和维护。因此 i3 Corps 认为正确的做法是采用由可复用部件构成的通用基础模型，每个型号只添加真正不同的部分：结构、机械系统、航电或任务设备。
模型在构建包之外，目录在云端
为了不把模型放在应用程序内部，该公司使用 Unity Addressables。模型存放在与构建包分离的目录中，按需加载并在本地缓存。被十五个应用程序引用的资产只存储一份，而应用程序本身只有在其代码发生变化时才需要改动。
在资产自身的管理上，公司起初走了自己的路：在版本控制系统和自动化之上开始搭建数据库和检索功能。最终他们没有继续发展这个目录，而是在政府云环境中部署了 Unity Asset Manager。
这项服务的能力可以从它的文档中看出。资产版本以线性方式管理，可以为特定管线给所需版本打上标签，版本分为已冻结和可编辑两类。不同团队可以在不同项目中使用和修改同一个资产，互不干扰。依赖关系会把诸如预制件与其FBX和材质关联起来，同事导入时便会一并取得。2026年7月16日，网页版中出现了交互式依赖关系图。它有助于理清装配体这类复杂结构，并弄清一次修改会波及哪些资产。同期还更新了多组成部分资产的层级浏览。自2026年5月起，经过优化和转换的副本会以单独的关联资产形式创建，不会改变源文件的版本。
还有自动元数据：上传模型时，服务会自行统计三角形、顶点、材质和贴图数量、最大贴图尺寸以及独立对象的数目。它还会判断是否存在骨骼绑定、动画和UV。自定义字段可以是文本、布尔值、数值，也可以是链接、用户或日期。
这项服务目前还不适用的地方
该公司承诺另写一篇文章，说明 Asset Manager 目前在哪些方面还不适合自家管线，以及它正在与 Unity 共同打造什么来弥补这一差距。此外，i3 Corps 将于11月30日至12月3日参加在奥兰多举行的 I/ITSEC 2026，展位号 #1761。
从更宏观的角度，作者这样看：政府积累了海量的CAD和参数化模型。其中许多是多年前按合同交付的，如今要找到这些数据几乎不可能。而据他们判断，需求正在向仿真、可视化以及借助AI的内容生成转移。
这对工作室意味着什么
把 i3 Corps 的需求与 Asset Manager 的文档对照，就能看出薄弱之处。在网页界面中，依赖关系要通过编辑模式添加，而且只能单向沿链条向下；从 Unity 编辑器上传时，依赖项可以自动作为单独的资产导出。对于一个8万个零件的装配体而言，没有这类自动化就意味着大量手工劳动。依赖图能显示一次修改会波及什么，但功能说明中并没有现成的«各版本之间在零件层面有何变化»的比较，而作者恰恰把这项任务列为下一步目标。服务不会换算数值字段中的单位，只能把单位写进字段名称里。
授权方面也存在疑问。Asset Manager 的席位包含在所有 Unity 方案中，但 Enterprise 和 Industry 级别组织中的全部角色只有在拥有 Enterprise 或 Industry Floating 席位时才可使用。在那里 Collaborate 席位被限制为消费者角色。组织级别提升时，未转换到新级别的席位会被降为查看权限。席位说明页面上没有价格。在公开文档中也未能找到政府云版本与普通版本有何区别的说明，以及更新后的模型如何送达教室电脑缓存中的旧副本。
同样的问题，大概所有资产寿命超过单个项目的团队都不陌生：工业可视化、周期长达数年的建筑可视化，以及为多款游戏维护统一装备库的工作室。对他们来说，这篇承诺中的局限性分析或许比眼下这篇文章更有用。
i3 Corps 为何放弃自建目录转而选择 Asset Manager：是自有代码维护成本高昂，是政府云的要求，还是指望能影响 Unity？