一些關於API層面的優化的VR渲染優化方法

2021-07-14 20:05:48 字數 1456 閱讀 7601

vr渲染需要左右眼兩幅不同的畫面,現在的大部分引擎都是暴力的直接渲染兩遍,這樣做想想效能也很難達到75fps(或90fps)

以oculus dk2為例,1920x1080@75fps,加上super sampling就變成了(ue4預設135%)2592x1458@75fps

如果是oculus的消費者版本和htc vive,解析度和重新整理率更是提公升到了2160x1200@90fps, 推薦配置是gtx980

以140%的super sampling為標準的話,只是color buffer每秒的資料量就有2160x1200x1.4x1.4x90x4 byte ≈ 1.7gb

這還沒算post processing裡的n多張render target和deferred rendering的gbuffer、light buffer

效能永遠是vr渲染的最具有挑戰的部分,本著能省一點是一點的思路,vr的渲染優化我總結了這麼一些:

雖然vr渲染需要左右兩幅畫面, 但是有很多效果是不需要畫兩次的:

api層面的優化, 有這麼幾個思路:

這只是減少一些api呼叫、state切換還有vertex處理的消耗,那瓶頸最大的pixel處理的消耗怎麼減少呢?

valve使用乙個stencil mesh, 剔除了17%的畫素

nvidia的gameworks也提供了一種方法, 叫multi-resolution shading,大概的思路就是邊緣的畫素經過變形後會損失一些,另外人眼對視線中心的畫素更敏感,所以周圍一圈可以降低解析度來渲染。通過這種方式可以節省25%到50的畫素

硬體方面,nvidia和amd都推出了雙gpu渲染的支援,即每塊gpu渲染乙隻眼睛的畫面。嗯,這一定是個陰謀,他們肯定在偷著樂:這下顯示卡不愁賣了

sony的ps vr在ps4的機能下實現了120fps。聽起來不可思議,實際是60fps通過reproject插值出中間幀,跟killzone的

temporal reprojection

和oculus的timewrap差不多原理

一些VR延遲優化方法

vr中的 延遲 特指 motion to photon latency 指的是從使用者運動開始到相應畫面顯示到螢幕上所花的時間.這中間經過了大概這麼幾個步驟 感測器採集運動輸入資料 採集到的資料進行過濾並通過線纜傳輸到主機 遊戲引擎根據獲取的輸入資料更新邏輯和渲染視口 提交到驅動並由驅動傳送到顯示卡...

Python安裝一些包時用到的系統層面的依賴

注 以下解決方法均以centos7.3環境 已配置好可用yum源 為例,其他作業系統可能會有所區別。安裝cffi報錯 c cffi backend.c 15 17 fatal error ffi.h no such file or directory 解決 執行 yum install libffi...

關於介面的一些思考

下面示例是模擬遊戲 憤怒的小鳥 的實現。叫的方式的介面 public inte ce shouttype 嗷嗷叫 public class aoshout implements shouttype 喳喳叫 public class zhashout implements shouttype 鳥的抽象...