什么叫做场景优化？
每一位游戏玩家，无论是传统的 PC 和主机游戏，还是时新的手游以至 VR 游戏，都会对这样一个名词有着特殊的理解和关注，那就是 FPS（帧速率，Frames Per Second）。FPS 太低的话，画面就一卡一卡的，玩起来不舒服；如果是戴上 VR 头盔的话，因为晕动症的影响，玩家甚至会迅速感到头晕和恶心，一天都无法心情舒畅。
FPS 顾名思义就是每秒钟渲染的帧数，也就是说，显卡和显示器每秒钟都会更新数十张不同的图像（帧），进而形成一种动画的效果。
从传统动画的角度上来说，每秒 10 帧以上的画面就可以形成连续的动画效果（例如中国古代的走马灯），而不需要任何交互的电影放映，则采用每秒 25 帧或者接近 30 帧的播放速度，让观看者自在地欣赏大片。
但是加入了交互元素之后，例如可以快速转动视角的鼠标，手柄，以及 VR 头盔，人们对于帧速率的需求就直线上升了——如果是面对平面液晶显示屏的话，受限于 IPS 屏幕本身的刷新率特性，内容本身通常需要达到 60FPS 的渲染速度；而戴上 VR 头盔之后，采用 OLED 屏幕的内容则可以达到 75FPS 的更新，事实上，出于尽量避免晕眩的考虑，游戏内容的画面刷新也必须达到这个数值。
然而这谈何容易：交互游戏并不是预先拍摄好的电影和动画片。它需要根据玩家的操作来触发不同的逻辑，并渲染出不同的画面内容。而游戏场景可能是复杂的，细碎的，并且有很高的真实感和特效方面的要求——而这一切都必须在短短的1/75秒内完成！就算显示硬件的水准逐年提升，这依然是一个极具挑战性的话题：如何优化我们的场景和渲染策略，在如此有限的时间要求内，实现高效与细节并存的游戏内容呢？
本文将针对这一话题做适当的讨论，然而话题本身的技术含量已是深不见底，所以文章也只能浅尝辄止，只期望为读者和同行们小启一扇门扉。
渲染批次，扼住命运的咽喉
在描述一些晦涩难懂的名词之前，我们不妨先来看一个例子：
假设我们有一个果园，每天它都要派出一辆卡车，走固定的路线运送水果到市里去。如果运送的水果总量为 10 吨，而这辆卡车一次能够承载 200 千克水果的话，那么显而易见它需要跑上 50 趟才能完成这一任务，也许这会花费整整一天的时间才能够完成。
显而易见，我们并不希望这项工作花掉那么多的宝贵时间，那么一种直截了当的解决方案是：给这辆卡车换上更为给力的发动机，比如 NVIDIA 的战术核显卡，让它跑全程的速度减半再减半，同样 50 趟的任务，这回只要一个上午就可以搞定了。
当然生活也许并不总是那么如意的，也许果园的工作人员早就心怀怨气，每次给卡车只装了 50 千克水果，于是可怜的司机就需要走上足足 200 个来回，直到别人吃上早饭了还垂死地奔波在路上……
幸好，拯救他的方法也不止一种，比如，装上战术核显卡之后，他至少能够和别人一样每天拉完 50 趟再按时回家吃饭了。
但是一个智商正常的果园老板应该不会把这当成是最合理的决策吧……难道不应该先开除那个装货的？让爷的小卡车别这么傻兮兮地跑上 200 个批次吗？
结束我们的遐想，而现实却也许傻得有些可爱：当作为内容开发者的我们同样遇到了“卡车花在路上的时间太长”这种问题的时候，第一选择往往是换用更逆天的显卡和系统，而不是好好琢磨一下该死的工作人员藏哪儿了。
没错，送了 200 趟水果的卡车，就好比跑了 200 个渲染批次（Draw Call）的显卡，而每个批次的执行都是会消耗固定时间的。而为了缩短这一时间，进而提升帧速率的开发者们，与其直接买入更新的显示设备，倒不如先坐下来仔细想一想，渲染批次过多的瓶颈是什么（那个作孽的装货工？），我又能把它优化到什么地步（至少恢复到 50 个批次的正常水准？）。而这成百上千吨的水果就好比是复杂和精致的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包，以及其他种种细致入微的内容吗？当然不能。所以我们也没有办法在一个渲染批次里搞定美女模型的一切。
而与此相关的另一个问题也会困扰着更深层次的图形开发者：场景内容的管理。例如一座数字化的虚拟城市，每一栋楼，每一个房间，每一辆车，每一位居民，都应当是独立存在的个体，对这些模型资源的管理也显然应当按照相似的分类方法。然而从渲染的角度来说，这样产生的 Draw Call 恐怕远远不是最优的选择，甚至轻而易举就会让前文中送水果的卡车司机崩溃掉。
如果按照材质把模型重新分组和整合，倒是可以进一步提升渲染的效率，不过资源的管理工作却无疑会让人崩溃。试想一下，在公安局的户口本上，你不再属于某个家庭，而你身体的各部分则分别隶属于短发组，麻脸组，格子衫组，灰裤子组……这种“按材质分组”的行为看起来多少有点“汉尼拔”似的惊悚气氛了。
然而，场景优化面临的麻烦还远没有尽头。
有关填充率的那些传说
试想一位画家，挥毫泼墨，将现实中的山水人物跃然纸上，描绘得栩栩如生。这些山水人物原本是自然存在的，绘制到纸上，就成了油彩，凑近去看，就会有浓重的颗粒感——虽然大多数情况下这并不妨碍我们观瞻就是了。
现代计算机的图形渲染过程与此类同。把复杂的场景模型跃然于屏幕之上，这一过程称作光栅化（Rasterization），而屏幕上的像素点，近看起来同样存在颗粒感，低分辨率的屏幕则更为明显。这种颗粒感对于VR类的内容来说更为显著（因为 VR 眼镜相当于放大了屏幕分辨率对画面质量的影响），而它也是破坏场景真实感和效果的主因之一。
那好办啊，有人可能会说，那就拼命增加屏幕分辨率不就好了。从现在的 1080p，到 2K，到 4K，到 8K……总会有彻底解决这个问题的一天吧？
然而事情并没有这么简单，还是回过头来谈谈我们的画家：在一张 A4 纸上画简笔画，也许他只需要 1-2 分钟而已；如果是 10 米长卷，那么也许要一天的时间；如果是在万里长城上……那么画家可能直接就跳下去了，搞这么一辈子的工程，生不如死啊。
没错，这里的画卷可以类比为我们所说的屏幕分辨率，而画家求死的原因，只因为要画的东西太多，而他对画卷内容的填充率（Fill Rate）太低了，因而渲染效率也变得惨不忍睹。
这个问题的解决方案，无非三种，弊端也是一目了然：
1、改用小点的画卷（降低屏幕分辨率和用户体验）；
2、换个疯狂的画家（升级硬件，提升填充率）；
3、少画点花里胡哨的东西（降低渲染内容的质量）。
听起来都不是什么一劳永逸的选择，并且大多数开发者一定会选用最直接的那个方案，没错，换更疯狂的画家，搞硬件的军备竞赛。
不过从场景优化的角度来说，方案三反而成了最靠谱的一条道路，并且这给各路算法豪侠和数学家们也提出了一个有趣的命题：如何在渲染质量还看得过去的前提下，尽量少画点“对用户没用”的内容呢？
对这句话的详细解释就是：用户看不到的场景不要画出来，把它提前裁减掉（Culling）；而用户可能本来也看不清的场景，就用更低的细节程度（Level of Details）把它画出来。
这里必须要解释一句。显卡并不是多么聪明的一种硬件产品，它并不能主动分辨出当前提交的渲染指令中，包含的信息是否真的能够被显示到屏幕之上；而是选择了另一种更为简单的策略：不管有多少东西都先画上去，如果不幸没画到纸上的话……反正你也不在乎对不对？毕竟最终用户关注的只有纸面上的内容而已。
然而古今中外，那些为了优化场景而苦思冥想的开发者们，却仅为了这一个目标前赴后继，伤痕累累。
当然，这里所说到的“填充率”一词，只是相关图形系统运行机制的冰山一角。它还可能被进一步细分为像素填充率（光栅化操作和屏幕缓存绘制的速率）和纹理填充率（纹理在模型表面映射和采样操作的速率）。而实际执行过程中，还可能受到显存带宽（显卡在单位时间能够传输数据的总量）参数的影响，而这些信息往往都会标识在具体显卡品牌的性能说明文档中，作为发烧友比较和购买的依据（虽然它们实际上并无统一标准可言）。
不过这并非本文所要继续深入阐述的命题了，我们关心的，还是那些图形学和 VR 领域的先行者们，为了哪怕一点点的优化效果做出过的努力。
联系方式：0755-81699111
课程网址： http://www.vrkuo.com/course/vr.html
