技术干货！如何优化大场景，提高渲染速度？

今天跟大家分享一篇技术干货。

作者是Arthur，本名赵鹏。

在CG行业已经工作9年，从事开发工作。

近几年来，随着电影特效的飞速发展和电脑硬件的提升，电影制作的场面是越来越宏大，随之而来的就是如何有效的管理和优化巨量的场景，因此也诞生了不少专门解决此类问题的软件。比如像Katana和Clarisse等等。而主流的三维制作软件，诸如Maya, C4D，Houdini等都有着自己的场景技术， 这里我们主要来浅谈下Maya内，相关的场景优化技术。因为大部分国内公司主流的制作平台还是以Maya为主，并且不是任何一家公司都有能力去消费如Katana和Clarisse这类商业的软件（盗版用户可以直接忽视掉一切），而且在流程和成本上，跨越多个软件带来的流程过于繁杂，可能需要花费更多的时间整理一套传递工具，这又需要TD的支持，并且又得购买更多的商业软件来满足项目运行。这些都是成本问题，相信各家制作公司自有体会，好了废话不说，我们直接进入主题。

在谈及场景优化的重要性之前，我们需要解决一个观念问题。即，是否需要优化。这是很多制作者常常有的疑问，尤其是越涉及到具体镜头的三维环节时才有比较大的认识，像资产环节部门，比如模型，绑定，前期等，基本对场景优化没有任何概念，希望看了这篇文章后，能改变下这些环节制作人员的概念。场景是否需要优化，主要还得看项目，按电影项目来说，这基本是一个不可逃避的技术。相信很多灯光制作人员会为了打开一个场景苦苦等待半天。好不容易打开之后，没操作几分钟就报错error，直接crash掉，是不是很无语。还有一种情况，场景打开了，制作好灯光后，再点击渲染慢慢等待渲染视图出现画面，等待半天不出图。然后系统操作越来越卡，结果发现内存爆掉了。一般这时，只能重启电脑，我相信很多制作公司都会遇到这类问题。好了，需求在这里了，要么做优化要么买内存，有钱的公司无所谓嘛。直接上128G，256G。但有一点，现在的视频从1080P，到现在的4K，以后的8K。硬件的提升，会带来画面的提升，同时观众的需求也不断在提升。你是否也有住够的钱去喃，成本也是在增加的，由此看，场景优化是否重要喃，如果到此也都不以为然，请直接关闭浏览器，该干嘛干嘛去。

我们接着聊，在谈完是否需要优化的这个大前提下，如果大家都认同优化的必要性，我们接下来就要谈如何优化了。目前在场景优化这块Maya和各家渲染器都有专门的工具来帮助用户解决场景优化方案，由于技术的互通性，不同渲染器在场景优化这块的做法差不多都是一样的。因此这里没有必要去做一个渲染器之间的横向对比，这也不是本文的重点，所以这里我们挑选Arnold这块渲染器作为案例，主要是这家公司的渲染器最大的卖点不也是巨量场景的渲染优势吗！

在我们看来场景优化贯穿整个三维流水线，如果一家制作公司忽视这块，那么相信这家公司的成本控制一定做得不怎么样，具体的咱们一点一点分析。

先来看一段视频

相信很多人都应该看过，过多的信息大家可以自己查阅，这里就附上这家公司的网址吧，http://www.whiskytree.com/，当年也是看了这段视频后才开始入坑漫长的场景优化技术研究，慢慢长征路啊......。通过视频我们看到，这家公司其实在场景拼装之前做了大量的开发准备。首先是资产库，这点相信国内的各大公司也都有自家的资产库管理方案。但应该很少有公司意识到场景优化。其实从资产环节也已经下手了，从视频中可以看出，这家公司用到的技术应该是代理技术，利用简易模型代替实体模型。然后挂在ass做代理渲染，国内不少公司都沿用的这套思路，放在制作中，后面我们会分析这种方案的弊端。另外近几年流行起来的一个技术又为各大制作公司提供了一条线路-Assembly，为此我们专门用这套技术方案做了对比演示，这里放上一段对比演示测试，在此感谢下某公司的支持，提供了场景数据对比：

视频如下我们按照从左到右，从上到下的顺序来讲解，我们编号1,2,3,4来对应说明下：

1.没有任何优化，资产文件都是mb文件，然后直接进行reference高模到一场里进行场景制作。

2.使用Assembly技术，打开简模场景，渲染时切换高模版本。

3.优化方案1，打开简模场景，渲染高模，场景内保留层级。

4.优化方案2，打开简模场景，渲染高模，未保留层级。

上图数据的时间并非最终时间，最直观的时间直接看上方视频比较客观，因为数据里统计的加载场景时间，并不包含使用者实际操作过程中的时间。通过上面的测试就为我们下面要讲的场景优化方案做一个铺垫，对比测试的过程大致是这样，在同系统同平台下进行的测试，模拟一个制作者从打开场景到渲染出图的整个过程，目的在于阐述两个环节：

●灯光制作环节：单个场景的打开，加载，制作到渲染，作为项目的管理者，应该很清晰的明白一点，渲染速度并非是衡量一个镜头的成本，成本的计算应该是从制作者拿到文件那一刻开始计算，所以过分的强调某个渲染器速度快，意义不是绝对的。要从整个镜头从开始到完成的时间，才具备可参考性。很多制作者会遇到这样的问题，打开一个镜可能需要漫长的等待，当文件打开后，制作人员为了避免一会再次打开文件等待过程，干脆就不关闭场景。一直制作，反反复复的操作和渲染势必导致内存不停的累加。直到内存溢出，如果运气好，没有crash掉，当你保存场景的时候也有可能是个漫长的保存过程，这样的制作效率是否也应该算作成本喃。

●渲染环节：目前绝大部分的制作公司都会采用的batchrender的方式，而极少采用独立的渲染方式，比如Arnold的kick。两者的最大的区别在于数据的调用方式，前者的过程一定是磁盘-maya内存-渲染器，后者是磁盘-渲染器，省掉了一个过程，我们这里没有做个相关的数据对比，大胆猜测下，在目前主流的硬件设备上磁盘的读写速度很难和内存直接对比，加之maya的缓存功能，把磁盘数据转换到内存里，对直接从内存读取渲染来说，会加速预加载的过程，减少时间，用我们的观点来说就是牺牲空间换时间，而从磁盘来说可能就是一个瓶颈（如果有朋友了解相关磁盘读写加速的方案，不妨和我们联系，一起来探讨一下），这里我们做一个假设，一条镜头有100帧，而恰巧有100台机器，我们分别使用batch和kick两种方式做两种渲染方案，渲染参数设置一致，默认采样，尺寸960*540，png格式。

理论的计算公式表

实测数据表

接下来我们回到一开始，场景都是有若干小的物件组装而成。在早期的Maya版本中，主要是硬生生加载进来。无论你是import的方式也好还是reference也好，都是直接把场景加载到Maya内，既内存内。可以设想，当场景面数和节点增多时，相信你的内存是抗不住的，因此连场景都没办法加载进来，内存就吃完了。有钱的朋友加内存解决，这里直接忽略。好啦，后来Maya加入了个新东西，Assembly，相信不少公司都已经在用了。至少有流程TD的公司大部分都在用，它解决了场景的拼接和加载问题，因为他可以在不同Level的模型之间做切换，因此不少公司用它来做Previs。

但问题随之即来，它在渲染方面非常的不灵活，可以说是鸡肋吧。渲染的时候需要硬切，比所有数据全部读到Maya内存里，这和之前说的没有Assembly的方式是一样的。只是把这个加载过程放在了渲染阶段，在场景足够大的时候或者说是足够复杂的时候，内存一样是爆掉。而且在渲染前，制作师需要可能漫长的等待过程，就是慢慢看着它把场景一点一点加载进来，甚至可能Crash掉。好了到这一步，入坑的公司应该不少了吧，可能此时不少大公司就开始在渲染这一环节直接放弃掉Maya，投奔其他软件。这里不做讨论，有钱毕竟就想怎么玩怎么玩咯，那没钱或者财力相对弱的公司或者个人怎么办喃。

好了，渲染器又提供了Archive，也就是大部分制作人口中的代理技术(后面都用代理技术作为术语，方便读者理解)，来解决场景加载和渲染问题，arnold是stadnin（ass），Redshift是rs，vray，prman应该是rib，几乎都有相同的技术来解决这类问题。在上面视频中，也运用到这类技术，即代理技术是允许使用任何物体加载一个代理节点，此代理节点去读取磁盘的文件，如ass，渲染器在渲染前，转换场景描述的时候自动加载磁盘内的数据，因此无需通过Maya内存读取三维信息，达到场景优化渲染的一整套方案，如下面所示：

好了，到这里是不是大家觉得，好像问题解决啦，没什么可聊的啦，我相信大部分的人会有这样的想法。那好了，咱们来聊一些具体在项目中使用此类技术的弊端，注意一下，虽然下面我们会用Arnold的ass作为分析对象，但所有渲染器只要是利用代理技术就都会遇到下面的问题：

         物体属性选项问题

我们拿一个物体的Shape节点和用standin节点加载ass进行对比：

从图中不难发现，很多属性，在standin上是没有的。代理技术是把当前三维模型转述为磁盘文件，那么数据是写死在文件内的。虽然给了用户不少override的选项，新版本的arnold提供了一个operaterr节点来操作ass文件。但问题是，一旦需要修改和模型相关的option，诸如Export  Tangents、Export Veterx Colorts等。只能回到上一个环节打开源文件重新输出一次ass文件。好，假设你是一个像建筑这种静止的物体的时候，只需导出一次就好。可能觉得也没什么，那假设是一个动画模型喃，比如一颗树，你是否有耐心慢慢等待输出ass文件的过程喃，我们也假设你有，并且不在乎，继续下面的讨论。

运动模糊问题

渲染如果需要运动模糊，尤其是defrom motion的时候，我们可能会尝试不同的length和step值来达到我们需要的模糊效果。哪怕你是计算vector也是同样，如果再ass文件内没有模糊信息的话，无论制作者如何调节motion 参数也不会有效果。因为ass文件被写死了，又得回到模型环节重新输出。好了，不同的镜头可能都会有不同模糊需求，是否也做好准备继续重新输出喃（没事，顺便还可以出去休息会找个理由）。公司层面是否也无所谓这些时间成本的浪费喃（哎，反正老板也不懂，管他的）。

磁盘占用问题

一般来说像ass代理文件，大小一般2倍于abc文件，不同的shape存在差异性，这里需要具体的测试来验证，各位读者有时间的话可以做做对比看看。

预览和灯光制作问题

都知道灯光师，制作环境灯光，需要知道环境集体是怎样的。如果只是单单显示一个盒子，对灯光或者预览来说会有一定的局限性。那有人说standin有线框显示，实体显示啊，对没错。但问题来了，这种切换效率高吗，并且视图的可操控性和maya内存的开销，是否也应该关注下喃，笔者这里做了一次对比测试：

左手边上下视频都是用Ass文件加载，右手边是优化过后的结果，从直观层面看：

1.加载速度不一样

2.内存开销上也不同

测速数据表

具体分析下，我们先从上下两幅图对比入手，由于我们这里没有足够多的场景资产，所以上方的图就只能使用copy的方式给大家呈现举例。假设一个场景里面都是用standin代理技术布景，如果在预览和制作灯光时，需要实体显示物体的时候，很容易导致Maya内存溢出，更别说正常的制作。下方的图是我们模拟在使用关联复制，既比如制作分布常用的技术。节约内存，达到制作大面积植被的效果（其实思路可以延伸到任何类型物体上，思路是发散的，题外话）。你也能较清晰的发现左右对比在同一方式上的差别。更为重要的是，目前测试的版本中发现切换standin不同的显示方式时，内存并不能得到释放，会不会累加这里没有具体测试过。