资产目录这个东西，很容易做得特别完整。环境、角色、灯光、特效，再往下分几层，一张图展开，看起来什么都有了。但真正在工程里用的时候，我更关心一件事：需要改一个资产，大家能不能顺利找到它。

模型在哪，材质在哪，Painter 的源文件又在哪。最好不用每次都去问最初做这个资产的人。尤其多人协作的时候，目录得让接手的人也看得懂。

下面这张图，是我以前为团队整理的资产目录。它同时说明了 UE 的 Content 里怎么放，以及引擎外的制作文件怎么留。现在再看，有些习惯我还会保留，有些分支对小项目来说就不必照搬。

当时的团队资产目录图。它记录的是那一阶段的组织方式，不是要求所有项目照着建立同样多的文件夹。

一套资产，尽量能一起找到

拿建筑套件来说，模型有自己专用的材质、贴图和组合方式。我更愿意把它们放在同一个套件附近，而不是所有模型进一个大目录、所有贴图再进另一个大目录。

这样改一栋建筑时，相关内容比较容易看全。只有确实被多个套件共用的母材质、材质函数和纹理，我才会把它们放到共享目录。还没有人复用的东西，不用急着起名叫 Common。

旧图里也划分了项目资源、个人试验区和第三方内容。这个思路我觉得仍然有用：看到一个陌生文件，至少可以先判断它是正式内容，还是某个人正在试的东西。

源文件留好，比文件夹名字漂亮更重要

UE 里的资产负责最终使用，Maya、Blender、Painter 或 Houdini 的工程则保留制作过程。两边需要能对应起来，但不必混在同一个 Content 目录里。

我最近整理个人场景项目时，大致考虑了下面这种关系。这里只是一个套件示例，命名可以按自己的习惯改：

Content/Project/Env/Architecture/SanctuaryKit/
  Meshes/
  Materials/
  Textures/
  Assemblies/

SourceArt/Environment/SanctuaryKit/
  Reference/
  Sources/
  Textures/
  Exports/UE/

Sources 里再按需要保留不同软件的工程。软件可能会换，但这套建筑还是这套建筑，所以我会先按资产归属组织，再考虑软件分类。

Exports 存交给引擎的文件，SourceArt 保留可继续修改的原稿。两者都不是“放进去就算备份了”，仍然要有版本记录或另外的备份方式。测试包也应该单独放，不能拿一个能运行的包代替源工程。

小项目可以少建一些目录

以前做团队规范，会希望把可能遇到的情况提前写出来。现在自己做场景，我反而会收一点：灰盒阶段有 Blockout、Env 和 Maps，能把工作推进就先用着。等真正有了建筑套件、共享材质或交互内容，再补对应目录。

一个套件只有几个文件时，也没必要硬分成四五层。目录本来是为了减少查找，分完之后每次点得更深，反而不划算。

这些是我最近整理方案时的取舍，其中有些还在计划阶段。我不想把一张目录建议图写成已经完成的管线成果，后面实际用起来有问题，仍然会改。

文件放在哪里，和关卡怎么加载，是两件事

旧图里有按叙事、环境、角色和灯光拆分的关卡。这样分有当时的协作需要，但不能只看文件夹名字，就以为场景加载已经安排好了。

Content 目录管理资产文件，World Outliner 的文件夹整理场景中的实例。子关卡、Data Layers、World Partition 则要结合工程的加载与协作方式来使用。新建一个 Maps/Subs 文件夹，不会自动产生流送关系。

所以我现在会先把主地图和典型流程跑通。确实需要多人分工或者分段加载，再决定怎么拆，而不是先把所有子关卡名字列完。

旧图里，有几处不能直接照抄

LOD 和碰撞不一定需要各建一个 Content 文件夹。静态网格中的 LOD、简单碰撞通常就在网格资产里管理，制作侧的源文件可以另外留好。

命名也要分清团队约定和引擎规则。例如旧图中的 COL_ 可以用于制作侧识别，但通过 FBX 导入自定义凸碰撞时，应遵循 UCX_ 等对应的引擎命名要求。名字看着像“碰撞”，引擎未必会按碰撞处理。

平台差异也不必一开始就复制出两套完整资产库。能通过质量配置和平台资源设置表达的，先共用；确实需要不同资产，再做清楚的变体。否则修改一个模型，要记得同步两份，维护起来更麻烦。

还有生成文件。像 OFPA 使用的外部 Actor 文件，虽然目录不适合手工编辑，里面却保存着关卡内容，不能因为名字陌生就当缓存删掉。

整理旧工程时，我会慢一点

已经在用的工程，不能只顾着把目录重新排漂亮。我会先确认有能恢复的版本，再挑一小组资产试着移动。操作放在 UE 内容浏览器里做，保存相关内容、处理重定向器，然后重新打开引用它的关卡检查。

外包收发目录可以按批次保留，但最终采用的资源，还是应当回到它所属的资产位置。否则过了几个月，只剩“某某发来的最终版”，别人很难继续维护。

我希望目录最后能回答的，其实都是很普通的问题：文件在哪，源文件在哪，谁在用它，改错了怎么恢复。能把这些问题交代清楚，目录就已经帮上很大的忙了。

本文结合旧团队目录图与最近的个人场景目录方案整理。正文原图用于说明历史实践，封面为示意配图。