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

莋者是Arthur，本名赵鹏

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

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

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

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

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

相信很多人都应该看过，过多的信息大家可以自己查阅这里就附上这家公司的网址吧，/当年也是看了这段视频后才开始入坑漫长嘚场景优化技术研究，慢慢长征路啊......通过视频我们看到，这家公司其实在场景拼装之前做了大量的开发准备首先是资产库，这点相信國内的各大公司也都有自家的资产库管理方案但应该很少有公司意识到场景优化。其实从资产环节也已经下手了从视频中可以看出，這家公司用到的技术应该是代理技术利用简易模型代替实体模型。然后挂在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*540png格式。

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

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

好了渲染器又提供了Archive，也就是大部分制作人口中的代理技术(后面都用代理技术作为术语方便读者理解)，来解决场景加载和渲染问题arnold是stadnin（ass），Redshift是rsvray，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文件加载，右手边是优化过后的结果从直观层面看：

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