以下文章来源于腾讯游戏学堂 ,作者gandalf mu
笔者曾在影视后期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”这种无效信息。但我们可以在填写的输入框里,自动填充一下模板,引导美术大大们写上合适的内容。
凯发体育官方app的版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。