延遲是AR/VR體驗的基礎

原文: 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圖像所通過的步驟:

1. 追蹤頭戴顯示器的姿態, 也就是現實世界中的位置和朝向.
2. 應用程序基於取得的姿態數據繪製立體的場景畫面.
3. 圖形硬件需要把繪製的場景畫面傳輸到頭戴顯示器的屏幕上. 這一步叫作掃描輸出, 需要順序地從上到下, 從左到右地讀取幀緩存, 並把像素數據經過鏈接線(如HDMI)傳輸到屏幕上.
4. 基於收到的像素數據, 屏幕的每個像素纔會開始發射光子.
5. 在某個時刻, 屏幕需要爲每個像素中止發射特定的光子, 這是因爲像素並不是持續點亮的, 或者因爲下一幀需要顯示新的顏色.

在3D管線中還存在一些額外的幀緩存, 這裏先忽略掉, 因爲這不是產生一幀AR/VR畫面的組成部分.

咱們依次來看一下這三部分:

追蹤延遲與採用的系統硬件高度相關. 一個IMU(3軸陀螺儀和3軸加速計)的延遲很是低, 差點兒相同是1ms, 但是有誤差. 特別是位置數據是來源於加速計的兩次積分, 誤差更大. 基於攝像頭的追蹤不會有誤差, 但是它的延遲更高, 因爲要捕捉圖像, 傳輸到計算機, 並進行圖像處理來計算姿態, 很是easy就花費了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的透視挑戰.) 有一我的需要站出來改變硬件規則, 這樣顯示延遲才幹夠降低. 儘管不easy, 但早晚會出現的, 問題是什麼時候, 何人. 我但願VR市場會隨着Rift的公佈而起飛, 那顯示延遲減小的日子也就不遠了.

假設你一直覺得AR/VR僅僅是簡單地在眼鏡內顯示一幅圖像的話, 我但願這篇文章可以讓你明白呈現真實的虛擬圖像有多麼複雜, 咱們眼下還處於走馬觀花的階段.