加入收藏 | 设为首页 | 会员中心 | 我要投稿 云计算网_宿迁站长网 (https://www.0527zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 站长资讯 > 动态 > 正文

从60Hz到75Hz,完成一次VR的场景优化需要遍历哪些血泪史?

发布时间:2016-01-19 06:27:08 所属栏目:动态 来源:雷锋网
导读:VR场景优化走过哪些血泪史,VR游戏才成为今天这样?

【编者按】作者王锐,VR行业资深从业者。

什么叫做场景优化?

每一位游戏玩家,无论是传统的PC和主机游戏,还是时新的手游以至VR游戏,都会对这样一个名词有着特殊的理解和关注,那就是FPS(帧速率,Frames Per Second)。FPS太低的话,画面就一卡一卡的,玩起来不舒服;如果是戴上VR头盔的话,因为晕动症的影响,玩家甚至会迅速感到头晕和恶心,一天都无法心情舒畅。

FPS顾名思义就是每秒钟渲染的帧数,也就是说,显卡和显示器每秒钟都会更新数十张不同的图像(帧),进而形成一种动画的效果。

从传统动画的角度上来说,每秒10帧以上的画面就可以形成连续的动画效果(例如中国古代的走马灯),而不需要任何交互的电影放映,则采用每秒25帧或者接近30帧的播放速度,让观看者自在地欣赏大片。

从60Hz到75Hz,完成一次VR的场景优化需要遍历哪些血泪史?

但是加入了交互元素之后,例如可以快速转动视角的鼠标,手柄,以及VR头盔,人们对于帧速率的需求就直线上升了——如果是面对平面液晶显示屏的话,受限于IPS屏幕本身的刷新率特性,内容本身通常需要达到60FPS的渲染速度;而戴上VR头盔之后,采用OLED屏幕的内容则可以达到75FPS的更新,事实上,出于尽量避免晕眩的考虑,游戏内容的画面刷新也必须达到这个数值。

然而这谈何容易:交互游戏并不是预先拍摄好的电影和动画片。它需要根据玩家的操作来触发不同的逻辑,并渲染出不同的画面内容。而游戏场景可能是复杂的,细碎的,并且有很高的真实感和特效方面的要求——而这一切都必须在短短的1/75秒内完成!就算显示硬件的水准逐年提升,这依然是一个极具挑战性的话题:如何优化我们的场景和渲染策略,在如此有限的时间要求内,实现高效与细节并存的游戏内容呢?

从60Hz到75Hz,完成一次VR的场景优化需要遍历哪些血泪史?

本文将针对这一话题做适当的讨论,然而话题本身的技术含量已是深不见底,所以文章也只能浅尝辄止,只期望为读者和同行们小启一扇门扉。

渲染批次,扼住命运的咽喉

在描述一些晦涩难懂的名词之前,我们不妨先来看一个例子:

假设我们有一个果园,每天它都要派出一辆卡车,走固定的路线运送水果到市里去。如果运送的水果总量为10吨,而这辆卡车一次能够承载200千克水果的话,那么显而易见它需要跑上50趟才能完成这一任务,也许这会花费整整一天的时间才能够完成。

显而易见,我们并不希望这项工作花掉那么多的宝贵时间,那么一种直截了当的解决方案是:给这辆卡车换上更为给力的发动机,比如NVIDIA的战术核显卡,让它跑全程的速度减半再减半,同样50趟的任务,这回只要一个上午就可以搞定了。

当然生活也许并不总是那么如意的,也许果园的工作人员早就心怀怨气,每次给卡车只装了50千克水果,于是可怜的司机就需要走上足足200个来回,直到别人吃上早饭了还垂死地奔波在路上……

幸好,拯救他的方法也不止一种,比如,装上战术核显卡之后,他至少能够和别人一样每天拉完50趟再按时回家吃饭了。

但是一个智商正常的果园老板应该不会把这当成是最合理的决策吧……难道不应该先开除那个装货的?让爷的小卡车别这么傻兮兮地跑上200个批次吗?

结束我们的遐想,而现实却也许傻得有些可爱:当作为内容开发者的我们同样遇到了“卡车花在路上的时间太长”这种问题的时候,第一选择往往是换用更逆天的显卡和系统,而不是好好琢磨一下该死的工作人员藏哪儿了。

从60Hz到75Hz,完成一次VR的场景优化需要遍历哪些血泪史?

没错,送了200趟水果的卡车,就好比跑了200个渲染批次(Draw Call)的显卡,而每个批次的执行都是会消耗固定时间的。而为了缩短这一时间,进而提升帧速率的开发者们,与其直接买入更新的显示设备,倒不如先坐下来仔细想一想,渲染批次过多的瓶颈是什么(那个作孽的装货工?),我又能把它优化到什么地步(至少恢复到50个批次的正常水准?)。而这成百上千吨的水果就好比是复杂和精致的VR场景内容,同一时间内能够送达的越多,它能够表达的内容真实感与细节程度也就越详实。

从60Hz到75Hz,完成一次VR的场景优化需要遍历哪些血泪史?

渲染批次(Draw Call)在以往并不是一个被十分重视的概念,制作游戏场景的美术人员更愿意用“三角面数”(Triangle Face)来描述内容的复杂程度或者制作水准,譬如:这是一个足有1000万面的卡通少女(她的每一根毛发也许都清晰可辨),又或者这是一个只有100万面的故宫实景模型(然而我的高超技巧让这一艺术瑰宝依然栩栩如生)。

殊不知,对于实时渲染而言,三角面数并不足以决定渲染的效率以及帧速率结果。仅用了一个批次就完成渲染的1000万面模型,和用了1万个批次才渲染完成的100万面模型,其执行效率恐怕是天壤之别。后者在实际执行当中的表现,恐怕一定会让那些自信于低面数模型的人们大跌眼镜。

然而这就引起了另一个有趣的论题:为什么会有大量的Draw Call呢?既然每一位开发者都能明白这样的道理,为什么不一开始就设计成一次Draw Call执行全部场景物体的渲染操作呢?就算是因为承载力的问题不得不分成多个Draw Call,这种简单粗暴的设计依然应当是最优的解法无疑吧?

然而这样的愿望往往无力成为现实,因为现代图形渲染底层接口对于Draw Call的实际执行,是在绘制实际几何体图元(Draw Primitive)的阶段;而每次绘制图元的操作之前,我们只能为这组图元(可能是200个三角面,也可能是10万个三角面)设置一张纹理图像(Texture),以及一组着色器(Shader)——而这两者正是虚拟现实和游戏应用当中用于表达物体材质和真实感的最核心组件。一张图像能够容纳和清晰地表达一个精致美女的肌肤,秀发,慧眼,红唇,丝衣,高跟鞋,LV包,以及其他种种细致入微的内容吗?当然不能。所以我们也没有办法在一个渲染批次里搞定美女模型的一切。

从60Hz到75Hz,完成一次VR的场景优化需要遍历哪些血泪史?

(编辑:云计算网_宿迁站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!