主页 > 折纸

动画电影《白蛇:缘起》背后的CG渲染

时间:2019-07-28 来源:美食家阿秀

点击上方蓝字CG世界 关注CG我们

“ 感知CG · 感触创意 · 感受艺术 · 感悟心灵 ”

中国极具影响力CG领域自媒体


文章已获授权

转自公众号“渲染方程”




动画电影《白蛇:缘起》已经上映了,相信很多喜欢国漫的小伙伴已经看过了,今天小的(TD)就来给各位官人扒一扒这部电影的CG渲染相关的事情吧。#请随意转发和转载#




相信熟悉追光动画的小伙伴应该知道,追光动画的灯光渲染流程是基于Arnold和Katana。这回就单说这个渲染吧。


从《白蛇:缘起》开始,追光动画开始使用新的Arnold5.x作为渲染内核。我想我们应该是第一家将新的Arnold用在电影级别的项目渲染上,为什么?因为我们几乎遇到所有类型的渲染问题。我们反馈的bug数量在Solid Angle的2017年终总结中排名第二,第一名的那位大兄弟是他们自己的开发者



关于渲染质量



在电影《白蛇:缘起》中,为了达到电影级的质量,我们的光线追踪采样达到了3168~3312(camera aa = 12)。看过电影的朋友应该对最后决战的场景记忆犹新,那些场次充斥着大量的特效和冰霜元素。很多镜头的渲染时间达到惊人的4000核小时(机器核心数*渲染小时数),甚至更多。之前皮克斯的《寻梦环游记》的渲染中,皮克斯透露他们电影中的亡灵镇的渲染时间差不多是300机时左右,其实,电影质量的渲染,哪一个不是拿金钱和时间烧出来。



Arnold的优点是渲染硬表面材质,因为它是一款单向光线追踪的渲染器,这意味着在Arnold的世界里,灯光是没有形状的,无法模拟焦散,也不擅长计算折射。Arnold的折射运算和SSS(次表面)运算都不是严格按照物理模型去做的,为了提升渲染时间都做过很大的优化。但是纵使这样,它依旧是世界上最好的两款渲染器之一,它的最大的优势在于它的采样模型和它的内部BRDF(双向反射分布)的实现方式,都具有整个行业非常领先的地位和优势,即使是RenderMan也比不了。


因为使用Arnold 5,我们的渲染时间其实优化了很多,单就着色时间(shading time)来比较,我们比之前的渲染内核效率要提升很多。



关于渲染内核



从第一版的Arnold 5内核到最终使用在项目中的稳定版本,我们迭代了至少7次。总结起来渲染问题主要有三类:运动模糊不匹配,内存溢出,渲染崩溃



运动模糊不匹配



新版Arnold配置进项目不久,在某一个风和日丽的下午,Jerry(老大)问我 :" 你说Arnold 5刚放出不久,会不会又什么问题 ",我拍了拍老大的肩膀 :" 嗨,我都测过了,你还不放心我咋得 ",话音未落,角色特效部门的小伙伴就呼哧呼哧的来到了TD部门,从他脸上凝重的表情就看出来,出事了。Jerry看了我一眼,我尴尬的杵在了那里。所有的项目中的角色毛发和角色模型,运动模糊都没有没有匹配上



为什么CG动画需要渲染运动模糊呢?用大白话说:因为你的处理器性能不够么!人眼一秒中处理24张高精度的图像,眼神的焦点处图像变化太大,大脑哪里还处理的过来嘛。所以运动的物体会让它模糊一点,大脑处理时也能迷迷糊糊的糊弄过去,这样你的脑壳就不会感到晕了嘛。


为什么不后期合成呢?拜托,说好的用心做动画,后期合成的运动模糊和渲染的运动模糊完全不能比嘛。


几乎每一个追光的灯光TD的被运动模糊不匹配的魔咒困扰过。当时我们测试了所有毛发资产,有将模型的小数帧的cache一点点的匹配,依旧找不到问题出在哪儿,持续了一周的时间,在心力憔悴几度昏觉的情况下,我联系上了Mike Farnsworth(Tecla), 这个老哥是KtoA(Katana to Arnold)的开发者,当时将情况和他说了,他立马就开始重新review KtoA的代码,那时我这边是晚上10点,等到深夜3点多的时候,收到了Mike的邮件:



那一刻,我真的想亲他一口,亲完又想打他,虽然这是TMD全是他自己的写的Bug啊。后来他给我传了一份临时的hotfix版,那一晚的后半夜,睡的特别香


总结原因:

因为我们的灯光渲染流程在Katana中,而资产制作在Maya和Houdini中。在跨平台的数字资产交换中,很容易出现属性数据丢失的情况,毛发和模型本身就是两套缓存(Cache),很容易造成数据不匹配的情况。


决处方:

1.第一时间和开发者沟通;

2.尝试匹配不同软件之间的属性数据,比如从Maya中导出场景ASS(Arnold Scene Source)和Katana中导出的ASS数据对比;

3.导出数据缓存时,注意数据的字节长度,如果模型离原点过远时,缓存的数据可能是个32位double值,但却只能保存成16位float值。



内存溢出



又是一个风和日丽的下午,Jerry(老大)又问我 :" 渲染器不会再出什么篓子了吧 ",我蹭的站了起来,一拍胸膛:"再不会有啥问题了,我你还不放心吗",话音未落,PLT(植被)组的TD叫了起来 :" 电脑内存炸了,整场的植被都炸了 "。Jerry看了我一眼,我默默的坐下了。在Arnold 5的早期版本,存在很严重的内存溢出现象。



追光有自己的一套基于XGEN的植被的工具和流程,经过了三个项目的洗礼之后已经非常的成熟了。但是在Arnold 5的渲染中,一个1G左右包含XGEN的场景,可能内存占用会超过80G,这在早期的测试中并没有发现,因为早期的测试资产量级非常小,等到真正镜头制作中才会表现出来。后来向官方反馈了。


总结原因:Arnold 5移除了"deferred procedurals",所以在渲染时会将xgen procedural单体全部递归式的展开,然后跟据procudural的ID进行instance,设置不同的位移属性铺满整个场景。


解决处方:向官方反馈之后,在两个内核版本后面(5.0.2.1)修复了。



渲染崩溃





还是一个风和日丽的下午,Jerry(老大)再次问起 :" 哎,我说... ",我立马打断他 :" 肯定没问题了这回,你就这么不放心我吗",话音未落,灯光组某些特定的场次出现各种诡异的农场渲染崩溃。这回我真的哇的一声哭了出来。渲染崩溃的事情大家都喜闻乐见,Arnold 5也并没有好到哪里去(但比RenderMan强点)。


到底是啥导致的渲染崩溃呢?就我本身对Arnold和Prman的使用经验来看,我觉的主要问题就出在多线程渲染上了。


渲染开始前的准备阶段,渲染器会做这些事情:


1.翻译转换procedural(程序化)节点

2.展开instance节点

3.遍历场景,找到所有Shape节点

4.找到Shape节点中的所有灯光节点


这前两步是非常容易导致渲染崩溃的,为什么?


我们设想,现在有12个线程在同时执行第一步和第二步,而第一步和第二步直接又是相互依赖的。多线程编程,是不太方便使用动态列表,如vector之类的,需要使用Map或者List这类,因为它们提前申明了数据结构内存占用的大小的,这样多个线程并行计算时,你同时往一个数据结构的指针中写数据,就不会内存冲突。内存申明了就得释放吧,出来混总是要还的嘛,这一借一还,就很容易出错了,尤其是procedural节点大多是第三方开发的,这下就更乱了。


总结原因多线程渲染内存冲突

解决处方可以将Arnold的多线程生成场景(parallel_node_init)的渲染选项关闭,将场景翻译线程数(translationThreads)设置为"1",注意这会拖慢渲染速度,但是很有可能解决你的渲染内存冲突导致的崩溃问题。


项目做完了,回头看着Jerry头上的头发少了一大把,我内心无比的愧疚...



关于资产和着色器



从Arnold 5开始,深受大家喜爱的alShaders不再更新了,我是从alShaders的开发者论坛看到了大神Anders Langlands(anderslanglands)给大家发的群邮件,那个时候他刚结完婚,而且也刚从MPC跳槽到Weta,没有时间继续更新,但是最重要的是,Arnold 5几乎涵盖了所有alShaders的功能,可能AL也觉得再维护下去意义不大吧。下图为alShaders的实现:



对于我们CG制作公司来说,就很头疼了,我们之前的数字资产大量使用alShaders,并且材质(Surface)部门对这个材质球的各种属性的艺术表现也是聊熟于心,我们不得不花大量的时间是探索新的通用材质球的各种效果。


幸运的是,Arnold 5给我提供了一个超级强大的工具:OSL(Open Shading Language)。这是一个由Sony Imageworks开发维护并且开源的shading语言。主流的渲染器都在渐渐拥护支持。



了解详情的看这里:

https://github.com/imageworks/OpenShadingLanguage


总之,我们在Arnold 4到Arnold 5的资产的Look转换中,使用了大量的OSL着色器,在整个《白蛇:缘起》的项目中,也是大量的使用OSL的着色器。OSL最大的好处就是它和Python一样,跨平台、跨软件、易于开发和维护。加上丰富完整的API,写起着色器如同砍瓜切菜一般呢。



从Arnold 5开始,Arnold深度集成了OSL的内核,所有BRDF都包裹成closure,这样做最大的好处就是可以使用LPE(Light Path Expressions)灯光路径表达式,可以在输出场景中任意的灯光bounce,比如镜子反射中的金属球的高光中的某个物体上高光里的自发光,有点像绕口令,头晕的看上图。


在《白蛇:缘起》中,我们使用LPE实现了逐灯合成(Pre Light Compositing),在NUKE里直接调节每个灯光的颜色和曝光,再结合新的Cryptomatte,实现了最大限度的后期控制。



写在最后




    

CG动画制作不易,磕磕绊绊,甜苦参半,有很多你想做,但又不得不不做的事。你觉得可以更完美,但是时间和预算让你不得不妥协。我个人是留有遗憾的,希望还有更多的机会去弥补这些。


希望每一份坚持都值得,希望每一坨梦想都可以被看到


骄傲的Miyazaki

2019年 1月 11日




想要了解更多CG专业知识

可以到CG世界Pro溜一圈哇

扫描二维码即可穿越