http://m.blog.csdn.net/article/details?id=50667507

VR中的”延遲”, 特指”Motion-To-Photon Latency”, 指的是從用戶運(yùn)動(dòng)開始到相應(yīng)畫面顯示到屏幕上所花的時(shí)間.?
?
這中間經(jīng)過了大概這么幾個(gè)步驟:

傳感器采集運(yùn)動(dòng)輸入數(shù)據(jù)

采集到的數(shù)據(jù)進(jìn)行過濾并通過線纜傳輸?shù)街鳈C(jī)

游戲引擎根據(jù)獲取的輸入數(shù)據(jù)更新邏輯和渲染視口

提交到驅(qū)動(dòng)并由驅(qū)動(dòng)發(fā)送到顯卡進(jìn)行渲染

把渲染的結(jié)果提交到屏幕, 像素進(jìn)行顏色的切換

用戶在屏幕上看到相應(yīng)的畫面

當(dāng)然, 實(shí)際上還有很多細(xì)節(jié)問題, 比如屏幕上的像素并不是同一時(shí)間切換的, 可能面上面的那行先切換, 再一行行更新到最下面的, 在這里就不糾結(jié)這些細(xì)節(jié)了.

這其中的每一個(gè)步驟都會(huì)產(chǎn)生一定的延遲, 而目前公認(rèn)的大眾能接受的延遲是20ms以下, 這基本上可以做為衡量一個(gè)VR頭顯是不是合格的一個(gè)標(biāo)準(zhǔn). 雖然20ms是非常短的時(shí)間, 但通過努力還是可以達(dá)到的, 主要有這么幾個(gè)思路:

硬件層面的優(yōu)化

• 提升傳感器的采樣頻率, 減少刷新率與傳感器頻率的同步等待時(shí)間消耗
• 提升傳感器的精度, 減少對(duì)采樣數(shù)據(jù)進(jìn)行穩(wěn)定性過濾產(chǎn)生的延遲
• 采用有線傳輸也有一部分原因是出于延遲的考慮
• 屏幕使用OLED替代LCD, 減少像素顏色切換的時(shí)間
• 提升屏幕刷新率, 主流的屏幕是60Hz, 那每幀就是16.67ms; 如果提升到90Hz, 那每幀就是11.11ms

大部分的手機(jī)VR產(chǎn)品在延遲上都是不合格的, 最明顯的表現(xiàn)就是轉(zhuǎn)頭時(shí)的畫面不連續(xù)/抖動(dòng)/殘影等:

• 市面上的手機(jī)采用OLED屏的還是少數(shù), 比如iPhone配個(gè)VR殼子那延遲就很感人
• 如果依賴手機(jī)的陀螺儀進(jìn)行轉(zhuǎn)向模擬, 其精度和頻率遠(yuǎn)遠(yuǎn)達(dá)不到要求
• 手機(jī)屏幕目前都是60Hz的刷新率, 在延遲上本身就受限

刷新率的提升

假設(shè)刷新率為60Hz, 并不是代表每幀就有16.67ms的延遲, 而是說屏幕圖像每16.67ms才更新一次, 渲染選項(xiàng)中的”垂直同步”的概念就是來源于此. 這就對(duì)我們提交渲染畫面的時(shí)機(jī)要求非常高, 如下圖:?

為了方便計(jì)算, 這里先假設(shè)傳感器, 傳輸, 屏幕像素切換的延遲都為0

• 假設(shè)我們?cè)诿繋_始的時(shí)候(上一次垂直同步結(jié)束)采樣一次傳感器數(shù)據(jù), 在垂直同步之前完成提交, 那延遲就是16.67ms
• 如果當(dāng)前幀無法在16.67ms內(nèi)完成渲染, 比如花了17ms, 那么就會(huì)拖到下一幀進(jìn)行提交, 屏幕上顯示的畫面就還是上一次的圖像, 這時(shí)候的延遲就變成了16.67*2=33.33ms

這就對(duì)VR的渲染提出了非常高的要求:

• FPS必須達(dá)到刷新率的要求, 90Hz就是90Hz, 80FPS是不行的, 會(huì)被垂直同步拖累成45FPS
• FPS必須保證穩(wěn)定, 偶爾掉一兩幀在VR中的感覺非常明顯, 可能某個(gè)物體的位置已經(jīng)差了幾十個(gè)像素了

以O(shè)culus Rift(消費(fèi)版)為例, 1080x1200x2的屏幕分辨率, 90Hz的刷新率, 再加上因?yàn)樽冃嗡枰腢pSampling, 實(shí)際的渲染畫面就是3024x1680@90Hz, 這性能壓力幾乎與4k@60Hz相當(dāng). 所以, 單純的提升刷新率和分辨率, 目前來說渲染能力還是跟不上. 不過既然有了性能需求, 硬件廠商才有前進(jìn)動(dòng)力, 對(duì)整個(gè)行業(yè)生態(tài)來說, 是件好事.

引擎層面的優(yōu)化

除了拼命優(yōu)化降低每幀畫面的渲染時(shí)間外, 引擎層面還可以通過一些策略進(jìn)行優(yōu)化, 關(guān)鍵的思路就是: 能不能把采樣傳感器數(shù)據(jù)的時(shí)間點(diǎn)盡量延后, 讓它與垂直同步的時(shí)間點(diǎn)盡量靠近?

這里我們?nèi)匀患僭O(shè)60Hz, 每幀時(shí)間16.67ms(約17ms), 忽略硬件延遲?

如果在游戲邏輯過程中(1ms時(shí))采樣傳感器數(shù)據(jù), 那延遲大約就是16ms?

如果在渲染線程進(jìn)行繪制之前(5ms時(shí)), 重新再采樣一下傳感器數(shù)據(jù), 修正一下視口信息(不會(huì)對(duì)游戲邏輯產(chǎn)生影響), 那延遲就縮短到了約12ms?

做過渲染優(yōu)化的人都知道, 提交D3D Command后, 需要等待GPU執(zhí)行完畢, 這部分時(shí)間在整幀時(shí)間中的占比還是相當(dāng)高的. 那有沒有辦法在渲染完成之后, 提交到屏幕之前再次采樣一次傳感器數(shù)據(jù)呢? 如果像下圖那樣的話, 延遲可以縮短到3ms!!!?

這就是Timewarp的主要思想, 我們來看看它是怎么實(shí)現(xiàn)的

Timewarp

了解過延遲渲染的人應(yīng)該都知道, 我們可以利用ZBuffer的深度數(shù)據(jù), 逆向推導(dǎo)出屏幕上每個(gè)像素的世界坐標(biāo)?

這就意味著, 我們可以把所有像素變換到世界空間, 再根據(jù)新的攝像機(jī)位置, 重新計(jì)算每個(gè)像素的屏幕坐標(biāo), 生成一幅新的圖像:?

可以看到之前被遮擋區(qū)域的像素是缺失的, 因?yàn)槲覀兊臄z像機(jī)位置變化了. 那如果攝像機(jī)位置不變, 僅僅是朝向變了呢? 這樣就不存在像素可見性的變化了:?

Timewarp正是利用了這個(gè)特性, 在保證位置不變的情況下, 把渲染完的畫面根據(jù)最新獲取的傳感器朝向信息計(jì)算出一幀新的畫面, 再提交到顯示屏. 由于角度變化非常小, 所以邊緣不會(huì)出大面積的像素缺失情況.?

Oculus的Demo中可以停止渲染新的畫面, 完全由單幀圖像計(jì)算出各個(gè)朝向的新畫面:?
?
也就是說, 只要角度變化不是非常大(上圖為了演示效果偏轉(zhuǎn)的角度很大了), 可以通過這項(xiàng)技術(shù)”憑空渲染”出下一幀的圖像, SONY的PSVR正是利用這一點(diǎn), 把60FPS的畫面Reproject成了120FPS.?
Timewarp只能處理頭部轉(zhuǎn)向, 不能處理頭部移動(dòng)的情況, 而且一旦錯(cuò)過了垂直同步的時(shí)機(jī), 一樣需要等待下一次垂直同步才能顯示出來. 那能不能在每次垂直同步之前, 強(qiáng)制進(jìn)行一次Timewarp呢? 那就需要驅(qū)動(dòng)來開個(gè)后門了…

驅(qū)動(dòng)層面的優(yōu)化

假設(shè)垂直同步時(shí), 當(dāng)前幀還沒有渲染完畢, 這時(shí)如果要進(jìn)行Timewarp的話, 就需要驅(qū)動(dòng)提供一種高優(yōu)先級(jí)的異步調(diào)用, 這就是異步Timewarp的由來: Timewarp操作與場(chǎng)景渲染并行執(zhí)行, 如果沒有新的渲染畫面, 就繼續(xù)使用上一幀的畫面進(jìn)行Timewarp.?

這可以在一定程度上補(bǔ)償FPS不達(dá)標(biāo)造成的延遲問題, GearVR中正是應(yīng)用了這項(xiàng)技術(shù), 保證了手機(jī)VR的體驗(yàn).?
當(dāng)然, PC上使用項(xiàng)技術(shù)還是有一些限制:

• 必須是Fermi, Kepler, Maxwell(或更新)核心的GPU
• GPU是以DrawCall為單位調(diào)度的, 所以耗時(shí)太長(zhǎng)的DrawCall是插入不了Timewarp繪制操作的
• 需要最新的Oculus和NVIDIA驅(qū)動(dòng)支持

異步Timewarp并不是說FPS低于標(biāo)準(zhǔn)還能流暢跑, 這只是一種補(bǔ)救措施, 所以優(yōu)化仍然要好好做-_-

驅(qū)動(dòng)方面還有一些其它的優(yōu)化空間, 比如強(qiáng)制提交渲染隊(duì)列:?

如果驅(qū)動(dòng)中緩存了3幀, 那延遲優(yōu)化就白做了…?

另外就是大家耳熟能詳?shù)腂ack Buffer(Double Buffer Rendering), 其實(shí)也會(huì)增加一點(diǎn)延遲, 不如省掉這一步, 即Front Buffer Rendering, 或者叫Direct Mode:?

參考資料

What is Motion-To-Photon Latency??
Optimizing VR Graphics with Late Latching?
VR Direct: How NVIDIA Technology is Improving the VR Experience?
Virtual Reality with AMD LiquidVR? Technology?
Lessons from Integrating the Oculus Rift into Unreal Engine 4?
Oculus Rift - How Does Time Warping Work??
Asynchronous Timewarp Examined

上一篇?下一篇

評(píng)論（6）

sat4722915196樓

感覺好吊啊

前天 13:37回復(fù)

vvsxr5樓

第一張圖好萌

2016-04-18 09:57回復(fù)

feng17902915434樓

搞智能的么？分析的透徹

2016-04-15 14:35回復(fù)

查看全部評(píng)論?????發(fā)表評(píng)論

我的熱門文章

• 我與SM不得不說的故事(一)
• C++與Flash的交互
• 強(qiáng)大的PropertyGrid
• 一個(gè)簡(jiǎn)單實(shí)用的SSAO實(shí)現(xiàn)
• WPF工具開發(fā): 第三庫選擇

相關(guān)博文

• thread Intel? Threading Building Blocks Integration Now Available to Unreal Engine 3 Licensees
• 虛幻Unreal Engine3完全解析
• 淺析Unreal Engine 3中的FName
• 一個(gè)實(shí)用的3-D游戲引擎實(shí)現(xiàn)方法
• 一個(gè)實(shí)用的3-D游戲引擎執(zhí)行方法翻譯
• Unity3D開發(fā)者快速上手Unreal Engine 4指南
• Game Engine Architecture by Jason Gregory16 實(shí)時(shí)游戲引擎架構(gòu)3
• 精通Unreal游戲引擎互動(dòng)出版網(wǎng)
• 參考 流行的游戲引擎 編輯器 unrealcryengineid_tek_5
• 3D游戲引擎FAQ 3 什么是剔除culling系統(tǒng)和LOD系統(tǒng)

總結(jié)

以上是生活随笔為你收集整理的一些VR延迟优化方法的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。