元宇宙开发之VR制作指南（2）

Warp方案介绍

延迟问题在软件层面是无法避免的，即要根据用户的输入进行游戏逻辑计算再渲染，等到渲染完成就一定会过去一段时间。这个时候的画面就不匹配当前的玩家头部的视线角度和位置了。Motion to Photon的延迟是VR制作体验最核心的问题。

 

Oculus在paper《The Asynchronous Time Warp for Virtual Reality on Consumer Hardware 》第一次提出ATW技术。Warp从字面解释即是将渲染输出的画面按照uv网格进行一定的扭曲。由于VR制作显示器和眼睛之间有一层透镜，透镜使得平面的屏幕光线转化成人眼视觉的球形角度射入到视网膜。同时由于透镜的扭曲效果，我们需要对平面显示器显示的图像信息进行对应的矫正。另一方面为了补偿透镜边缘厚度不一致导致的色相分离，warp方案对于图像的扭曲在RGB不同通道上有细微的差异。当然纯粹的warp其实只是对VR制作显示光学上的修正，并不处理延时问题。

 

那么在warp的过程中，我们尝试根据当前双眼的视线角度来修正画面结果，如果这个修正的步骤足够快，不就能解决头部旋转延迟的问题。这计算被Oculus称作为Time Warp。我们在正常视觉光线矫正的基础上添加了基于时间的矫正，而且不需要额外的步骤。

 

由于在足够短的时间内，头部角度的运动幅度不会很大，所以对于time warp我们只要将渲染完的画面以平面的形式，根据当前时间点HMD的旋转信息将画面旋转到对应的角度，就能够让画面匹配实时的运动。当然只进行图像的旋转是不够的，双眼位置在空间站并不是重叠的，相对于HMD单一的位置坐标有一定的偏移。同时双眼在一定时间内的移动，前一帧重建的平面对于双眼位置的旋转角度也是不一致的。只进行简单的旋转在物理上是非常不准确的。但在实际的测试实验下，只考虑旋转的简单TimeWrap已经可以达到很好的效果。另一个问题是在于头部运动旋转后的边缘可能会没有画面信息，但人眼在视野边缘的关注度很低，基本不会影响感知。

 

延迟和预测

TimeWarp可以将人感知的头部运动和接收到画面的延迟降低到一个很低的数值，减少大脑接受信息的不一致导致的眩晕。但游戏内容物理逻辑的更新是没有修正的，这样会影响玩家的体验吗？答案是当然不会，除非游戏的帧率低到一定的程度。我们对于肢体操作的感受延迟是几百毫秒这个数量级的，比起视觉反馈的延迟高多了。还记得苏炳添100米的起跑反应时间是0.16秒，扯远了。

 

那么我们有办法尽可能将视觉延迟修正到0呢？预测是一个方案，只要我们能够估算出timewarp所需要的计算时间，在获取HMD姿态信息时根据运动传感器的历史数据进行对应时长的运动预测，得到warp操作完成时刻的数据，理论上就可以实现0延迟。同时游戏逻辑更新阶段使用的传感器姿态信息也使用预测值，也可以减少操作的延迟。基于人体运动惯性的姿态预测可以达到很好的效果，甚至在有专用芯片的时候采用神经网络进行预测也是不错的方案。

​姿态预测和同步在Valve的slides中给出的predictuon时间线的示意图。但其实除掉预测，在实际实践的时候还有一些困难。

- 显示器的刷新率时延

- GPU管线的的时序同步

 

上文有提到VR制作显示需要高像素密度及高刷新效率的显示器，frontbuffer画面信息编码解码再到LED显示器，总会有一个时间消耗。根据我对映维网整合US专利信息分析，Meta在高刷新率LED制造工艺上有大量的提交，包括硅基LED半导体蚀刻，调光原件和控制器等等。下一代Oculus显示模块将具备更高的参数和更好体验。

 

另一部分是GPU管线的schedule问题。就像RTR4里提到的Timing，对于游戏内容渲染来说，帧率变化抖动是一个非常常见的问题。这种变化在VR制作下会带来糟糕的体验。ATW计算另一个关键核心就在于异步asynchronous。我们希望timewarp这个处理和正常的渲染是异步进行的，即无需等待正常渲染的任务完成。根据设定好的刷新频率对有效的front buffer画面进行timewarp变换后提交给显示器。就算是游戏的实际渲染帧率低，也不会影响到显示器输出的刷效率。

 

然而目前的几乎所有GPU都不支持真正的异步执行。不论是正常的Rendering 还是ComputeQueue，在底层是共用计算核心的。GPU在分配计算线程组时有一定可配置的策略，但相同的芯片计算单元共享和抢占机制注定会互相影响。在Oculus的测试中分别使用CPU、DSP和GPU进行ATW的实现。GPU实现的效率是DSP和CPU的近10倍。

 

对于CPU和DSP方案，图像Warp需要大量的贴图采样，这种不一致性的内存访问性能较低，而GPU有对应的采样器等芯片硬件单元。另一方面framebuffer存储在显存中，内存同步也是和大问题。同时warp算法本身chromatic aberration的处理是RGB分离的，DSP那些扩展的指令集实现的SIMD和PIL策略并不能发挥出最大的优势。

针对GPU方案，最大的问题在于不能真正的异步，VSync和Preemption对于姿态预测和渲染时间评估带来一定的难度。DSP芯片可以实现异步但性能并没有设想中那么高。

总而言之目前并没有最完美的ATW的实现方案。有传言Meta在考虑设计自己的VR制作芯片。即在芯片设计时类似光线追踪模块有专门的计算单元来执行ATW，在图形API层面加上真正的异步扩展。当然对于Apple来说有这样的能力。

 

SpaceWarp

基于ATW，考虑了HMD在空间中移动的TimeWarp被oculus称为SpaceWarp。熟悉图形学的朋友会发现，我们常用的temporal方法在时域上的空间重建和spaceWarp有相似之处。考虑空间位置我们可以根据depthbuffer的深度信息重建出像素的深度坐标，再根据新时刻的双眼姿态信息重建出头部运动后的画面。

当然类比temporal与SSR一样，部分像素也可能因为重新投影找不到对应的信息，需要做一些拟合。对于运动的物体，也需要motion vector信息来抵消flicker。更精妙的是，SpaceWarp也可以顺带解决抗锯齿的问题，利用时间维度的信息来增加像素采样。

 

Oculus在目前的SDK中已经实装了SpaceWarp技术——AppSW。该方案更加激进，既然我们可以高准确度地重建画面帧，为什么不以一半的帧率渲染然后插值出高帧率呢？使用该特性可以在36fps下重建出72fps的画面，这样极大提升VR制作渲染的时间预算。显然SpaceWarp的计算开销比起纯粹的TimeWarp要大多了。经测试排除warp重建本身的计算开销，整体可以提升70%的性能。

 

这里有个个人的猜想，这套space warp方案被命名为AppSW是因为其技术实现是在应用层，即引擎和现有的图形API层。类似于如果自行设计芯片的话，是不是以后会有硬件层级的spaceWarp如“HwSW”。这里你可能会问，真的有这么大的需求把这个warp流程固化到硬件芯片层面吗？

是的没错，合成层(CompositionLayer)是另一个VR制作渲染特性，和正常的相机Framebuffer一样是也要做对应的warp操作。合成层的目的主要是减少渲染的颗粒感和锯齿，即我们使用独立的层进行warp采样，该图层的分辨率可以足够高，超过显示器的分辨率。通常在视频渲染和UI上我们使用合成层来提升画面质量。这样其实在开发时warp的渲染计算量在整体渲染的比重是不低的，不论传统应用还是游戏。我们都可以利用专有硬件来提升这部分的执行效率。

 

最后再提一点关于VR制作云游戏，warp对于VR制作云游戏来说有巨大的优势。云端渲染计算达到延迟可以被warp在感知上抵消，而传统的云游戏延迟卡了就是卡了。云渲染估计只能实现简单的TimeWarp，SpaceWarp做不到。

 

GraphicsAPI优化

解决了反馈延迟的问题接下来就是VR制作的渲染效率了。VR制作游戏对比起传统游戏来说就是天生的性能需求爆炸，双目图形渲染不可避免会带来双倍的渲染开销。同时高帧率和高分辨的需求又是雪上加霜。但其实对于VR制作渲染效率的优化有很多思路，首先是CPU端 graphicsAPI层面的优化。

由于VR制作渲染，左右眼的图像分别是两个位置和角度不同的相机渲染的，那么场景中的所有Renderer需要使用不同的ViewMatrix渲染两次，造成了双倍的绘制提交(DrawCall)和带宽消耗。那么有没有办法优化呢？比如一次指令提交就可以绘制出双眼的模型。

对于VR制作的绘制提交，工业界给出了几种方案用于减少CPU端的指令提交和带宽消耗。

Multi Pass Stereo 传统渲染方式，左右眼画面单独渲染。drawcall数量翻倍

Single Pass Stereo 一个pass进行左右眼绘制，drawcall数量不增加。

 

Single Pass Stereo有多种具体的实现方案

使用GeometryShader

Multi-View Rendering

Stereo Instancing

 

GeometryShader方案是最直观的想法，一份顶点数据经过GS输出左右眼相机对应的顶点。但是由于GS在GPU端本身有较大的overhead，所以不常被工业界采用。

Multi-View是一个针对VR制作的GraphicsAPI扩张。实现原理是通过特定的API配置多个viewport输出到frame buffer的不同位置，在raster前的shader步骤只执行一次但是有多个输出。Multi-View在dx gl gles vulkan等API都有支持，是最常用的SPSR的方案。CPU端只有单倍drawcall，带宽减少，GPU端primitive setup和vs等步骤的开销变小了，整体来说GPU端也有一定的性能提升。额外提一点multi-view除了用于VR制作渲染之外还可以用于实现single pass的pointlight shadowmap渲染或者是其他cubemap的捕获。

 

​Multi-view管线时序

最后一个方案是Stereo Instancing，即利用GPU Instancing的特性，对所有drawcall instancing双倍的顶点，利用InstanceID加额外的constantbuffer实现stereo rendering。S

Stereo instancing方案不需要额外的图形API扩展，只要支持instancing就可以实现，兼容性更好，但目前VR制作都是特定硬件所以兼容性优势没有意义。在GPU端也有一定的性能提升，但是如果本身模型渲染使用了instancing，那么在编程层面实现会较为复杂。

 

其他的CPU计算也有优化的空间。

视锥体剔除可以极大减少无效的drawcall提交， 但是由于VR制作渲染左右两只眼睛相机的视锥体都需要剔除，计算量翻倍。由于双眼相机贴合很近，有方案提出使用统一的Mono相机的视锥体然后额外加上5度的torrance就可以完成双眼的剔除。

有研究表明距离人眼10m之外的物体双眼感受不到视差的存在。基于这个视觉特性我们对于一定距离外的物体可以不进行双目渲染即左右眼使用相同的图形输出，减少对应的绘制开销。

 

 

StereoRendering最大的问题是Near eye Display 需要更高分辨率的像素输出。在优化像素渲染方面工业界提出了大量的优化方式。

 

最核心的方案就是Foveated Rendering(注视点渲染)，该技术属于multi-resolution rendering的一种。根据人眼视觉细胞的分布和视觉生理特性，视野核心的区域对视觉贡献度最高，而周围区域的光线输入贡献弱。如果我们对注视点的区域绘制使用高分辨率，视野边缘降低渲染分辨率即可以减少整体的像素着色器计算开销。

 

​人眼视野区域眼球追踪技术可以检测用户的注视方向，目前一些高端VR制作设备支持了眼球追踪技术，而最近官宣的PSVR制作2也支持该技术。Pico的高端商用版本已经配置了眼球追踪功能，在开发SDK中也支持对应的注视点渲染优化功能。

 

对于没有眼球追踪的功能的设备，我们也可以根据视野范围，固定比例缩减视野边缘的分辨率，该技术被称作Fixed Foveated Rendering(FFR)。当用户将视线从一个物体移动至另一个物体时，如果两个对象距离较近就只需要进行眼动(Saccade)，而距离较远时头部则会运动，而不是将眼球转动到视线边缘，这样VR制作显示器视线边缘固定降低分辨率也是合理的。有眼球追踪追踪可以解决只有眼动情况下的注视点渲染问题，同时可以进行更高的像素计算量优化。

 

Foveated Rendering的另一个渲染实现是使用Log Polar极坐标进行变化，使得整体的像素分辨率有更高利用率和自然的过渡。

 

​极坐标变换的注视点渲染针对视觉特性的还有其他的一些优化。

例如人眼的视觉中心并不是在画面的正中心的，左眼会偏右，右眼偏左。这样Foveated Rendering其实达不到最佳的优化状态。相比于传统单个相机的渲染，视野大小通过纵向FOV加上AspectRatio实现(横向纵向FOV相同)，VR制作双目渲染其实可以使用非对称FOV进行计算即上下左右四个FOV值，将画面的中心匹配眼球视野中心。在游戏引擎支持方面，Unity也针对VR制作渲染适配了非对称FOV的管线参数设定。但是由于FOV的设定变化会影响大量的shader计算，开发者要是进行迁移还是有一定的工作量。

 

​非对称FOV参数、由于imagebuffer输出的画面经过视觉矫正之后，部分像素经过透镜不会被用户看到。我们可以直接在渲染阶段跳过这些像素的渲染。具体的方式是使用一个MeshMask覆盖整个被剔除的区域，这块区域DepthTest会Failed从而减少Pixel着色的开销，在HTV Vive中，这部分剔除的像素可以减少17%的像素填充率。

 

 

技术缺口和挑战

> The demands on display technology for VR制作 are extremely high.

VR制作 设备的技术缺口实在是太大了。最首要的是芯片算力，要达到人眼无法感知的图像输出，显卡的算力要达到现在的1000倍。大概是如果考虑上各种优化技术，芯片性能提升一个数量级可能也勉强够用了。

电池技术制约着VR制作一体机的使用范围。更高能量密度的电池技术，可以使得VR制作设备的重量大大减轻，提升用户体验。不过由于目前VR制作头盔笨重的外形和闷热的佩戴体验，Quest2两个小时左右的佩戴体验也是足够了。但等到下一代更轻便和紧凑的头盔设计出现，目前的电池对于要支持起元宇宙长时间的体验就有些力不从心了。或许到时候我们需要一个更大的充电宝。

 

正如RTR4中提到对于显示器技术的需求是极高的。目前工业界和学术界的方向都集中在显示屏幕和透镜方案的创新中。

曲面屏幕、柔性屏幕等一些新显示技术也将会用于改进VR制作的显示效果。更具一些供应链的消息，Meta的下一代VR制作头盔的显示器可能采用混合屏幕的方案，即双眼中心是两块高刷效率的Micro OLED屏幕，大的背景是一整块分辨率相对低的Fast-LED。Foveation Display了属于是。

更多的透镜方案被提出来提升HMD的FOV。透镜厚度越小，人眼距离屏幕越近FOV越大。目前市面上大部分VR制作设备使用的是Fresnel透镜。而最新的一类Pancake透镜利用半透半反偏振膜的双透镜系统折叠光学路径，使得透镜的厚度大大减小，这样同时可以降低眼镜厚度减轻整体重量和体积又增大FOV。

 

SLAM方案也是巨大的挑战。VR制作一体机无法使用Beacon等基站进行空间定位。HMD上的红外和RGB摄像头用来进行SLAM重建和空间定位，以及手势及手柄的6dof姿态定位。在Quest2中的see through是通过4个红外摄像头识别的。穿透模式也一定会使用RGB进行重建，这样才可以实现完整的Artificial Reality。但是由于手柄追踪的方案都是基于红外摄像头，手柄发射红外光源来头盔来进行空间定位。如果同时支持红外和RGB，一体机芯片就要支持多达8个视频流处理，计算压力无法负担。彩色SLAM重建必然RGB摄像头的分辨率要足够高。Microsoft的一个专利里提到的是给RGB摄像头添加一个红外偏振镜片，让其能够更好地分析出红外光源。另一个方案是在手柄上添加红外摄像机和芯片进行独立SLAM，头盔上添加红外光源反向识别。不过只要使用了红外识别就注定无法戴着头盔走出室外，或许RGB识别才是最终正确的路线。但仔细想想，元宇宙的核心就不想让我们离开房间，你只要戴着头盔沉浸在虚拟世界中就好了。甚至以后我们只需要停留在冷冻仓里链接脑机接口。

​

在简单翻阅了过去几年的siggraph或者是ACM VR制作顶会的论文之后，我发现关于VR制作渲染方面的软件技术似乎已经不再是热门的研究方向。更多的是新奇的显示技术，注视点AR渲染或者是holograph等。渲染技术其实在16年VR制作风口已经被业界研究得差不多了，上文我们提到的第一篇关于VR制作渲染最核心的方案ATW是oculus在16年的paper。

 

本文未完，待续……

上海九影专注AR和VR的定制开发，欢迎您的咨询！

 

 

本文转自：原创 Yemi 游戏开发实验室   如有侵权，请通知删除，谢谢！