游戏工业化？——Pipeline 基本概念之资产管理

上文我们说到了 Pipeline 需要管理的数据和元数据，以及它们的特点和管理方式。

一个资产有不同组成部分，每个部分都有文件数据和元数据，海量的资产就组成我们资产管理系统。

那么，要搭建资产管理系统，从哪里着手呢？

莫急，我们来观察一个（主要是影视）美术的一天。

一个 Artist 的日常

备注

实际上，并不是“导出下游资产文件”，任务就完成了，完事大吉了。

首先比如模型任务并不是必须100%完成，才能给到绑定；其次哪怕模型任务通过了，也有导演/总监想法又变了，或者模型文件有质量方面的问题，都需要重新进入制作，然后导出下游资产文件。

从上图中，我们可以看到明显有三类文件：

• 工程文件，我们取个代号叫 workfile：美术工作的文件，通常是 DCC 的 project file，比如 ma、mb、max、hip、 psd、spp
• 图片或视频文件，我们取个代号叫 dailies：可以通过review 系统进行查看的文件，比如 mp4、mov、avi、png、jpg，如果 review 系统支持3d 资产查看，那么也可能是fbx、obj 等格式
• 上下游交接文件，我们取个代号叫 element：比较“干净的”，通常是第三方格式，比如三维资产的 obj、fbx、abc、usd等，二维资产的 png、jpg、tga、exr

举个例子，现在有个工业化厨房，你的工作环节是切土豆丝：

你从 A 窗口拿到一个削好皮的土豆（上游的element）

你的 workfile包含了你的案板、你的刀、切的土豆丝、切下去的边角料；

你的 dailies 就是你干着活，老板想看看你的工作成果，有没有切成他喜欢的形状，这时候你就拿手机拍了照或者拍了视频发给老板，老板说我喜欢那种波浪状的土豆丝，于是你换了个刀片，开始切波浪状的土豆丝，再拍照发给老板，老板说没问题了。

然后你把切好的，大于4cm的（经过质检）土豆丝，这就是你导出的element，放在另一个窗口，Pipeline 会自动把它送到下一个环节的 A 窗口。

题外话

影视有更细分的环节TD，负责帮你把切菜的刀改进得更锋利一些、或者引进更先进的切菜手法、研发更多方便提升效率的刀片.....

我们把文件分类好了，就可以根据他们的特点，以及应用场景，分而治之，逐个击破。

在此之前，我们还需要对文件什么时候，在哪里放，做一些说明。分别提到影视的文件共享方式（比如NAS）和游戏的中心化版本管理系统（比如P4V）

工作区 vs Publish区

这里会涉及一个 workspace（工作区） 和文件管理系统服务器（publish区）

如果是 P4V 这样的管理系统，则工作区就是你在客户端里面看到的workspace，它是你本地的一个目录，而 publish 区就是 P4V的服务器

特点：文件不下载到本地电脑里，就不能引用。

首先我们最好要求美术的workspace，都设置为统一个位置，比如d:/my_workspace，这样，d:/my_workpace/....../char_goblin_rig.ma就可以引用d:/my_workpace/....../char_goblin_model.ma文件，Submit到 P4V服务器时，把 rig 文件依赖的 model 文件路径信息，保存到数据库里，其他人下载了该 rig文件时，从数据库读取到依赖的 model 文件，则把 model 文件也一同下载了，打开 rig 文件，引用关系正确无误，文件没问题。

如果美术的workspace位置五花八门，则文件的引用需要使用相对路径，如果跟被引用文件层级相差较远，则会带来阅读的不方便，想想看../../../../model/char_goblin_model.ma。

NAS的方式：工作区和 publish区，都在NAS服务器上，只不过分成了两个文件夹：

这种方式，美术无需本地有额外硬盘空间，而是直接就在NAS服务器上进行制作，无需上传下载。

首先需要美术把NAS映射为同一个盘符，比如 x:/。一般影视公司 IT 可直接全域推送，无需美术手动连接。

美术的绑定文件 x:/workspace/artist_xxx/....../char_goblin_rig_v002.ma引用的是 x:/publish/....../char_goblin_model_v002.ma

美术在NAS上的个人workspace文件夹中，只存放他自己的工程文件即可，无需拷贝相关引用文件到他的workspace下。

publish区的文件一般有严格的权限管控，不允许普通用户删除和修改，如果文件需要更改，则要升级一个版本，比如从v002升级（另存为）为v003，并且提交（拷贝）到publish区。

谁能提交什么类型文件，是由该美术的任务决定的，也就是说，一个动画师，没有model任务，该动画师根本就无法去提交一个model文件。

注意：上述提到的“另存为”“拷贝”，并不是美术手动操作的，是由Pipeline 系统操作的（类比一下P4V客户端对于的按钮）。

如果你家的NAS各方面性能承受不住这么用，丐版NAS可以是这种工作方式：

首先美术需要把 NAS映射为同一个盘符，比如 x:/。

美术的rig文件，引用的是NAS上的model文件，做完之后上传（拷贝）到NAS的publish文件夹，其他美术下载（拷贝）rig文件，打开也是没有任何问题的。

上述提到的“上传”“下载”“拷贝”，并不是美术手动操作的，是由 Pipeline 系统操作的（类比一下P4V客户端对于的按钮）。

这个话题结束，我们继续讨论三种类型文件。

工程文件 Workfile

通常是 DCC 的 project file，是美术制作的文件。

这里 Pipeline 主要就是解决：

• 标准命名：美术仅提供文件命名的描述部分descriptor，命名的其他部分则由Pipeline 系统来完成。比如 goblin 的某个动画文件，美术需要提供类似walk这样的描述，则该文件会被自动命名为char_goblin_ani_walk_v001.ma，文件命名规范需要根据项目资产特点来制定。
• Publish（升级）：将 workspace文件进行升级，并上传到文件管理系统中。此处也需要上传适当的 metadata 到 Pipeline 数据库里，比如它的上个版本是谁，比如它依赖引用了哪些文件。
• Checkout（下载）：从文件管理系统中下载指定版本文件到 workspace下，原因可能是自己workspace删除了，或者是A的任务交给B做了，B需要从文件管理系统中下载A提交的文件。
• 版本回退：把文件回退到某个之前的版本，基于之前的版本继续制作。
• 质检：文件在publish之前，需要做一些检查，以防文件有垃圾节点之类的，造成文件打不开。

此部分的工作，跟用哪个DCC，相关度很小，主要是跟文件管理系统有关，基本就使用了DCC 的 new、open、save、save_as 这几个 API。

所以，我们可以得出结论，workfile类型的文件，跟行业、公司、项目类型、环节，基本无关，Pipeline 系统可以轻松管理。

媒体文件 Dailies

通常是视频或图片，体现工作内容，用于给导演、总监、主美、组长等进行 Review/监修/审查。

这里 Pipeline 主要就是解决：

• 标准命名：一般跟对应的 workfile 名字一致。
• 标准化图片、视频：统一的水印、分辨率、色彩转换、编码方式等等
• 最好附带辅助工具，如三维软件拍屏工具、截图工具、录屏工具、拼图工具......
• publish 到 Review 系统中，并且记录该文件依赖的 workfile 信息到 Pipeline 数据库中。

此部分的工作，跟用哪个DCC，相关度很小，主要是跟 Review 系统有关。

所以，我们可以得出结论，dailies 类型的文件 ，跟行业、公司、项目类型、环节，基本无关，Pipeline 系统可以轻松管理。

交换文件 Element

通常是第三方格式，用于不同DCC之间、不同人员、不同环节之间进行资产交换。

这个同时也是流程千变万化的主力部队，是跟行业、公司、项目类型、环节，大大相关。

影视的 DCC 除此之外还有：Hiero、Clarisse、Katana、Mari、ZBrush、Modo、SP、SD、Photoshop、Pftrack、SynthEye... ...

这里还没扯上环节，如此排列组合，也是大家经常说的“我们项目不一样”。

这里 Pipeline 主要就是解决：

• 导出：不同DCC的不同环节导出不同的第三方格式文件。记得要记录 workfile 的信息。
• 质检：很容易理解，我们不能把有问题的资产引入系统中。
• 导入：不同DCC的不同环节导入不同的第三方格式文件。
• 更新通知：当有新版本element导出时，可以通知到使用了此element 的workfile（的拥有者）
• 更新：有新版本element时，用户可以更新，最好是一键，同时用户也可以切换到任意旧版本element。
• 导入、导出的脚本是一对，最好也有版本控制，这样制作中途element有变动，比如参数不同了，旧版本导出脚本导出的element，可以使用旧版本的导入脚本进行导入，减少了脚本要各种兼容历史遗留的问题。

下一篇文章，我们展开讨论一下，如何应对千变万化的element

缓存文件 Cache

咦？怎么冒出了一个你没有分类出来的文件？！

在影视，一般是一种自产自用的文件，比如把 houdini 一大堆的节点，解算出缓存，然后再导入回houdini 中，用结果继续进行节点连接。这种文件的特点是占用空间大，删除可再次生成，在项目结束进行打包的时候，完全不需要备份。

游戏还有一种 cache，中间转换文件，例如 fbx 导入八猴进行烘焙，再把烘焙出来的文件导入到 sp 等进行其他贴图绘制。

八猴文件我们可以直接通过其 python api 动态生成，这个八猴文件可以考虑到底留不留下，留下的话方便万一标准参数下烘焙效果不理想，可以手动调整。推荐根据实际情况。

和影视不同的地方：

游戏行业制作环节大大缩减，一个人需要负责多个环节，比如有些项目动画师也得做绑定。需要我们帮助美术减少修改操作步骤，跨软件 Live Link 进行数据实时传递。

其次，各环节资产最终都是要在引擎里看效果的，所以要尽可能拉近美术和引擎的距离，依旧需要各种 Live Link。

关系

element、dailies 都是从workfile产生的，那么有一个原则，只要有 dailies/element 一个版本，就必须保存产生该文件的workfile，因为dailies会被别人（总监）看到，element 会被别人（其他美术）用到，但凡涉及到文件被其他人“观察”了，就要保存其源文件，以便“还是觉得半个月前看到的那个版本更好”“我用的xxx版本是没问题的”时，可以找到源文件，branch 出去继续做。

还有一点：

当：只是导入engine 时，参数设置需要更新，那么 element不用重新出，只需重新导入engine 即可，如果导入时已经记录过了引擎资产<->element的关系，那么此时就可以对涉及到的引擎资产，自动化批量重新导入。

当：element内容不够了（虽然已经尽最大可能确保内容无损了），workfile不用变，美术无需打开文件修改，只需重新导出 element，再导入engine，这两步，大概率也可以自动化批量处理。

当我们记录完备了这几种文件的依赖关系，那么我们很容易就可以绘制出如下的关系图：

引擎资源

整个项目的所有资源都需要导入到游戏引擎中，它同时也是最末端，由它最终打包出成品。

这个特性非常类似影视的 Finishing System，DaVinci Resolve 软件。

DaVinci Resolve is the world's only solution that combines editing, color correction, visual effects, motion graphics and audio post production all in one software tool!

最近版本增加了远程协作工具和基于云的工作流程，这简直就是真·大型·多人·在线·实时协作（MMO-DCC???）

进入到了引擎的美术资产，后续就在引擎里自产自销，项目的引擎工程会有真·版本管理系统如P4V、SVN等，所以针对引擎里的美术资产管理，我们就只管理 metadata。

Messiah 这点非常爽，二进制数据和metadata完全分离，metadata全部存放在 xml 里面，这让我们的提取工作量和难度减少了个数量级。（但是拆分和写入不合理，移动下资产就有十几文件被修改了你是认真的吗，这是要了美术协作的命啊）

但一点都不简单，复杂度非常高，要跟引擎里的各种模块编辑器打通，比 level editors, animation blend-tree authoring tools, state machine editors 等等，确实是一个非常艰巨的工作。

一个动画师修改了一段动画的时长，它会影响到游戏的很多地方，那到底是哪些地方？

并不是说太复杂了太艰巨了所以我们就不做了，而是因为太复杂了太艰巨了，所以我们才去做。

当然没必要非得要万事俱备才开始做，而是边做边解决，能解决多少就解决多少。坚定不移的做难而正确的事。

在这个方面我还是一个新手，求求各位游戏大佬，多多分享些经验出来。

---

当我们把各种类型文件、各种环节文件都安排得井井有条，相应的metadata都搜集完备，资产管理系统，这不就已经完成了七七八八了吗？

接下来，就是怎么展示给用户的事情了。我们需要一个：

资产浏览器

可以独立运行版的，不打开任何DCC、不开游戏引擎、暂时不用下载任何资产文件，就可以浏览资产的 Asset Browser！

找到它

这个浏览器，它必须具备花式条件搜索、模糊搜索、收藏、打tag等常见资产库的功能。

可以根据用户的需求，有多种浏览方式：

• 阵营 -> 种族 -> 性别 -> 资产
• 发布版本 -> 英雄 -> 皮肤 -> 资产
• 地图 -> 区域 -> 城市 -> 兴趣点 -> 建筑 -> 资产
• ...

把玩它

当定位到具体的资产后，我们要展示这个资产方方面面的信息：

• 查看它的原画设计
• 它的模型、模型的工程文件最新是哪个版本
• 总共提交过多少次 Review
• 绑定是哪个美术做的，什么时间完成的
• 它有多少面、有无骨骼、贴图几张
• 它被放置在了哪些关卡，哪些位置，被放置了多少次，能在游戏地图中标识出来
• 可以用DCC打开它的任意环节的工程文件（此时才需要下载该文件）
• ......

这里能做的事情太多太多了，一定要留有API接口，方便其他TA、TD，或者自己，随时新增更多功能，因为关于资产的所有信息都在，你可以对它为所欲为。

这个 Asset Browser，最好是可以在DCC 和引擎里打开；选中DCC 和引擎中的某个资产，可以获取该资产的详细信息；可以根据上下文和某些规则，比如是哪个城市，自动推荐合适的建筑物。发挥你的脑洞，发挥美术的脑洞。

好了，篇幅够长了，今天就先到这里。

我们前几篇文中，一直提到，Pipeline 在这里要做什么、那里要做什么，感觉零零散散的，可能大家脑中还是拼不起来，能不能系统说一下，Pipeline 到底要有哪些功能？

敬请期待下一篇。