加载中…
个人资料
Wingedtiger
Wingedtiger
  • 博客等级:
  • 博客积分:0
  • 博客访问:47,546
  • 关注人气:306
  • 获赠金笔:0支
  • 赠出金笔:0支
  • 荣誉徽章:
相关博文
推荐博文
谁看过这篇博文
加载中…
正文 字体大小:

浅谈场景优化的重要性-场景篇

(2018-06-01 10:03:15)
标签:

场景优化

arnold场景

maya

分类: 杂谈
浅谈场景优化的重要性-场景篇

近几年来,随着电影特技的飞速发展和电脑硬件的提升,电影制作的场面是越来越宏大,随之而来的就是如何有效的管理和优化巨量的场景,因此也诞生了不少专门解决此类问题的软件,比如像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的vrmesh,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不同的显示方式时,内存并不能得到释放,会不会累加这里没有具体测试过。

到这里,差不多已经分析和对比了Maya下场景优化的几种方案,我们从是否需要优化场景的角度和优化方案上做了一些介绍,来浅谈了场景优化的重要性,读者是否还有疑虑,可进QQ群讨论:139482355(或扫描下方的图片即可)。

浅谈场景优化的重要性-场景篇

0

阅读 评论 收藏 转载 喜欢 打印举报/Report
前一篇:WitCachePipe
  • 评论加载中,请稍候...
发评论

    发评论

    以上网友发言只代表其个人观点,不代表新浪网的观点或立场。

    < 前一篇WitCachePipe
      

    新浪BLOG意见反馈留言板 电话:4000520066 提示音后按1键(按当地市话标准计费) 欢迎批评指正

    新浪简介 | About Sina | 广告服务 | 联系我们 | 招聘信息 | 网站律师 | SINA English | 会员注册 | 产品答疑

    新浪公司 版权所有