《CF穿越火线》引擎动画案例分享（上）

作者：弓振涛 Unity官方平台 2019-06-25

本文将分享喜悦娱乐副总经理兼技术总监弓振涛在Unite 2019上的技术分享：《CF穿越火线》引擎动画案例。

受篇幅限制，本次演讲将分享二篇内容。本文将分享：在制作动画的过程中人和资产的调度，以及并行分工和分级审核二个案例。


演讲内容

大家好，我是来自喜悦娱乐的弓振涛，很开心和大家分享我们使用Unity制作影视动画的案例。

去年我在Unite大会的内容分享更多是偏技术型的，例如：一个内容创作型的公司如何使用Unity引擎，怎么制作漫画、互动小说、游戏、影视剧以及电影中的特效。后来很多行业的朋友问我是怎么做的？怎么实现的？其实最早对于这个问题，我们最早也是自己问自己。

从2016年，我们看到从《ADAM》和《死者之书》，这些Unity官方制作的作品，我们都非常的兴奋。我们就是想能不能有这样完整的工程，让我们研究一下每个具体的细节怎么做的。

过去一年的时间中，我们更多的是在趟一些坑，所以形成了一些经验来分享给大家，希望大家少走一些弯路。


本次分享的角度分二个方面：

第一个是人的角度，作为导演、建模师、动画师、特效师等，如何和引擎对接。因为动画制作团队有上百人，你不可能让每个人深度学技术，告诉他们怎么做，因为很多观念性流程已经根深蒂固了，人的角度实际是我们的一个工作流程。

第二个从资产的调度，我们制作一个影视动画工程，Unity工程结构怎么进行设计？DCC工具制作的数字资产怎么分布？包括一些技术规范，最重要的是Timeline结构怎么设计，我们看过很多Timeline的一些案例，但实际上当你去做动画番剧，一个成片的时候，很多的细节跟我们做游戏过场动画的差别非常大。

具体的三个坑是：并行分工、分级审核和迭代整合。


首先我要解释：升级到引擎动画并不是说对传统Maya动画的代替。

Unity是一个非常高效的渲染引擎，它有自己的优势，渲染得非常快。怎么拿Unity改造传统Maya动画的生产环节，这是我们的一个重点，而不是说去革传统Maya动画的命，去代替它。

首先是可能性，当我们看到Unity官方推出《ADAM》、《死者之书》、《异教徒》等一系列作品的时候，我们非常的兴奋，这是从0到1的转变。说起Unity这个引擎，大家觉得Unity游戏引擎等于制作游戏。当它面向一些工业、影视、医疗、汽车等行业设计的时候，我们突然发现是可以做这些工作的。

这些作品非常优秀，但这些作品有一个问题：这些作品是Unity官方制作的，工程本身有高度定制化的内容，从渲染器到一些插件的使用。那么怎么让这种可能性变成一种可行性？


后来Unity官方又推出一系列的工具，包括：Timeline、Post Processing Stack、HDRP高清晰渲染管线，随着这一步步的措施，让非官方的团队有机会使用Unity去制作动画。


为什么我们选择Unity引擎？其实非常简单。首先Unity的效果好，渲染快。渲染快让我们不用去农场渲染，不必离线渲染，节省了非常多的时间。基本上在渲染成本中，平均下来可能占到三分之一甚至更多的成本。

最重要的是修改快，因为它基本上是实时的，不管是导演的一些需求，或者是平台的需求，可以反复的修改产品。我们可能进行了非常好的成本控制。

例如：一个二万一分钟的片子，可能修改成本就三万，但是制作团队在等待着，他们需要去修改。修改完之后再拿到云上面渲染，渲染完之后再看是不是这样的效果，于是渲染成本就变成了五万六万，这对一个做商业项目的公司而言成本是非常昂贵的。

我们在画面效果以及成本制作周期，尤其每周交片，周播番剧的时候，我们需要寻找一个相对平衡的点来制作我们的动画番剧。

下面是我们跟腾讯合作的《CF穿越火线》番剧的截图，这个番剧会在今年的暑期档上线在腾讯视频平台。


其实这部片子在制作的时候，我们也用到了一些比较新的，传统动画领域较少涉及的技术，例如：动作捕捉，表情捕捉等技术，但这不是今天介绍的重点，这些技术比较常见了。重点是一个上百人的动画团队怎么跟Unity结合，把我们的流程和引擎对接。

当我们的项目落地制作的时候，其实全都是套路，没有人去教我们。


大家看过《死者之书》和《异教徒》，都是非常酷炫的成片。在Timeline里，随着Timeline里时间轴线的拖动，看到每个资产、每个效果、甚至每个后期效果的变化。

量变是会引起质变的。当我们制作一个15～20分钟一集的番剧，镜头数可能在200～300之间。像CF这种动作偏多的，它的镜头数可能在400以上。对于这么多的镜头数所对应的资产，不管是角色、场景、特效等，当资产量达到一个程度的时候，一定会引起质变，会有一个个Bug，各种问题出来。

对于一次成片，可能我们过去看的片子都是单场景，场景不是特别的多。即使场景优化得再好，在一次成片加载一定会有效率的问题，包括镜头数不多，那么你对应数字资产的量也没有那么多。


对于Unity中很多二进制文件，我们无法去同时编辑，这个其实非常头疼，因为传统动画团队里已经分好了动画、特效、角色等各个团队。我想绑定的时候，发现角色还没有好，怎么办？或者我希望在场景中做一些灯光的时候，场景还没有做好。

对于二进制文件，我们怎么处理？包括对于Unity工程，我们不是做一个游戏项目，我们现在是一个动画项目的时候，这个工程结构怎么跟传统的工作流程结合，或者说非常根深蒂固的一种思维，和各个角色的人员，这里指的人员是导演、动画师等等，组织结构、担任各个工作的人员，怎么去调整？


首先第一个案例，并行分工。

从人的角度，我们当然希望所有人并行做这个事情，不可能串行的在等，从而提高我们的效率。

在制作过程中，一般导演都会去使用一些三维软件，甚至使用Maya自己去K镜头。我们希望导演使用Cinemachine能去做一些镜头，接触一些引擎中的东西。


有些镜头用Cinemachine去做会非常好，例如一个子弹发射出去之后，我希望镜头跟着子弹走，这时候根本不需要去K动画，只需要把Cinemachine中的Target绑到子弹上，随着就可以出去，而且这个效果非常的平滑。

Cinemachine不是万能的，当我们不能用它实现的时候，我们会使用Maya制作一些镜头上的资源。我会对执行导演要求更高一点，你需要会拿Timeline去做我们的白模Layout，因为这个可能是除创作层的，真正开始做资产的起点。从分镜开始，导演全程就要与其他的角色并行分工。


影视的模型师，和游戏中的模型是不大一样，游戏里面做模型对效率没那么高的要求，可以放开很多的细节。

影视的模型师，制作完高模后，体型和关节点确定后，绑定师就可以进行绑定了。绑定师已经介入了，就不可能再等待。拓扑好低模后，分好UV，材质师可以介入了。

材质师需要关心贴图，例如ID贴图，怎么去区分？怎么去制作材质？而且材质是跟引擎相关的，不可能使用传统的DCC工具制作好，再导入进来。那么成品之后，特效师可能要进行布料的模拟，在Houdini或在Unity中做各种解算。


地编师也是一个对游戏常见的职业，导演在白模Layout之后，地编师就可以搭建初版场景。

当动画进来后，我们可以根据摄像机的动画去观察，哪些镜头会暴露一些细节，需要修改一些场景中的细节，例如这个建筑离我很近，有一个大特写，那就要把它制作得非常精致。

在制作后期特效时，地编师可能会根据需求分层输出序列帧。


对于我们所有的项目角色，他们在动画的前期，中期和后期一定是并行工作的，每个人有自己介入的时间，根据项目不同而不一样。

至少下图标橘黄红色的部分，他们一定会在引擎中工作。即使是没标的模型师和动画师，我们也要求他们制作的动画资产，像FBX格式也要放到引擎中，在FBX Exporter中按照美术技术规范做一些检测。


这个时候，我们怎么解决这些角色并行工作的问题？

首先想到一个词就是游戏，毕竟很多人接触Unity就是从游戏开始的，我之前也是做游戏的。游戏里面有UI，我们会把UI打包各种场景，主界面的UI或副本的UI等。

当使用这些UI的时候，我们会加载这些UI场景，包括我们加载地图的时候，可能会放一个Loading图，甚至我们想到了Loading的这些接口。

此时，自然而然引出了Unity场景的概念，就是我们在Hierarchy层级窗口看到的一系列游戏对象打包的概念。

这个场景不要理解成一般办公室，会场之类场景，其实在Unity里面，一系列对象只要以某种组织关系打包在一起的结构，都可以称为Unity场景。Unity支持多场景同时加载的，这是解决大家并行分工最核心的东西。


上图中的示例，第一集的时候，在港口拍摄的场景，我可能把整个场景拆分得非常的细。

如下图所示，我们会拆分Timeline类型的场景。它的功能就是嵌套导演，组长以及组员三个级别的Timeline，这是我们整合出片的场景。红框的部分是我们导演Timeline的场景，底下蓝色的预制件是组长已经做好的时间轴的Timeline。


当然也有灯光师的场景。下图红框部分可以看到有四个场景，这是因为像周播的动画番剧，不可能等一个人做完再继续，所以我们会安排能力强的做主拍摄场景的灯光，但是会把其它不同区域拆分开来，给不同的灯光师制作，最后同时加载，这是非常简单的思路，也是多场景加载的思路。


对于地编也一样处理，我们会把它进行一个拆分，后面我们会说拆分的技巧。

当我们传统团队做这些事的时候，可能不一定能理解这回事，他会觉得我做一个单体模型交给组长就完了，为什么这么拆？


对于我们的视觉特效，当然也有单独的视效师的场景。


关于环境场景，在多场景加载的时候，在Unity中你激活哪个场景，就把它Set active了，那么整个多场景加载的环境会显示以它的标准。

例如，使用3D模块创建场景的时候，我们使用天空盒。当这个场景中，加载想要的内容，例如落日黄昏的天空盒，你把它Active了，整个场景就以它为主。

如果是我们创建的HDRP的版本工程，我们会在场景中创建Scene Setting。我们在这里可以进行一些雾效的设置，天空的设置。通过这个设置，你把这个放在激活的场景里，全局的多场景加载也会以此为准。


Base场景是技术美术和程序关心的，已经有很多的脚本。


这个时候其实所看到的是，因为导演要审批片子，所以需要看到时间轴上各个资产是怎么调度的，简单来说播放起来是什么样子的。这里会有灯光，动画和角色等，当然导演有修改权限的也只是有Timeline的场景。

灯光师也一样，并不关心其他的资产怎么样，也不可能把几百G大的工程在本地进行处理。所以灯光师只需要下载几个相对关心的场景就可以了。灯光师的修改权限也只在Light灯光这个场景里面。

同样的，地编师的修改权限也在Static里面。


当然这里也会有问题，当我们拿到拍摄表的时候，灯光师知道要加载Static、Light、Enviroment等，但是对于每个拍摄场地，不可能会记得那么清楚，也不可能像传统画一张表不停找这些拍摄通告。

其实，项目中的数字管理员可以做一些效率工具，帮助大家组织结构。因为作为不同角色的人，他们基本的需求就是只要入口就行了，打开入口就是工作环境，是否符合美术技术规范。这个时候把相应的场景加载进来，我们可能有不同的入口，从这个入口进去做自己的事情就可以了。


下图是古镇枪战的俯视图，这里我分享一下大概的拆分技巧，虽然我们制作影视不是特别考虑效率，但是还是要考虑的。


下图红框是主街道的区域，也是主拍摄的场景。可能制作的时候，我会安排能力最强的人，安排他们制作最精细的部分。而后面二排建筑物则可能找普通能力的人，甚至一些外包的供应商来完成。

对于白天拍摄场景的时候，因为已经拆分主街道和后排的房屋二个场景，那么白天的时候二个场景都加载，因为Timeline的加载还是要费一些效率的。但是到晚上的时候，第二排场景就不需要加载了，这是一种简单的拆分策略。


如下图所示，主要的拍摄场景在红框的地方，那么在黄框的地方可能类似于做LOD一样，这个地方的场景模型不用那么高的精度，红框可能使用SD或者次时代的工具Substance Painter做很漂亮的材质，后面这些可能用普通的材质就可以。

类似更远的地方，因为镜头可能会处理一些景深的效果，可能在后面就虚掉了。


我刚才提到了场景是抽象的包括一系列游戏对象的概念，在这个场景里面，战斗前和战斗后也是有差别的。

战斗后的话场景中有些房屋可能成为了残垣断壁，道路上有很多碎片，碎屑。下图红框部分可能是造成的一些破碎，有一些污渍的地方。我们可以一样把它打包成一个场景，交给一个人制作。

我们的目的就是把这个场景尽可能快的在周播剧所规定的时间内，把资源给消耗掉。


第二个案例是分级审核，这是从传统的方向来导向的。

如下图所展示的三级概念。组员是自己的团队或者一些供应商外包，他们会按照美术规范制作各种资产。制作好的资产会提交给组长审核，审核通过了放进Maya工程里面。最后导演审片，然后去渲染。


例如，动画师的数量在制作团队中几十人很正常，多的时候七八十人，如果算上外包可能会更多。动画的组长向导演去负责，同样你的团队中还有其他的角色存在。

下图非常清晰的看到三级的审核资源，一个制作的制度。这种流程对于制作传统动画，在想法里面非常的根深蒂固，我们怎么让引擎对应这个，不去改变太多想法呢？


当我们想介绍新的事物时候，不要试图一下子推翻老的，我们要让成员一步步接受，让他知道这个东西渲染得非常快，修改得非常快。

我们让导演去尝试，然后制作的资源也会发现，原来这样去制作也可以提升效率。这样就容易让制作团队去接受。

如下图所示，这是对应的三级结构，我们设计了祖、父、子三级结构。导演的工作环境是祖Timeline，组长是父Timeline，然后组员是子Timeline。


组员的子Timeline非常简单。例如，我是组员，分配六号镜头，镜头有什么样的摄像机动画，什么样的角色，包括特效，音效等，我可以通过各种轨道把它组织在一起，做好我的镜头。

下图右边的层级窗口橘红色线框部分，这是组长的工作环境或者场景。下面每一个小红框就是一个镜头，我分的是6号镜头，8号镜头，另一个人分了7号镜头。当我们制作好这些资产的时候，进行检查并使用规定的格式提交。


下图是组长的Timeline窗口，他会看到这样的状态。这个层级还是刚才组长的窗口，红框是组长的父Timeline。我们发现，组员制作的内容都在这里看得到。

每天可能更新SVN或工程时，我们可能发现不停的资源向里面汇集，那么作为一个镜头组长，审镜头的时候，可以非常简单而快速。


当需要向上一级，祖Timeline提交的时候，导演其实不需要看到非常零碎的镜头，我们可以进入Unity预制体更新的机制，作为预制体提交给他，导演可以非常方便看到变化。

下图是导演的组Timeline，他会看到，这是角色组长提交的角色Timeline，还有后期的Post Processing Stack，灯光，下图右边的层级窗口，红框部分就是导演的Timeline。


前面所说的每个Timeline都可以通过正常方式创建，也可以增加一个Playable的脚本。

例如：上图蓝框框的是角色动画的组长提交的预制体，它会依次播放镜头中所有的角色动画，右边这个镜头指的名字为Episode00_Port_Timeline_Character，这是角色组长的一个工作环境，也就是他的Unity场景。同样对于灯光，这是灯光组长的工作环境。

小结

在本篇中，弓振涛分享了在制作《CF穿越火线》时人和资产的调度，以及分并行分工和分级审核二个案例。我们在下一篇中，将分享第三个案例－迭代整合和使用引擎做动画时的一些误区，敬请期待。

更多Unite大会精彩演讲内容分享，尽在Unity Connect平台(Connect.unity.com)。

作者：弓振涛  
来源：Unity官方平台
原地址：https://mp.weixin.qq.com/s/GOA5RWKvMBdwcqvg68lIVQ

参与评论