以下文章来源于腾讯游戏学堂 ，作者Gandalf Mu
腾讯游戏学堂.
笔者曾在影视后期Pipeline领域工作多年，后来转至游戏行业并继续从事Pipeline方向的工作。影视Pipeline百花齐放，而且不断在进步，而随着游戏工业化的不断发展，游戏研发当中的Pipeline也越来越受到重视。游戏工业化包含诸多模块，其中美术流程工业化这一点，绝对绕不开，并且也是其中的重要部分。本篇文章主要和大家讨论一下影视Pipeline、游戏Pipeline，以及他们之间的异同点，涉及项目管理和数据管理两方面。文中的内容均是我个人的经历以及朋友们的经历，并不代表整个国内游戏行业。如果你那里的情况不同，非常欢迎你在评论区留言，让大家的信息更加同步，相互学习，共同进步。
我们在工作中会碰到如下问题：
我们把上述的问题，按照相关的工作岗位，聚类一下：
Pipeline 就是来解决上述问题的。
更概括一点说，Pipeline 是管理项目的信息和数据的流动。
信息被高效、正确、及时地传达到位
数据的来龙去脉、前世今生、脉络关系管理的清清楚楚明明白白
它是谁，它从来哪里，它要到哪里去
非常重要的前言：没有放之四海而皆准的 Pipeline 系统，一定要根据项目的实际情况，只有适合你的 Pipeline才是好的 Pipeline。如果是一个几人的小团队，喊一嗓子就能沟通到位的事情，没必要花时间精力去折腾 Pipeline系统，得不偿失；或者项目的美术资产很少，也确实没必要。
开发和维护 Pipeline 系统的人，在影视行业，叫做 Pipeline TD。
下面一张图片，展示了一个动画电影的完整制作流程，你能找到 TD 在哪里吗？
[ 图源：file/tupian/20220803/www.illuminationmacguff.com ]
可以看到，TD 们都是在小房间之外走动，负责监控和维护，保障整个管道正常运行的人。
继续我们的话题，本文我们从刚开始提到的三个岗位的工作内容角度，将 Pipeline 要管理的范畴，分为三大类：
项目管理
Review
资产管理
这三者并不是隔离的，而是紧密结合在一起的，之间的数据和信息流动是要丝滑的、无缝的。
其实 Review 是包含在了项目管理中的 ，但在游戏过程中，由于大家经常忽视 Review 这一块的重要性，所以我就把它单独拎出来。
按照影视的说法，就是分 Production Management 和 Asset Management。
项目管理
我们这里不涉及项目管理模式，如Agile、Waterflow。
这里的内容主要包含：
任务分配、排期
任务的上下游关联
任务的资产关联
跟踪资产完成度、发行版本、项目进度等
这里涉及到的数据类型：
Project
Phase
Asset
Task
People
TimeLog
大概的关系是：
上述涉及到的内容，最好有甘特图来协助查看和便捷编辑。
另外要有多样的 filter，协助项目每个人查看他感兴趣的部分，比如：
列出所有动画任务
列出所有两周内要过期的任务
列出包含在xxx版本要上线的任务
该系统必须可以应对变化，大到比如外部环境变化导致的延期、比如老板突然要调整游戏上线日期，小到人员离职，多增加美术、多外包、系统可以快速调整和更新排期，确保每个人都知道自己该做什么、该什么时候做、先做哪个后做哪个。
具有项目管理功能的软件/系统有很多，影视或游戏行业在这方面的基础需求也没有太多的特性，强烈建议直接使用一个用户量多的、适合你项目体量的商业系统就行，前提是这个系统必须支持二次开发，因为只满足基本需要可远远不够，按照之前的经验，我们 Pipeline 在这个部分的主要精力放在了
将生产数据进行各种角度的可视化，帮助PM 精细化管理项目周期和人力安排，把控项目风险，避免空转/过载
开发各种自动化监听脚本，比如当A任务完成80%就把 B任务状态改为“可以开始”，减少 PM 手动、重复工作量，减少人为出错
开发各种RTX通知机器人，比如提醒美术临期任务。及时提醒，避免遗漏
开发各种小工具，包括并不限于浏览器插件、基于管理系统的菜单拓展等，减少PM 操作步骤
生成产能报告，展示进度、落后的部分、资源闲置等等状况
另外，提到它必须提供二次开发接口，还因为这里的信息，是要出现在美术的工作环境中的，比如DCC、引擎里的
再次，还需要强调的是，该系统的数据库支持一定程度的自定义：可以多增加表；已有的Table 或者新增的Table 可多增加 Column。
随着项目越来越复杂，需求量增多，Pipeline 岗位再次被细分，甚至前几年国内都有公司招聘制片TD。在我查找小黄人那张图片的时候，看到做小黄人的 Illumination 公司竟然也有招 Production Technical Director。
Review
主要包含两方面：
Review 工具
管理和跟踪反馈
美术上传工作内容，总监对其进行反馈；美术拿到反馈继续修改，不断迭代，直到效果通过。
这里涉及的有：
Task
Version
Playlist
Note
People
大概的关系是：
影视的几种 Review 形式：
直接日常线上Review，美术/外包随时提交，组长或总监随时反馈，Review 流程超快
rounds，直白翻译叫巡视，走一圈：总监带着PM，走到 Artist的工位上，直接查看其 DCC 内容
正式的 Review 会议，有专业投影仪，标准的色彩显示，有组长、总监、PM，兴许有客户，预先准备好的 Playlist 进行挨个 Review
游戏还会有直接打开游戏，边体验边 Review，我们的反馈方式就要加上录音、录屏、截图。
另外，不得不提一下 Client Review，就是客户，或者是导演、老板、IP方等，在内部已经迭代了不少版，总监觉得已经离定稿不远了，可以拿出来给客户看看。
client Review 的note 需要做隔离，不能直接让相应的美术看到。
一方面，确实有语言翻译的原因，另外，还是需要“翻译”一下客户的反馈，再一方面，需要“过滤”一下客户的反馈。
Review 工具需要具备的功能：
可以写文字描述
有各种画笔功能，可以直接在画面上涂鸦
可以录音、录屏、截图
Ghost and Hold Annotations
Live Review
多版本对比看：并排着对比、叠在一起对比
可以查看历史 Note 反馈
可以切换历史Version 版本
可以切换其他环节的Version 版本
影视：可以看到前后shot，串起来看
......
没有全部功能都有的产品，各个产品有差异、有自己的护城河，我们可以把某一个功能做的特别好的小软件纳入进来，一起使用，然后将它们结果信息同步到我们的 Review系统中。
同样的，该部门的软件或者系统必须支持二次开发，我们 Pipeline 在这个部分的主要精力放在了：
让美术及时看到反馈，可以是发邮件、发即时消息
甚至让美术直接在自己的 DCC 里面看到，把反馈图片贴在场景里
根据新的Note 反馈，自动创建 Task，方便追踪后续是否解决了该反馈
美术可以更方便的上传 Version
批量上传 Version
视频标准化：画面水印、文件分辨率、文件编码、色彩空间、规范命名......
统计：task 有多少个 version、多少个 note，跟task 的bid 比，滞后了还是超前了，反向修正排期，让排期更合理。
增加更多格式支持，比如支持 3d文件预览
同时具备了项目管理和 Review 功能的软件有ShotGrid 、Ftrack。游戏跟影视不同，需要有软件开发的管理部分，这部分如果让诸如 ShotGrid 来管，也不是很合适。所以，可以两个都用，对关键的数据进行实时双向同步。
这时候，肯定有人说，用两个商业系统，那成本多高啊。
这里肯定是忽略了隐形成本，因为觉得贵：
就使用 excel 来管理，带来了协作难题，多版本信息不同步，历史修改丢失，直接影响了生产，这个成本呢？
如果选用了不合适的或者成熟度低的系统，再雇一个TA/TD 来全职开发补齐功能，请问他年包几何，开发能不能按时完成、bug有多少，这个成本呢？
非要 Google Docs/腾讯文档，支持协作，也能高级查询过滤，但公式复杂的逆天，PM 能不能学会、啥时候能学会、要不要直接招个已经会的，这个成本呢？
再次强调那句话，美术资产量不大，确实没必要。
数据管理
有一个我常被问到的问题是：那我的工程文件，是上传到 ShotGrid 里吗？这个问题，简单地回答是或不是，远远不够。所以索性就说个明白。
Data vs metadata
Data ，在我们讨论的上下文中，指的是我们能在硬盘上看到的具体文件，比如.max、.mb、.hip文件.
这些文件有的是二进制文件，可以理解为用记事本打开，里面都是乱码，人根本就看不懂；
有些是非二进制文件，常常是类似xml 、json 、yaml 等，可以理解为用记事本打开，里面都是人类可读的单词符号，偶尔你还能“哟这不是我的节点名字嘛”
metadata ，元数据，是描述数据的数据。
比如说 Data 是你这个活生生的人， metadata 就是你的简历内容，什么身高、体重、身份证号等等，在没看到你这个人站在我面前之前，我通过你的 metadata ，就可以掌握个大概，有时候就能判断出你是不是我要招的人，等我具体想深入了解你的时候，再把你喊过来当年交流。
玩摄影的朋友可能更熟悉，Data 就是你拍的图像文件，metadata是这张照片的 ISO、焦距、光圈、拍摄时的地点、曝光......
在我们讨论的上下文中，一般是这几类：
文件本身的信息：创建时间、修改时间、大小、创建者、存放路径、文件格式
文件内容的信息：面数、有没有UV、有没有骨骼、多少根、在level 里的世界坐标、灯光的亮度、相机的景深
人为添加的信息：“这个文件我增加了地面模型”、“这个版本把角色的腿拉长了一些”
文件的依赖关系：模型文件依赖的贴图文件们、动画 reference了哪个绑定文件、关卡里面放置的资产们
你想记录的其他信息：这个文件的质检结果
一定要根据你们的需要，选择真的要经常查看的 metadata
存放方式
这两种Data，存放方式有所差别。
Data
Data 通常会比较大，毫无疑问，是存放在文件存储系统，比如我们的硬盘、 NAS 、网盘、 P4V 、 SVN 、 Git 等等地方。
Data 文件的存储，在视效行业，基本采用 NAS 。
存储是影视公司的头等大事，它涉及访问速度、写入效率、快照系统、日志系统、权限管理、吞吐量、存储带宽、协议延迟、冷热数据分层、分布式存储等等，总而言之，不是简简单单的找个地方放文件就行了，是个很花钱的工作。
而游戏这边，美术资产分为：
进引擎之前的，就是.max、.fbx、.sd、.spp等等文件。这跟影视的没有任何区别。
进引擎之后的，就是游戏引擎项目工程了。
进引擎之前的文件
我所见过的管理软件有 P4V 、 Git 、 SVN 、Alienbrain 以及，只存放在美术本地硬盘上... ...
就算是使用了上述的存储管理，也并不是每个工程文件版本都上传的，大部分还是项目组强制要求，必须至少传一个最终版，上下游交接的文件倒还是有上传的。
影视公司的理念：Artist 制作的所有文件，都是公司的数字资产，必须 publish 到存储服务器！
当然啦，这是缺少文件夹放置规范和自动化工具，换位思考一下，没有一键无脑上传工具，你让我每个版本都上传，我也觉得很烦。
进引擎之前的文件存储方式，建议使用：
NAS ，推荐指数，五颗星，下面一个段落专门讲一下。
P4V ，推荐指数，三颗星。专门给游戏行业设计的。尤其是，如果引擎工程也使用 P4V 了的话，我不清楚它的收费模式，但从美术角度讲，可以减少一个需要理解的系统。如果有人能说服我游戏公司真的不能用 NAS ，那么 P4V 可以变成四颗星。
云储存 ，推荐指数，一颗星。类似网盘，但不要用网盘！如果你不知道为什么就证明你根本不适合它。对象存储这块，影视有强大的、专业的、专门服务TD 的 IT，都还没敢全换，只敢稍微尝试一下，除非你能找来核心开发者专门来给你服务。
SVN 、 Git ，推荐指数，零颗星。这俩就不是干这个事的！相当于你让一个模型师去设计汽车的发动机，原因是他们都用 Max 来建模。就我上面提到的存储要涉及的功能特性，他们两位能有的寥寥无几。
单独介绍一下 NAS
使用方式：每个美术，把 NAS 服务器映射为统一的一个盘符，比如 x:/ ,相当于美术插了一块“移动”硬盘，跟 D 盘一样。只是这块盘，每个人都有，而且都是同一个。
入门：美术 A 创建了个 x:/aaa/bbb.txt ，美术 B 那里马上也有了 x:/aaa/bbb.txt
高级：美术 A 建了个模型 x:/prop_desk_model_v001.mb ，然后里面引用了几张贴图 x:/prop_desk_normal.tga x:/prop_desk_diffuse.tga ，保存。美术 B 此时打开x:/prop_desk_model_v001.mb，不会有任何问题，全程没有上传下载的步骤。这里只是简单举例，影视并不是这么粗暴使用的，但就是这个理儿。
在上文中提到，不能责怪游戏TA 工具部署那么繁琐，影视的工具、Pipeline系统代码直接部署在NAS 上，把 NAS 上的代码文件更新了，工具就更新了，然后这个文件夹权限锁死，只有自动部署的CI 机器有权限写入，防止美术误删误改。
另外有一点，因为文件都放在了 NAS 上，如果网速够快，美术直接在 NAS 上制作，本地的硬盘就不会被占了，只需扩容 NAS 即可。
对比一下 P4V ，美术制作过程中的文件都在本地，要是跟其他人交换文件，首先需要别人上传，还得把别人的文件下载到他本地，也就是说，同一个文件，出现在了多个硬盘里，不浪费吗？我见过一个项目才是初期，打开美术的资源管理器，一片红彤彤的硬盘空间告警，然后每个人都去再次申请增加个人硬盘，不浪费吗？
P4V 主打的版本管理，在 DCC这里没用，二进制文件merge 不了，就算是非二进制文件也 merge 不了。
你可能说，那我就喜欢我依赖的文件，一直都叫 prop_desk_model，可以自动更新 ，你说的 NAS 存储，它今天叫 prop_desk_model_v0002 ，明天又多出一个新版本叫 prop_desk_model_v0003 ，我还得手动更新呢。
这位客官请留步，首先，谁告诉你 NAS 不能搞文件一直叫 prop_desk_model ，而且永远是最新版。symbolic link 了解一下。
其次，这个更新的确有自动更新，和手动更新两种，但你 P4V 也不是自动更新的呀，也得点一下更新按钮。
最后，我们不使用 symbolic link 是因为掉过坑。美术 B 用了美术 A 的文件，干的好好的，第二天，文件打不开了，经排查，是美术 A 更新的文件导致的。然后有一天美术C 也要用美术 A 的文件，并提出个修改，美术A 修改了，但是美术 B 并不需要这个修改，又悲剧了......
所以，我们最后选择了每个版本都是单独的文件，通过文件名里面带着版本号来进行管理。这个也符合美术的直觉。
Pipeline 系统自动获取是否有新版本，询问美术是否更新，然后美术可以一键更新，美术也可以随时回溯到任意版本，数据隔离美滋滋。
说了这么多，但 NAS 在游戏这边闻所未闻，除了大公司是有一些 IT 安全方面的考量，中小公司我完全不了解。
的确，游戏行业进引擎之前的文件，没有影视整个公司的多，那你 NAS 硬盘可以买少点啊！
难道是因为访问速度？那我们可以在本地硬盘制作，完成后 publish 到 NAS 上啊。
进引擎之后的文件
游戏项目工程，必须必须必须选择一个有版本管理功能的软件，如 P4V 、 SVN 、 Git，这一点大家都没有疑问。
metadata
Matadata 则存在两种方式，以 json 或者 xml 文件形式，一般存放在它要描述的 Data 旁边，看起来可能是这样：
prop_desk_model_v002.max
prop_desk_model_v002.json
另一种方式，则是将 metadata 存入数据库里面。
看你们的实际需求吧。
你非要问我的意见，那我肯定是选择数据库。
为啥不用“存放在文件中”方式呢，当我们要查看、要搜索的时候，比如过滤出模型面数超过2千的武器，这种方式基本就是去递归扫描武器文件夹里面，模型文件旁边的 metadata文件，打开、读取，哎呀不符合，下一个.....资产量稍微上去一点，可能几分钟、十几分钟过去了，突然我觉得，我也不是那么的想知道超过2千面数的武器有哪些了。雪上加霜的是，如果是存放在了 P4V 、 SVN 、Git ，本地都没有下载全部资产，还怎么搜索！
那我就去 P4V 服务器上搜嘛！——你这是把存放文件中的唯一优点也舍弃了。
另外，前文也提到：项目管理系统的数据库要支持一定程度的自定义：可以多增加表；已有的Table 或者新增的Table 可多增加 column。
ShotGrid 和 Ftrack 都支持数据库自定义，一鱼三吃，白得一个数据库！而且 UI、API、账号权限管理...存放在数据库方式的缺点，全解决了，还不用额外花钱！
除此之外可以省去TD 一大部分工作量，还能拿它去当人才库、资产库、材质库、日报管理、Pipeline团队的开发管理、各种工具的后台。
书归正传。还有个问题。
Data 和 metadata 有时候不是那么好区分，尤其是那种整合拼装其他二进制文件的软件 ，同时也不把引用的文件内容封装写入到自己的工程文件里面的，比如 Nuke Studio、Substance Designer 等。还有，游戏引擎的项目工程！
这时候，我们就要发自内心地好好想想，到底哪些数据，是我们不想开 data 文件，就想知道的。
这事做到极致的就是达芬奇软件，它的工程文件就是个数据库！
命名规范
这包含文件命名规范和文件夹规范。具体如何去制定就再说吧......看有没有人愿意看
这里就提一下它的重要性。
规范命名主要的目的是，给资产文件提供一个全局唯一的标识。
当我们提到一个资产的时候，就知道在哪里可以找到对于的文件。
当我们看到文件的名字，就可以确定资产的位置和类型。
有了规范的层级和命名，Pipeline 工具就可以自动化帮你上传下载、导入导出。
metadata 怎么记录
最好是美术使用 Pipeline 工具，在文件被上传/同步到服务器上时，自动提取出来，自动上传到咱们的metadata 数据库里。
额外的也需要用户输入，比如本次文件修改的内容。虽然我过往的经验是，搜集上来的都是“修改了一下”、“1111”这种无效信息。但我们可以在填写的输入框里，自动填充一下模板，引导美术大大们写上合适的内容。
