原文: http://blogs.valvesoftware.com/abrash/latency-the-sine-qua-non-of-ar-and-vr/
译者注: 原文发表于2012年, 虽然当时的一些硬件条件限制现在已经没有了, 但我们可以从中学习到AR/VR的延迟解决思路. 另外, 译文略过了显示器的发展史
如果没有足够低的延迟, 根本不可能带来好的体验, 也就说大脑不会把眼睛看到的虚拟画面当成真实的. 所谓的”真实”, 不是指你能不能用眼睛分辨出它们是否为虚拟的, 而是说你能不能在移动头, 眼睛或身体时, 感觉出它们与真实物体不一样. 这其中的关键是虚拟的物体在你移动时, 必须一直保持在正确的位置上.
如果从你转头开始到画面绘制在新的位置上花了太长的时间, 那画面就会偏移了很远, 造成VR中的抖动或者拖影.
那多少延迟才算多呢? 比你想像的要少得多. 参考一下, 游戏时从鼠标移动到屏幕光标更新通常有50ms甚至更多的延迟. 个人经验, 大于20ms对于VR来说是不可接受的, 有研究表明15ms(甚至是7ms)是一个临界值.
AR/VR对延迟的要求比传统游戏高得多, 是因为它们要求在你移动时保持真实世界的稳定性. 而传统游戏对于你来说, 大脑认为你是在看一幅图像. 当你移动时延迟会造成画面出现偏移, 而不是在它原本应该在的位置
假设你以60度/秒的速度转头(虽然这听起来很快, 但实际上比较慢, 因为人可以每秒转头超过100度), 延迟是50ms, 分辨率是1K x 1K. 当你转头时, 虚拟画面是基于50ms前的数据显示的, 也就是说它们的位置已经落后了3度, 这比你伸直手臂后看到的拇指宽度都要大. 换一种说法, 物体的位置已经差了30个像素, 也就是说看起来是非常明显的.
当然可以通过预测把绘制位置画到正确的地方, 这在大多数情况下是表现良好的. 不过, 当突然出现方向的改变时, 这个差异甚至比没有预测时更大. 所以, 这种做法同样会让人感觉到非常大的差异, 因为转向是常见的一种情况.
另外, 延迟看起来是直接与晕动症相关的, 延迟越大, 症状就越明显.
所以, 我们需要把延迟降低到20ms, 可能的话越少越好. 就算是20ms在现有的硬件条件下也是很难达成的, 至于7ms, 目前根本不可能. 让我们来看一下为什么.
下面这些就是画一次AR/VR图像所经过的步骤:
追踪头戴显示器的姿态, 也就是现实世界中的位置和朝向.
应用程序基于取得的姿态数据绘制立体的场景画面.
图形硬件需要把绘制的场景画面传输到头戴显示器的屏幕上. 这一步叫做扫描输出, 需要顺序地从上到下, 从左到右地读取帧缓存, 并把像素数据通过连接线(如HDMI)传输到屏幕上.
基于收到的像素数据, 屏幕的每个像素才会开始发射光子.
在某个时刻, 屏幕需要为每个像素停止发射特定的光子, 这是因为像素并不是持续点亮的, 或者因为下一帧需要显示新的颜色.
在3D管线中还存在一些额外的帧缓存, 这里先忽略掉, 因为这不是产生一帧AR/VR画面的组成部分.
我们依次来看一下这三部分:
追踪延迟与采用的系统硬件高度相关. 一个IMU(3轴陀螺仪和3轴加速计)的延迟非常低, 差不多是1ms, 但是有偏差. 特别是位置数据是来源于加速计的两次积分, 偏差更大. 基于摄像头的追踪不会有偏差, 但是它的延迟更高, 因为要捕捉图像, 传输到计算机, 并进行图像处理来计算姿态, 很容易就花费了10-15ms. 当前有一种没有偏差的的低延迟系统硬件, 来自于NDI, 可以做到4ms的延迟, 就是我们用来做延迟追踪的.
渲染延迟取决于CPU和GPU的能力, 还有所要绘制场景的图形复杂度. 大多数游戏并不会一直保持60FPS, 所以它们的渲染延迟都会大于16ms, 这对于AR/VR来说已经太高了. 老一点的游戏可以运行的更快, 甚至可以达到几百FPS, 但是相对的它们的画面比较朴素. 所以, 这里我们假设渲染延迟是16ms.
渲染的画面一旦生成, 就需要传输到屏幕. 特定像素的延迟通过取决于使用的显示技术, 而且与画面相关. 但是对于最常见的扫描输出技术来说, 最坏的情况是从帧缓冲绘制完毕到更新到屏幕上会花掉一整帧的时间. 如果是60FPS, 那最坏的情况就是16ms. 例如, 假设一帧画面正好在扫描输出开始扫描最上面那行时绘制好, 那么最上面那一行几乎就没有延迟, 但最下面那一行输出到屏幕上差不多就有16ms的延迟(理论上不会有那么多, 每两帧之前是有空白时间的). 也就是说, 渲染完的画面数据更新到屏幕上大约有16ms的延迟.
有时像素数据可以在到达时立即显示出来, 就是使用激光和OLED的屏幕. 有时会被缓存起来再显示, 就像顺序制彩色LCOS, 红色是同时点亮的, 接下来 是绿色, 然后就是蓝色. 有时像素数据会立即应用, 但是距离可见的改变会一点延迟, 如LCD面板会花费几ms切换状态. 还有一些电视机甚至会缓存多帧的画面用于图像处理. 接下来的讨论我会基于最优的情况, 也就是说我们使用的屏幕会在数据到达时立即把像素转化成光子.
一旦光子发射出去了, 几乎不需要什么时间就可以到达你的眼睛. 但是还有一个地方存在延迟, 那就是像素产生的光子停止到达你眼睛的时间. 这看起来好像没什么影响, 但当你戴着显示器时是影响非常大的. 因为一个像素状态持续的时间越长, 那它就距离正确的位置越远, 也就是残影越严重. 从延迟的角度来看, 像射线扫描那样亮一下就灭, 远比OLED或LCD那样一整帧的时间都亮着要好得多. 很多OLED和LCD显示器的残影现象比CRT要高, 这个 问题比较复杂, 这里就不展开讨论了, 我们暂且假设这部分的延迟是零. 不过需要明确的是, 如果持续时间不为零, 那么对于60帧来说, 最坏的情况是额外多了16ms的延迟.
所以现的总延迟是4+16+16=36ms, 离20ms还差很多, 更不用说7ms了.
所以, 要想达到理想的延迟, 有一些规则必须做出改变.
在追踪阶段, 比较直观的方式是通过传感器融合光学追踪和IMU. IMU可以提供低延迟的状态, 而光学追踪可以用于修正IMU的偏差. 做好这个是十分具有挑战性的, 而且市面上也没有现成的可用方案, 所以只能对硬件规则做出一些改变. 合理实现的话, 传感器融合可以降低追踪延迟1ms左右.
对于渲染来说, 除了简化场景外几乎没有什么可以做的. 对于PC来说, 只有5年前的游戏画面才能满足3-5ms的渲染延迟. 当然, 如果你想做可以到处走动的AR, 那需要在移动处理器上实现非常低的延迟, 或许只能做到2000年左右的游戏画质. 这就是为什么我认为AR还有一段很长的路要走.
好了, 经过两个阶段, 我们降低了4-6ms, 很不错! 但现在我们需要把渲染的像素显示到屏幕上, 这是需要改变硬件规则的地方, 因为60帧率的显示器需要大约16ms把数据扫描到屏幕上, 这就成了我们降低延迟到20ms以下几乎不可逾越的障碍.
我之所以说”几乎”, 是因为这在理论上是有可能实现的, 就是”与光束比赛”(只是打个比方, 对于CRT来说才有电子光束): 每条或每块扫描线的渲染正好在读取它们之前进行. 这个方案(对于缓存整帧或顺序制LCOS是不起作用的)可以把延迟降低足够多, 前提是保证每条或每块扫描线在这些像素扫描输出之前渲染完成, 通常大约几毫秒. 通过”与光束比赛”, 是有可能把总体的延迟降低到梦幻般的7ms.
很不幸, 与光束比赛需要一种非正规的底层渲染方式, 因为每条或每块扫描线是分开渲染的, 并且在游戏的时间线并不是在同一个点. 每块必须准确地在扫描输出时渲染, 否则与光束比赛就没有任何意义了. 这意味着你并不是每16.6ms渲染一次, 而是每次只渲染一小块. 假设屏幕被分割成16块, 那样的话每1毫秒就需要渲染一块. 既然还是有那么多像素要渲染, 那整个场景的数据结构同样也需要分块传输到指定区域. 这花费的时间应该比正常的帧渲染要高一点, 也就是说场景复杂度需要降低, 保证可以在3-5ms内画完. 想还原现代的3D游戏和真实度, 变得异常困难.
与光束赛跑还有一个问题, 那就是需要避免区块之间在视觉上出现边界. 这可能是无法接受的, 因为就算是一些细线, 也会使人分散注意力. 为了解决这个问题, 需要扭曲一些线段来接合. 显然, 这些线段的数量越多, 产生的瑕疵越少, 当然性能开销就越大. 如果取得平衡, 与光束家赛跑就变得可行了, 但是它会增加复杂度和性能开销, 对于降低显示延迟来说, 这并不是一个明智的的方案, 或许从根本上我就是错误的.
或许更简单的可行方案是把显示刷新率提高到120Hz, 这可以立即把显示延迟降低到8ms左右, 总体的延迟达到12-14ms. 既然我们可以渲染到200-333 FPS, 渲染是没有问题的, 那240Hz会更好, 总体的延迟会降低到8-10ms.
高帧率还可以提升显示质量, 像我之前说的, 可以降低晕动症. 现在只有一个问题: 适用于头戴显示器的高刷新率显示屏多半还不存在.
举个例子, 现在的Oculus Rift原型机使用了LCD的手机屏幕做显示器. 这是可以理解的, 因为手机屏幕的产量巨大, 所以它们非常便宜并且广泛使用. 但是手机屏幕并没有理由运行在120Hz, 因为这对用户来说没有益处, 也就没有人会生产120Hz的手机屏幕面板. 理论上这当然可以做到, OLED也是, 但除非VR市场足够大驱动厂商进行面板设计, 或者高价进行定制, 否则市面上是不会出现的.
还有一个相关的潜在方案: 在不提高帧率的前提下, 提升扫描输出的速度(也就是像素数据转化为光子的速度). 例如, 如果图形芯片可以在8ms内扫描输出一帧缓存, 而帧率仍然是60Hz, 那么扫描输出可以在半帧的时间内完成, 剩下的8ms就不会有数据了. 如果显示屏可以在数据到达时立即转化为光子, 那总体的延迟就可以降低8ms, 就算实际的帧率还是60Hz. 当然, 更高的扫描输出速度可以获得更好的效果. 这个途径不会像提高帧率带来的显示质量的提升, 但它既不会提升渲染的负担, 也不会降低渲染的质量. 跟高帧率一样, 这个方法只对AR/VR有意义, 所以需要显示屏技术的革命才会使它变成现实.
除了与光束比赛之外, 在现有的硬件条件下是没有方法达到足够低的显示延迟的, 这需要足够高的分辨率, 足够低的价格, 合适的图像大小, 小巧的体积和足够轻的质量, 还有适合消费级别AR/VR的像素质量. (你还会面临VR的宽视角和AR的透视挑战.) 有一个人需要站出来改变硬件规则, 这样显示延迟才可以下降. 虽然不容易, 但迟早会出现的, 问题是何时, 何人. 我希望VR市场会随着Rift的发布而起飞, 那显示延迟降低的日子也就不远了.
如果你一直以为AR/VR只是简单地在眼镜内显示一幅图像的话, 我希望这篇文章可以让你明白呈现真实的虚拟图像有多么复杂, 我们目前还处于蜻蜓点水的阶段.
转自：http://blog.csdn.net/xoyojank/article/details/50322355
虚拟现实的发展史;虚拟现实发展史
译者注: 原文发表于2012年, 虽然当时的一些硬件条件限制现在已经没有了, 但我们可以从中学习到AR/VR的延迟解决思路. 另外, 译文略过了显示器的发展史
如果没有足够低的延迟, 根本不可能带来好的体验, 也就说大脑不会把眼睛看到的虚拟画面当成真实的. 所谓的”真实”, 不是指你能不能用眼睛分辨出它们是否为虚拟的, 而是说你能不能在移动头, 眼睛或身体时, 感觉出它们与真实物体不一样. 这其中的关键是虚拟的物体在你移动时, 必须一直保持在正确的位置上.
如果从你转头开始到画面绘制在新的位置上花了太长的时间, 那画面就会偏移了很远, 造成VR中的抖动或者拖影.
那多少延迟才算多呢? 比你想像的要少得多. 参考一下, 游戏时从鼠标移动到屏幕光标更新通常有50ms甚至更多的延迟. 个人经验, 大于20ms对于VR来说是不可接受的, 有研究表明15ms(甚至是7ms)是一个临界值.
AR/VR对延迟的要求比传统游戏高得多, 是因为它们要求在你移动时保持真实世界的稳定性. 而传统游戏对于你来说, 大脑认为你是在看一幅图像. 当你移动时延迟会造成画面出现偏移, 而不是在它原本应该在的位置
假设你以60度/秒的速度转头(虽然这听起来很快, 但实际上比较慢, 因为人可以每秒转头超过100度), 延迟是50ms, 分辨率是1K x 1K. 当你转头时, 虚拟画面是基于50ms前的数据显示的, 也就是说它们的位置已经落后了3度, 这比你伸直手臂后看到的拇指宽度都要大. 换一种说法, 物体的位置已经差了30个像素, 也就是说看起来是非常明显的.
当然可以通过预测把绘制位置画到正确的地方, 这在大多数情况下是表现良好的. 不过, 当突然出现方向的改变时, 这个差异甚至比没有预测时更大. 所以, 这种做法同样会让人感觉到非常大的差异, 因为转向是常见的一种情况.
另外, 延迟看起来是直接与晕动症相关的, 延迟越大, 症状就越明显.
所以, 我们需要把延迟降低到20ms, 可能的话越少越好. 就算是20ms在现有的硬件条件下也是很难达成的, 至于7ms, 目前根本不可能. 让我们来看一下为什么.
下面这些就是画一次AR/VR图像所经过的步骤:
追踪头戴显示器的姿态, 也就是现实世界中的位置和朝向.
应用程序基于取得的姿态数据绘制立体的场景画面.
图形硬件需要把绘制的场景画面传输到头戴显示器的屏幕上. 这一步叫做扫描输出, 需要顺序地从上到下, 从左到右地读取帧缓存, 并把像素数据通过连接线(如HDMI)传输到屏幕上.
基于收到的像素数据, 屏幕的每个像素才会开始发射光子.
在某个时刻, 屏幕需要为每个像素停止发射特定的光子, 这是因为像素并不是持续点亮的, 或者因为下一帧需要显示新的颜色.
在3D管线中还存在一些额外的帧缓存, 这里先忽略掉, 因为这不是产生一帧AR/VR画面的组成部分.
我们依次来看一下这三部分:
追踪延迟与采用的系统硬件高度相关. 一个IMU(3轴陀螺仪和3轴加速计)的延迟非常低, 差不多是1ms, 但是有偏差. 特别是位置数据是来源于加速计的两次积分, 偏差更大. 基于摄像头的追踪不会有偏差, 但是它的延迟更高, 因为要捕捉图像, 传输到计算机, 并进行图像处理来计算姿态, 很容易就花费了10-15ms. 当前有一种没有偏差的的低延迟系统硬件, 来自于NDI, 可以做到4ms的延迟, 就是我们用来做延迟追踪的.
渲染延迟取决于CPU和GPU的能力, 还有所要绘制场景的图形复杂度. 大多数游戏并不会一直保持60FPS, 所以它们的渲染延迟都会大于16ms, 这对于AR/VR来说已经太高了. 老一点的游戏可以运行的更快, 甚至可以达到几百FPS, 但是相对的它们的画面比较朴素. 所以, 这里我们假设渲染延迟是16ms.
渲染的画面一旦生成, 就需要传输到屏幕. 特定像素的延迟通过取决于使用的显示技术, 而且与画面相关. 但是对于最常见的扫描输出技术来说, 最坏的情况是从帧缓冲绘制完毕到更新到屏幕上会花掉一整帧的时间. 如果是60FPS, 那最坏的情况就是16ms. 例如, 假设一帧画面正好在扫描输出开始扫描最上面那行时绘制好, 那么最上面那一行几乎就没有延迟, 但最下面那一行输出到屏幕上差不多就有16ms的延迟(理论上不会有那么多, 每两帧之前是有空白时间的). 也就是说, 渲染完的画面数据更新到屏幕上大约有16ms的延迟.
有时像素数据可以在到达时立即显示出来, 就是使用激光和OLED的屏幕. 有时会被缓存起来再显示, 就像顺序制彩色LCOS, 红色是同时点亮的, 接下来 是绿色, 然后就是蓝色. 有时像素数据会立即应用, 但是距离可见的改变会一点延迟, 如LCD面板会花费几ms切换状态. 还有一些电视机甚至会缓存多帧的画面用于图像处理. 接下来的讨论我会基于最优的情况, 也就是说我们使用的屏幕会在数据到达时立即把像素转化成光子.
一旦光子发射出去了, 几乎不需要什么时间就可以到达你的眼睛. 但是还有一个地方存在延迟, 那就是像素产生的光子停止到达你眼睛的时间. 这看起来好像没什么影响, 但当你戴着显示器时是影响非常大的. 因为一个像素状态持续的时间越长, 那它就距离正确的位置越远, 也就是残影越严重. 从延迟的角度来看, 像射线扫描那样亮一下就灭, 远比OLED或LCD那样一整帧的时间都亮着要好得多. 很多OLED和LCD显示器的残影现象比CRT要高, 这个 问题比较复杂, 这里就不展开讨论了, 我们暂且假设这部分的延迟是零. 不过需要明确的是, 如果持续时间不为零, 那么对于60帧来说, 最坏的情况是额外多了16ms的延迟.
所以现的总延迟是4+16+16=36ms, 离20ms还差很多, 更不用说7ms了.
所以, 要想达到理想的延迟, 有一些规则必须做出改变.
在追踪阶段, 比较直观的方式是通过传感器融合光学追踪和IMU. IMU可以提供低延迟的状态, 而光学追踪可以用于修正IMU的偏差. 做好这个是十分具有挑战性的, 而且市面上也没有现成的可用方案, 所以只能对硬件规则做出一些改变. 合理实现的话, 传感器融合可以降低追踪延迟1ms左右.
对于渲染来说, 除了简化场景外几乎没有什么可以做的. 对于PC来说, 只有5年前的游戏画面才能满足3-5ms的渲染延迟. 当然, 如果你想做可以到处走动的AR, 那需要在移动处理器上实现非常低的延迟, 或许只能做到2000年左右的游戏画质. 这就是为什么我认为AR还有一段很长的路要走.
好了, 经过两个阶段, 我们降低了4-6ms, 很不错! 但现在我们需要把渲染的像素显示到屏幕上, 这是需要改变硬件规则的地方, 因为60帧率的显示器需要大约16ms把数据扫描到屏幕上, 这就成了我们降低延迟到20ms以下几乎不可逾越的障碍.
我之所以说”几乎”, 是因为这在理论上是有可能实现的, 就是”与光束比赛”(只是打个比方, 对于CRT来说才有电子光束): 每条或每块扫描线的渲染正好在读取它们之前进行. 这个方案(对于缓存整帧或顺序制LCOS是不起作用的)可以把延迟降低足够多, 前提是保证每条或每块扫描线在这些像素扫描输出之前渲染完成, 通常大约几毫秒. 通过”与光束比赛”, 是有可能把总体的延迟降低到梦幻般的7ms.
很不幸, 与光束比赛需要一种非正规的底层渲染方式, 因为每条或每块扫描线是分开渲染的, 并且在游戏的时间线并不是在同一个点. 每块必须准确地在扫描输出时渲染, 否则与光束比赛就没有任何意义了. 这意味着你并不是每16.6ms渲染一次, 而是每次只渲染一小块. 假设屏幕被分割成16块, 那样的话每1毫秒就需要渲染一块. 既然还是有那么多像素要渲染, 那整个场景的数据结构同样也需要分块传输到指定区域. 这花费的时间应该比正常的帧渲染要高一点, 也就是说场景复杂度需要降低, 保证可以在3-5ms内画完. 想还原现代的3D游戏和真实度, 变得异常困难.
与光束赛跑还有一个问题, 那就是需要避免区块之间在视觉上出现边界. 这可能是无法接受的, 因为就算是一些细线, 也会使人分散注意力. 为了解决这个问题, 需要扭曲一些线段来接合. 显然, 这些线段的数量越多, 产生的瑕疵越少, 当然性能开销就越大. 如果取得平衡, 与光束家赛跑就变得可行了, 但是它会增加复杂度和性能开销, 对于降低显示延迟来说, 这并不是一个明智的的方案, 或许从根本上我就是错误的.
或许更简单的可行方案是把显示刷新率提高到120Hz, 这可以立即把显示延迟降低到8ms左右, 总体的延迟达到12-14ms. 既然我们可以渲染到200-333 FPS, 渲染是没有问题的, 那240Hz会更好, 总体的延迟会降低到8-10ms.
高帧率还可以提升显示质量, 像我之前说的, 可以降低晕动症. 现在只有一个问题: 适用于头戴显示器的高刷新率显示屏多半还不存在.
举个例子, 现在的Oculus Rift原型机使用了LCD的手机屏幕做显示器. 这是可以理解的, 因为手机屏幕的产量巨大, 所以它们非常便宜并且广泛使用. 但是手机屏幕并没有理由运行在120Hz, 因为这对用户来说没有益处, 也就没有人会生产120Hz的手机屏幕面板. 理论上这当然可以做到, OLED也是, 但除非VR市场足够大驱动厂商进行面板设计, 或者高价进行定制, 否则市面上是不会出现的.
还有一个相关的潜在方案: 在不提高帧率的前提下, 提升扫描输出的速度(也就是像素数据转化为光子的速度). 例如, 如果图形芯片可以在8ms内扫描输出一帧缓存, 而帧率仍然是60Hz, 那么扫描输出可以在半帧的时间内完成, 剩下的8ms就不会有数据了. 如果显示屏可以在数据到达时立即转化为光子, 那总体的延迟就可以降低8ms, 就算实际的帧率还是60Hz. 当然, 更高的扫描输出速度可以获得更好的效果. 这个途径不会像提高帧率带来的显示质量的提升, 但它既不会提升渲染的负担, 也不会降低渲染的质量. 跟高帧率一样, 这个方法只对AR/VR有意义, 所以需要显示屏技术的革命才会使它变成现实.
除了与光束比赛之外, 在现有的硬件条件下是没有方法达到足够低的显示延迟的, 这需要足够高的分辨率, 足够低的价格, 合适的图像大小, 小巧的体积和足够轻的质量, 还有适合消费级别AR/VR的像素质量. (你还会面临VR的宽视角和AR的透视挑战.) 有一个人需要站出来改变硬件规则, 这样显示延迟才可以下降. 虽然不容易, 但迟早会出现的, 问题是何时, 何人. 我希望VR市场会随着Rift的发布而起飞, 那显示延迟降低的日子也就不远了.
如果你一直以为AR/VR只是简单地在眼镜内显示一幅图像的话, 我希望这篇文章可以让你明白呈现真实的虚拟图像有多么复杂, 我们目前还处于蜻蜓点水的阶段.
转自：http://blog.csdn.net/xoyojank/article/details/50322355
虚拟现实的发展史;虚拟现实发展史