做项目当然可以用第三方资产。已经有人做好的东西，质量也合适，没必要每次都从头来一遍。但我比较在意的是：它放进我们的工程之后，还能不能像演示场景里那样好用？

单独看一个模型，往往挑不出太大问题。等它和项目里的灯光、母材质、碰撞、目录放到一起，才会发现有些地方对不上。我以前给团队整理过一张接入流程图，最近重新翻出来，觉得里面不少要求仍然实用，只是有些规则需要把当时的条件说清楚。

先放进测试工程，别急着往正式项目里搬

原流程的第一步，是判断这套资产到底要不要正式使用。只想研究一个效果，或者拿来试试风格，就先留在个人测试工程里。需要的是几块模型，就不必把整个演示关卡和它的全部依赖一起带进去。

我觉得这一步很有必要。正式工程是大家共同工作的地方，里面每多一套资源，后面都可能有人要找它、改它、处理它的引用。先把用途想清楚，整理起来反而省事。

这是当时使用的第三方资产接入流程图。下面按实际检查顺序展开说，其中对旧规则的调整会另作说明。

模型先看怎么用，再看有多少面

模型进来后，我会先看尺度、轴心、拼接、碰撞和 UV，再结合场景判断面数与 LOD。建筑模块要能对齐，门和台阶要与人的尺度相符，需要交互的物件也得有合适的碰撞。只把面数降下来，这些问题不会跟着消失。

旧规范里写过单体物件五万三角面的上限。这个数字是当时给制作侧的预算，并不是每个道具都可以放心用满。一个近处的重要物件，和沿街重复几十次的小摆件，使用条件差得很远。到了 VR 或移动设备上，更不能脱离同屏数量去看一件资产。

光照 UV 也要按实际用途准备。项目需要烘焙光照时，要检查相应 UV 的展开与重叠；不能因为纹理 UV 看起来正常，就认为这一项也已经处理好。

贴图和材质，是我会多花一点时间的地方

我做硬表面和材质比较多，对这一块会更留意。同样一组金属资产，换到另一套灯光下面，粗糙度、法线强度和色调可能都需要重新判断。演示图漂亮，只能说明它在那套条件下成立。

尤其是打包贴图，要看清每个通道实际存了什么。文件名叫 ARM 或 ORM，不能代替通道检查。贴图类型和颜色空间也要与用途对应，再接进项目的材质。

旧文档提到的 4K，是制作输出的精度要求。我会把源文件留得完整一些，但设备实际使用多大的贴图，要看观看距离、画面需要和资源预算。没有必要让一个远处的小物件始终占用最高规格。

当时我们倾向于接入项目已有的母材质，方便统一调整常用参数。我现在仍然认可这个方向，不过不会为了“统一”而硬替换所有资产。植被摆动、透明、特殊动画等效果有自己的依赖，替换之前要先确认功能保不保得住。

还有一点容易说混：大家都用了同一套母材质，不等于场景就已经自动合批。网格、材质实例、插槽和渲染方式，仍然需要回到工程里检查。

蓝图和依赖，要知道带进来了什么

旧流程对第三方蓝图限制比较严。那是当时为了控制工程里未知功能和依赖做的规定，我不会把它理解成所有项目都应该禁止第三方蓝图。

确实需要它的功能，就先在隔离环境里试清楚：依赖哪些插件，有没有改输入或项目设置，逻辑从哪里开始，打包后是否还能运行。能用、知道怎么维护，再按团队约定接入，比较踏实。

迁移时，UE 的 Migrate 工具会列出依赖。这个清单值得看一遍，避免漏掉必要资源，也避免带入不需要的演示内容。迁移目标和目录需要按项目要求选择，不能为了文件夹看着整齐，就随手搬动一批 .uasset。

导入成功以后，还差最后一轮检查

命名和目录整理完成后，我会回到实际关卡里看一遍。材质有没有丢，碰撞是否正常，关键表现有没有变化。移动或重命名资产产生的重定向器，也要在引擎里妥善处理，而不是直接在资源管理器里删除。

如果现在重新做这套流程，我还会补上资产来源与版本记录，以及目标设备上的构建检查。这些是这次回看后的补充，不是说旧项目当年已经把所有环节都做得很完整。

第三方资产到底有没有帮上忙，最后看的是团队能不能顺利使用和维护它。省下建模的时间，却在接入和返工上花得更多，就需要重新考虑用法了。

资料来自我保存的《第三方资产引用流程规范》和《三维生产说明文档》。正文保留实际流程图，封面是为本文制作的示意配图。