和大牛聊聊VR开发中的优化

VR次元 2017-04-20 17:42:16

原标题:和大牛聊聊VR开发中的优化

前言

大概做了大半年的VR开发,HTCVive上与room scale和手柄控制器、激光相关的开发做过,gearvr使用oculus sdk开发做过,使用Cardboard做普通vr app在android和ios上发布也做过。

vr设备呢,HTCVive和oculus搞过,gearvr和普通Cardboard类的手机vr搞过,LG的新的glass接过,露光严重,idealens、还有一大票的国产一体机,pico、小米,嗯做的好的目前的确还是那几个大厂的。

由于我参与的项目主要围绕视频播放的功能,所以大型3d场景接触的倒不多,然而还是有很多需要优化的点,为什么呢,因为做的视频播放本身就需要对大于1080p的视频做解码、在unity中渲染,对cpu和gpu消耗都很大,挤占了部分性能,所以对其他逻辑和渲染部分的性能要求更高。

VR开发中的优化主要围绕两部分吧,一部分是由于VR的特殊场景,双眼渲染,且对帧率要求高,所以对性能要求也高,还有vr场景下一些特殊要求。另一部分是传统unity性能优化部分,对程序和美术都有要求。unity相关的优化网上已经有很多优秀的文章了,我在这只根据VR开发与传统unity开发的区别,分享一些优化的建议。

VR优化

先从VR帧率卡说起

因为HTCVive和gearvr做的开发比较多,先说说这两个设备卡的表现,对于HTCVive而言,如果程序执行时卡顿比如loading或者什么,一般会优雅的回到HTCVive的一个默认场景,对用户还算比较友好,而对于gearvr而言,如果卡顿影响了渲染或者帧率低,那么用户头转动的时候能明显看到周围来不及渲染的黑的地方,如果渲染卡死的话,只剩最后一帧渲染的画面,周围的空间都是黑的。

对于PC而言,我们配置的显卡至少也会是970+吧,性能都比较好,cpu、渲染、IO等性能都比较高,但是到了移动端,相应操作性能都会变差,之前对比过一些操作,比如图片动态加载,在editor下可能只要几毫秒最多20几毫秒,到了移动端可能都要几十毫秒甚至2-500毫秒的都有,那么帧率降低的简直不要不要的。所以对于unity而言,不光在editor下看性能指标,也要利用profiler观察在移动设备的性能。我们在开发过程中和测试中都要不断的进行性能优化。

VR和传统游戏卡的区别

传统游戏也会做很多的性能优化,但是却可以有很多常用的解决方案,例如为了解决资源包大的问题,将资源通过异步下载并动态加载,为了减少加载的损耗,那么大不了加一个loading画面,而loading时一般而言随便卡,不太需要关注操作的阻塞延迟和帧率,因为loading时无需响应用户操作。甚至有的游戏按一个按钮也会进行阻塞,大不了出个loading嘛反正用户也会等。

对于VR应用,用户都是可以自由操作转头的,一旦卡顿,影响帧率,直接会影响用户视野转动,影响体验,同时降低帧率刷新后,用户会有眩晕感,那么就很失败。

一般什么时候会发生卡顿呢,对于vr程序开发而言,往往出现在场景切换时资源加载、初始化脚本逻辑执行,例如monobehaviour的awake和start里包含的大量的逻辑,甚至你以为使用了协程就没有问题,然而协程在首次执行时第一个yield前可能也包含了大量的逻辑。还有运行时动态资源加载以及常见的每帧处理事情过多导致降帧。

性能优化工具

unity提供了一些性能指标查看工具,比如profiler和frame debug。

● profiler
profiler可以看cpu、render、内存等性能消耗,一般可以看出每一帧哪些操作分别消耗了多少时间,找到瓶颈进行优化。例如我之前在pc上看性能貌似都还可以,但是在gearvr移动端就明显的看到像Resource.Load()这种操作过多的占用了时间于是优化掉。

 VR开发中的优化

 VR开发中的优化

另外注意不必要的log记得清理,否则在profiler里会占用很多时间。

profiler也可以实时查看unity程序在android和ios上运行时的性能表现。

● framedebug
framedebug可以方便的查看一帧都进行了哪些渲染,可以用来优化drawcall,在做vr开发的时候,因为双眼渲染,所以drawcall比普通程序也会高很多,正常表现是2倍的drawcall,具体平台就算进行了一定的优化,看起来往往也要多50%以上的drawcall。

 

 

 VR开发中的优化

 

99VR视界二维码
热门推荐
Hot Recommended
在线客服