动画电影《白蛇:缘起》已经上映了，相信很多喜欢国漫的小伙伴已经看过了，今天就来给各位官人扒一扒这部电影的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的邮件：
那一刻，我真的想亲他一口，亲完又想打他，虽然这是全是他自己的写的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动画制作不易，磕磕绊绊，甜苦参半，有很多你想做，但又不得不不做的事。你觉得可以更完美，但是时间和预算让你不得不妥协。我个人是留有遗憾的，希望还有更多的机会去弥补这些。
希望每一份坚持都值得，希望每一坨梦想都可以被看到。