前言：笔者曾在影视后期Pipeline领域工作多年，后来转至游戏行业并继续从事Pipeline方向的工作。影视Pipeline百花齐放，而且不断在进步，而随着游戏工业化的不断发展，游戏研发当中的Pipeline也越来越受到重视。游戏工业化包含诸多模块，其中美术流程工业化这一点，绝对绕不开，并且也是其中的重要部分。本篇文章主要和大家讨论一下影视Pipeline、游戏Pipeline，以及他们之间的异同点，涉及项目管理和数据管理两方面。文中的内容均是我个人的经历以及朋友们的经历，并不代表整个国内游戏行业。如果你那里的情况不同，非常欢迎你在评论区留言，让大家的信息更加同步，相互学习，共同进步。
我们在工作中会碰到如下问题：
我们把上述的问题，按照相关的工作岗位，聚类一下：
Pipeline 就是来解决上述问题的。
更概括一点说，Pipeline 是管理项目的信息和数据的流动。
· 信息被高效、正确、及时地传达到位
· 数据的来龙去脉、前世今生、脉络关系管理的清清楚楚明明白白
它是谁，它从来哪里，它要到哪里去
非常重要的前言：没有放之四海而皆准的 Pipeline 系统，一定要根据项目的实际情况，只有适合你的 Pipeline才是好的 Pipeline。如果是一个几人的小团队，喊一嗓子就能沟通到位的事情，没必要花时间精力去折腾 Pipeline系统，得不偿失；或者项目的美术资产很少，也确实没必要。
开发和维护 Pipeline 系统的人，在影视行业，叫做 Pipeline TD（Technical Director）。
下面一张图片，展示了一个动画电影的完整制作流程，你能找到 TD 在哪里吗？（友情提示，图超长）
[ 图源：https://www.illuminationmacguff.com ]
可以看到，（Pipeline）TD 们都是在小房间之外（不参与内容制作）走动，负责监控和维护，保障整个管道正常运行的人。
继续我们的话题，本文我们从刚开始提到的三个岗位的工作内容角度，将 Pipeline 要管理的范畴，分为三大类：
· 项目管理
· Review
· 资产管理（文件和 Metadata 的管理）
这三者并不是隔离的，而是紧密结合在一起的，之间的数据和信息流动是要丝滑的、无缝的。
其实 Review 是包含在了项目管理中的 ，但在游戏过程中，由于大家经常忽视 Review 这一块的重要性，所以我就把它单独拎出来。
按照影视的说法，就是分 Production Management 和 Asset Management。
项目管理
我们这里不涉及项目管理模式，如Agile、Waterflow。
这里的内容主要包含：
· 任务分配、排期
· 任务的上下游关联
· 任务的资产关联
· 跟踪资产完成度、发行版本、项目进度等
这里涉及到的数据类型：
· Project（最顶层的，游戏项目、电影项目，或者因为某些原因拆分出来“子”项目）
· Phase（或者叫Sprint，指一段时间，加很多个 milestone，用来做阶段性排期，比如游戏要上线的6.0 版本等）
· Asset（包括影视的 Sequence/Shot、游戏的美术资产、关卡等）
· Task（将 Asset的制作拆分出来的最小级别的、可以分配到具体人的任务，并且有期望起止时间和预计时长）
· People（可以是个具体的美术人员，也可以是外包公司）
· TimeLog（记录每个 Task 的制作实际制作时长，用来衡量工作效率或者是任务预算是否合适）
大概的关系是：
上述涉及到的内容，最好有甘特图来协助查看和便捷编辑。
另外要有多样的 filter，协助项目每个人查看他感兴趣的部分，比如：
· 列出所有动画任务
· 列出所有两周内要过期的任务
· 列出包含在xxx版本要上线的任务
该系统必须可以应对变化，大到比如外部环境变化导致的延期、比如老板突然要调整游戏上线日期，小到人员离职，多增加美术、多外包、系统可以快速调整和更新排期，确保每个人都知道自己该做什么、该什么时候做、先做哪个后做哪个。
具有项目管理功能的软件/系统有很多，影视或游戏行业在这方面的基础需求也没有太多的特性，强烈建议直接使用一个用户量多的、适合你项目体量的商业系统就行，前提是这个系统必须支持二次开发，因为只满足基本需要可远远不够，按照之前的经验，我们 Pipeline 在这个部分的主要精力放在了
· 将生产数据进行各种角度的可视化，帮助PM 精细化管理项目周期和人力安排，把控项目风险，避免空转/过载
· 开发各种自动化监听脚本，比如当A任务完成80%就把 B任务状态改为“可以开始”，减少 PM 手动、重复工作量，减少人为出错
· 开发各种RTX通知机器人，比如提醒美术临期任务。及时提醒，避免遗漏
· 开发各种小工具，包括并不限于浏览器插件、基于管理系统的菜单拓展等，减少PM 操作步骤
· 生成产能报告，展示进度、落后的部分、资源闲置等等状况
另外，提到它必须提供二次开发接口，还因为这里的信息，是要出现在美术的工作环境中的，比如DCC、引擎里的（第三部分）
再次，还需要强调的是，该系统的数据库支持一定程度的自定义：可以多增加表（Table）；已有的Table 或者新增的Table 可多增加 Column。
随着项目越来越复杂，需求量增多，Pipeline 岗位再次被细分，甚至前几年国内都有公司招聘制片TD（在游戏可以理解为配给APM 的TA）。在我查找小黄人那张图片的时候，看到做小黄人的 Illumination 公司竟然也有招 Production Technical Director。
Review
主要包含两方面：
· Review 工具（如何更好地Review）
· 管理和跟踪反馈
美术上传工作内容，总监对其进行反馈；美术拿到反馈继续修改，不断迭代，直到效果通过。
这里涉及的有：
· Task（上个部分中的Task）
· Version（内容一般是图片或视频，美术的一次迭代）
· Playlist（将多个 Version 放在一起的播放列表，方便开 Review 会议时查看）
· Note（反馈，一般有文字描述、示意图片、或者其他文件作为附件）
· People（这里指上传 Version的美术/外包公司，和负责 Review 的组长或总监）
大概的关系是：
影视的几种 Review 形式：
· 直接日常线上Review，美术/外包随时提交，组长或总监随时反馈，Review 流程超快
· rounds，直白翻译叫巡视，走一圈：总监带着PM，走到 Artist的工位上，直接查看其 DCC 内容
· 正式的 Review 会议，有专业投影仪，标准的色彩显示，有组长、总监、PM，兴许有客户，预先准备好的 Playlist 进行挨个 Review
游戏还会有直接打开游戏，边体验边 Review，我们的反馈方式就要加上录音、录屏、截图。
另外，不得不提一下 Client Review，就是客户，或者是导演、老板、IP方等，在内部已经迭代了不少版，总监觉得已经离定稿不远了，可以拿出来给客户看看。
client Review 的note 需要做隔离，不能直接让相应的美术看到。
一方面，确实有语言翻译的原因，另外，还是需要“翻译”一下客户的反馈，再一方面，需要“过滤”一下客户的反馈。
Review 工具需要具备的功能
· 可以写文字描述
· 有各种画笔功能，可以直接在画面上涂鸦
· 可以录音、录屏、截图
· Ghost and Hold Annotations（可以把视频其他帧画面的涂鸦半透明显示，适合动画环节 Review）
· Live Review （多人在线协作 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 上的代码文件更新了，工具就更新了（ps：工具里不要长时间 open一个代码里面的文件，不close），然后这个文件夹权限锁死，只有自动部署的CI 机器有权限写入，防止美术误删误改。
另外有一点，因为文件都放在了 NAS 上，如果网速够快，美术直接在 NAS 上制作，本地的硬盘就不会被占了，只需扩容 NAS 即可。
对比一下 P4V ，美术制作过程中的文件都在本地，要是跟其他人交换文件，首先需要别人上传（这个上传过程可不简单），还得把别人的文件下载到他本地，也就是说，同一个文件，出现在了多个硬盘里，不浪费吗？我见过一个项目才是初期，打开美术的资源管理器，一片红彤彤的硬盘空间告警，然后每个人都去再次申请增加个人硬盘，不浪费吗？
P4V 主打的版本管理，在 DCC这里没用，二进制文件merge 不了，就算是非二进制文件也 merge 不了。（你让美术去解决两个sd文件的冲突？美术打爆你的狗头！）
你可能说，那我就喜欢我依赖的文件，一直都叫 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 或者新增的Table 可多增加 column。
ShotGrid 和 Ftrack 都支持数据库自定义（可能程度不一样），一鱼三吃，白得一个数据库！而且 UI、API、账号权限管理...存放在数据库方式的缺点，全解决了，还不用额外花钱！
除此之外可以省去TD 一大部分工作量，还能拿它去当人才库、资产库、材质库、日报管理、Pipeline团队的开发管理、各种工具的后台。
书归正传。还有个问题。
Data 和 Metadata 有时候不是那么好区分，尤其是那种整合拼装其他二进制文件的软件 ，同时也不把引用的文件内容封装写入到自己的工程文件里面的，比如 Nuke Studio、Substance Designer 等。还有，游戏引擎的项目工程！
这时候，我们就要发自内心地好好想想，到底哪些数据，是我们不想开 data 文件，就想知道的。
这事做到极致的就是达芬奇软件（DaVinci Resolve），它的工程文件就是个数据库！
命名规范
这包含文件命名规范和文件夹规范。具体如何去制定就再说吧......看有没有人愿意看
这里就提一下它的重要性。
规范命名主要的目的是，给资产文件提供一个全局唯一的标识。
· 当我们提到一个资产的时候，就知道在哪里可以找到对于的文件。
· 当我们看到文件的名字，就可以确定资产的位置和类型。
· 有了规范的层级和命名，Pipeline 工具就可以自动化帮你上传下载、导入导出。
Metadata 怎么记录
最好是美术使用 Pipeline 工具，在文件被上传/同步到服务器上时，自动提取出来，自动上传到咱们的Metadata 数据库里。
额外的也需要用户输入，比如本次文件修改的内容。虽然我过往的经验是，搜集上来的都是“修改了一下”、“1111”这种无效信息。但我们可以在填写的输入框里，自动填充一下模板，引导美术大大们写上合适的内容。
文/Gandalf Mu
来源：腾讯游戏学堂
原文：https://mp.weixin.qq.com/s/lM5aV8K5t1QWW5j085dnKw
| 
发表于 2022-7-19 11:06:28
