我從去年開始做自己的引擎時就一直死磕一個問題一個普通3D渲染器到底要改多少地方才能讓它變成能在VR眼鏡里穩(wěn)定輸出畫面的渲染器當時我天真地以為無非就是把攝像機從一臺改成兩臺左右眼各渲染一遍而已。結(jié)果第一次把畫面推上眼鏡屏幕看到的是畸變到離譜的畫面、延遲到讓人頭暈的拖影我才意識到VR渲染和桌面渲染差的不是一點半點而是整條渲染管線的底層邏輯都要推翻重來。這個系列做到第十七篇正好輪到虛擬與混合現(xiàn)實的渲染算法這塊。我給自己定的內(nèi)部代號是vr-rd01rd是renderer的縮寫01代表這是第一版純光柵化渲染路徑不依賴任何商業(yè)VR SDK從算法層面把立體渲染、畸變矯正、時間扭曲這些東西一點一點摳明白。這篇博文就把vr-rd01里最核心的內(nèi)容整理出來聊清楚VR渲染里光柵化管線到底改了什么、為什么改、以及實際跑通的流程和踩坑。適合正在做自研引擎、或者想從渲染底層理解VR工作原理的朋友也適合那些用現(xiàn)成游戲引擎轉(zhuǎn)VR開發(fā)、但總被各種詭異現(xiàn)象搞到頭疼的人。1. VR光柵化和桌面渲染的分水嶺為什么把攝像機改成兩臺還不夠先放一個最反直覺的結(jié)論在一個桌面渲染器里把場景攝像機從一臺變成左右兩臺渲染出兩張圖然后拼在一起推到屏幕上——這個操作只完成了VR渲染大約30%的工作。剩下的70%全花在解決“VR設(shè)備為什么會讓你頭暈”這件事上。1.1 幀率、延遲與有效像素三座繞不開的大山桌面游戲普遍做到30幀就能玩動作游戲做到60幀已經(jīng)很順滑。但VR頭顯里的屏幕刷新率起步就是90Hz現(xiàn)在的設(shè)備普遍120Hz甚至144Hz。為什么因為人的前庭系統(tǒng)對頭部轉(zhuǎn)動極其敏感一旦畫面更新跟不上頭部運動大腦立刻產(chǎn)生強烈的暈動感。VR行業(yè)里有個共識從光子到運動photon-to-motion的延遲必須控制在20毫秒以內(nèi)超過這個數(shù)絕大多數(shù)人會在十分鐘內(nèi)開始不適。這20毫秒里包含什么傳感器讀取姿態(tài)耗時、CPU提交渲染命令耗時、GPU完成一幀繪制耗時、畸變矯正和掃描輸出耗時、最后把畫面真正點亮在屏幕像素上的時間。每個環(huán)節(jié)都要斤斤計較。桌面渲染里你寫個慢一點的后處理特效沒人管你但VR里哪怕多出3毫秒等待都會明晃晃反映在體驗上。還有有效像素這個坑。很多人看VR頭顯參數(shù)說單眼分辨率2560x1440覺得還挺清晰。實際上呢人眼通過透鏡看到的是光學(xué)放大后的畫面只有畫面中心區(qū)域像素利用率高四周因為透鏡函數(shù)扭曲等效像素密度直線下降。行業(yè)里普遍估算VR屏幕上有將近30%的像素是被浪費掉的。桌面渲染優(yōu)化看三角形數(shù)量和填充率VR渲染還得多看一項別把寶貴像素浪費在用戶根本看不清的區(qū)域。1.2 渲染循環(huán)的形態(tài)從“一幀一張圖”變成“一幀兩張圖加一次合成”桌面渲染的經(jīng)典循環(huán)是模擬更新一次攝像機采樣一次畫到后緩沖交換顯示。VR的循環(huán)則長這樣讀取頭顯最新姿態(tài)對“下一次顯示時刻”的姿態(tài)做預(yù)測用預(yù)測姿態(tài)分別更新左眼和右眼的視圖矩陣左右眼各做一次完整的場景繪制輸出到兩張獨立紋理對兩張紋理做畸變矯正和透鏡匹配合成為一張幀提交給顯示器等待垂直同步。這還只是最樸素的基礎(chǔ)版本真正產(chǎn)品級的引擎還會在步驟4和5之間插入異步時間扭曲ATW這樣的兜底機制。但vr-rd01的第一步就是先把1到5這條主鏈路用純光柵化算法跑通。我隨時在代碼里提醒自己這里每多一次不必要的渲染就是在跟用戶的大腦前庭作對。1.3 混合現(xiàn)實MR其實走的也是這條主干道做VR渲染算法經(jīng)常會碰到“虛擬與混合現(xiàn)實”被放在一起提。MR設(shè)備和VR設(shè)備的渲染差異主要在于MR多了一層“環(huán)境感知”和“視頻透視VST”的疊加。也就是說在光柵化渲染主干的最后合成階段MR需要把攝像頭采集的真實環(huán)境畫面先做校正再和你渲染出來的虛擬物體融合。這條路線不是另起爐灶反而更依賴干凈的左右眼合成流程——因為真實世界畫面一歪虛擬物體疊上去就完全穿幫。所以先把vr-rd01的立體渲染做扎實未來要接MR只是多接一路攝像頭紋理的問題。2. 立體視覺的第一塊基石左右眼非對稱透視投影矩陣立體感從哪來從兩眼看到畫面的差異來。人眼瞳孔距離IPD通常在58到68毫秒之間這個差別導(dǎo)致左右眼看到的物體位置有細微偏移大腦就根據(jù)這些偏移計算出深度。渲染端要做的事就是精確模擬這個偏移。2.1 而投影矩陣“非對稱”才是關(guān)鍵普通3D渲染的透視投影是標準對稱平截頭體視錐中心正好在觀察方向上。你把攝像機往右移半個瞳距就得到右眼視角往左移半個瞳距就得到左眼視角——這樣做出來的立體感其實是錯的。原因是實際頭顯里左右眼并不正對屏幕中心透鏡把屏幕分成左右兩個顯示區(qū)域每只眼睛看的是自己那片區(qū)域而且因為光學(xué)設(shè)計的原因眼球的光軸和屏幕法線不重合這就導(dǎo)致左眼看到的視錐是向左偏斜的右眼則向右偏斜。所以VR攝像機的投影矩陣必須是非對稱平截頭體。以左眼為例它的近裁剪面是偏的左邊界拉大右邊界縮小形成一個向左開口的截錐體。這才是真正模擬人眼觀察方式的做法。如果偷懶用標準對稱矩陣表現(xiàn)在畫面上的效果是垂直方向沒有立體感水平方向的立體感方向還是錯的看久了必暈。2.2 vr-rd01里怎么計算這個矩陣我實現(xiàn)了一份通用的非對稱透視矩陣構(gòu)建函數(shù)核心是把眼睛相對屏幕中心的位置換算成平截頭體邊界的偏移量。代碼大致是這樣mat4 buildVRProjectionMatrix(float eyeOffset, float nearPlane, float farPlane, float halfFovX, float halfFovY) { // 先算出對稱平截頭體的四個邊界 float left -halfFovX * nearPlane; float right halfFovX * nearPlane; float bottom -halfFovY * nearPlane; float top halfFovY * nearPlane; // 關(guān)鍵一步按照眼睛相對透鏡的偏移量把左右邊界整體平移 left eyeOffset; right eyeOffset; float m00 2.0f * nearPlane / (right - left); float m11 2.0f * nearPlane / (top - bottom); float m22 -(farPlane nearPlane) / (farPlane - nearPlane); float m23 -2.0f * farPlane * nearPlane / (farPlane - nearPlane); float m20 (right left) / (right - left); float m21 (top bottom) / (top - bottom); return mat4( m00, 0.0f, m20, 0.0f, 0.0f, m11, m21, 0.0f, 0.0f, 0.0f, m22, m23, 0.0f, 0.0f, -1.0f, 0.0f ); }調(diào)用的時候左眼傳eyeOffset -IPD * 0.5f右眼傳eyeOffset IPD * 0.5f。這里的數(shù)值單位要和場景坐標保持一致三個單位統(tǒng)一為米最省事。IPD一定要從設(shè)備參數(shù)或者用戶設(shè)置里讀取不能拍腦袋寫一個固定值——我用65毫米測過再換成一個64毫米的用戶細微的立體感差異就會跳出來。2.3 位置渲染之外還有一個深度方向的問題投影矩陣搞定了左右眼的橫向視差但立體的真實感還依賴焦點深度focus plane的設(shè)置。實際上VR屏幕是被透鏡固定在某個光學(xué)距離上的人眼看遠處物體時焦距發(fā)生變化理論上光柵化渲染管線的透視模型是無窮遠對焦的也就是焦點深度無限大。這和真實人眼完全不同所以即便渲染管線完全正確依然會有“輻輳調(diào)節(jié)沖突”導(dǎo)致的視覺疲勞。這個問題的根治現(xiàn)在各廠商都在研究光場渲染但短期內(nèi)光柵化的做法是把UI和重要交互元素盡量放在一個固定的光學(xué)深度上減少眼睛頻繁對焦的負擔。這就屬于“渲染算法跑通之后設(shè)計層面還要補課”的案例了。3. 畸變矯正讓光柵化渲染出來的畫面適配透鏡的光學(xué)缺陷VR頭顯里屏幕和眼睛之間隔著一組放大透鏡。透鏡讓畫面變大、視野變寬代價是生產(chǎn)出徑向畸變。二維屏幕上本來橫平豎直的網(wǎng)格線經(jīng)過透鏡成像后會變成桶形或枕形畸變。如果不做處理你看到的世界是彎的稍微轉(zhuǎn)動頭部就像掉進哈哈鏡。3.1 矯正思路先畫歪再被鏡片拉正畸變矯正的工程思路非常樸素我知道透鏡會把畫面扭曲成什么樣那我就提前把畫面扭曲成反方向。渲染的時候先做桶形預(yù)畸變讓圖像邊緣向內(nèi)收縮經(jīng)過透鏡放大之后邊緣正好被拉伸回來最終看到的畫面就是平的。桶形畸變和枕形畸變可以用徑向畸變模型描述。前面提到的光柵化流程畫完正常透視圖像后畸變矯正會在合成階段對圖像做一次采樣重映射。對每個輸出像素計算它對應(yīng)鏡頭中心的方向和距離再根據(jù)徑向畸變系數(shù)重新采樣輸入圖像。一段GLSL片段著色器就能完成預(yù)畸變的核心計算uniform sampler2D eyeTexture; uniform vec2 lensCenter; uniform vec2 screenCenter; uniform float distortionScale; uniform vec4 distortionParams; // 存放k1, k2, k3, k4 vec2 distortUV(vec2 uv) { vec2 centered uv - screenCenter; float r2 dot(centered, centered); float r4 r2 * r2; float r6 r4 * r2 * r2; float scale distortionParams.x distortionParams.y * r2 distortionParams.z * r4 distortionParams.w * r6; return lensCenter (centered * scale) * distortionScale; } void main() { vec2 srcUV distortUV(gl_FragCoord.xy / screenSize); gl_FragColor texture(eyeTexture, srcUV); }注意這里的distortionScale它等同于畸變矯正中的“預(yù)放大倍數(shù)”。因為畸變矯正會把有效像素往中心壓縮如果不放大邊緣區(qū)域會因為采樣不足出現(xiàn)像素空洞。加上這個縮放后實際渲染分辨率要比屏幕分辨率高出一截。我實測下來典型取值在0.85到1.15之間具體數(shù)值取決于頭顯鏡片設(shè)計只能靠對著網(wǎng)格標定拍攝一張準確的照片來推算。3.2 預(yù)計算形變網(wǎng)格性能立刻提升一個檔次你不可能每幀都對整張屏幕做逐像素多項式計算雖然GPU算這個不慢但再快也比不上“查表”。成熟方案是初始化時離線算好一張網(wǎng)格把每個輸出像素對應(yīng)的輸入紋理坐標預(yù)計算出來存成偏移紋素。渲染時只要一行紋理采樣連浮點運算都省了。這也是為什么我反復(fù)強調(diào)vr-rd01的階段劃分里畸變矯正必須獨立成層——因為它和場景復(fù)雜度完全無關(guān)只依賴鏡頭參數(shù)完全可以只算一次。另外畸變矯正階段有個經(jīng)常被忽略的問題左右眼畫面的畸變中心并不是屏幕的幾何中心而是各自透鏡的光學(xué)中心。這兩個中心之間通常存在一點偏移。直接用屏幕中分線當矯正中心邊緣銜接處會出重影。我踩過這個坑后來在初始化階段用了設(shè)備標定參數(shù)里的鏡頭中心坐標問題立刻消失。4. 異步時間扭曲兜住“渲染趕不上轉(zhuǎn)頭”的那一幀先做個小實驗戴著頭顯快速左右搖頭再看屏幕上的畫面。理論上渲染幀率如果跟上刷新率畫面應(yīng)該不卡不暈。但實際光照峰值下GPU繪制復(fù)雜的場景總有一幀跟不上這時候如果直接重復(fù)上一幀畫面用戶轉(zhuǎn)頭看到的畫面就會比頭部慢了整整一幀眩暈感瞬間送走你。異步時間扭曲Asynchronous Time WarpATW就是為了解決這個場景誕生的。它的核心思想是與其重復(fù)舊幀不如把舊幀的圖像根據(jù)最新的頭部姿態(tài)“扭曲”一下讓它盡可能貼合用戶當前看到的角度。4.1 時間扭曲的幾何學(xué)本質(zhì)ATW本質(zhì)上是一層極輕量的后處理。GPU渲染完一幀并完成畸變矯正后如果發(fā)現(xiàn)頭部姿態(tài)變了就利用新姿態(tài)計算一個旋轉(zhuǎn)矩陣對這個二維圖像做重投影。在數(shù)學(xué)上它假設(shè)場景絕大部分內(nèi)容是遠場的忽略視差造成的圖像變化只做旋轉(zhuǎn)補償。這一招厲害的地方在于成本極低一次紋理采樣加一次旋轉(zhuǎn)旋轉(zhuǎn)修正普通的移動級GPU也能在1毫秒內(nèi)完成整幀扭轉(zhuǎn)。需要注意的是ATW能兜住旋轉(zhuǎn)兜不住平移。頭部平移會導(dǎo)致近景物體的視差變化這是二維重投影即使旋轉(zhuǎn)也恢復(fù)不了的。所以ATW的正確使用姿勢是“應(yīng)急”而不是“常態(tài)化”。我見過一些數(shù)據(jù)產(chǎn)品級VR應(yīng)用里ATW貢獻了約20%的流暢度體驗但即使有它畫面依然會有邊緣撕裂的偽影。另一條工程上的做法是壓低渲染分辨率來提升主渲染的余量讓ATW只在極端幀率波谷才被觸發(fā)而不是每一幀都重度依賴。4.2 vr-rd01的插入位置和實現(xiàn)思路我在vr-rd01里把ATW放在了畸變矯正之后、提交掃描之前。實現(xiàn)方式用的是網(wǎng)格重投影把上一幀已經(jīng)完成畸變矯正的圖像綁定到一張全屏三角形網(wǎng)格上用最新的旋轉(zhuǎn)四元數(shù)更新網(wǎng)格頂點的投影坐標再重采樣渲染。這個方案實現(xiàn)成本低效果也穩(wěn)定。建議想深入移植的朋友按三個版本遞進先做“旋轉(zhuǎn)四元數(shù)修正版”它能解決90%的問題再做“網(wǎng)格翹曲版”解決畫面的邊界偽影最后才過渡到“深度感知重投影”這個版本把渲染管線的深度緩沖引入進來用深度offset補償一部分平移視差但開銷大很多在基礎(chǔ)光柵化這個階段先不碰。4.3 還有一個容易被忽略的“預(yù)測窗口”頭顯的姿態(tài)數(shù)據(jù)從傳感器傳到渲染線程是有延遲的可能10到20毫秒。如果你拿到姿態(tài)那一刻直接渲染等畫面真正顯示出來時用戶頭已經(jīng)轉(zhuǎn)到別處了。所以渲染循環(huán)里要引入姿態(tài)預(yù)測根據(jù)傳感器歷史軌跡外推一個“下次顯示時刻”的姿態(tài)。圖上很簡單但工程上要處理時間基準的同步——GPU渲染這一幀用了8毫秒還是12毫秒直接影響姿態(tài)預(yù)測要外推多遠。我處理這個問題時給每一幀都打上了時間戳并且記錄了上一幀的真實GPU耗時用滑動平均來預(yù)估當前幀耗時。實踐下來能把圖像的“飄感”削掉一大半。5. 從場景到屏幕把vr-rd01第一條可運行管線完整搭起來講完了上面三個原理塊這段就進入純流水賬式的實操。我用OpenGL作為光柵化后端因為它是暴露渲染管線各階段最直接的選擇能讓人看清每一步到底發(fā)生了什么。如果你用的是Vulkan階段一樣只是命令緩沖的提交方式不同。以下步驟是我在vr-rd01里一晚上跑通的完整順序。5.1 初始化階段采集設(shè)備參數(shù)這一步不能省。我把設(shè)備的屏幕分辨率、左右眼屏幕區(qū)域、鏡頭畸變系數(shù)k1/k2/k3/k4、光學(xué)中心偏移、瞳距IPD全部讀入一個HardwareParams結(jié)構(gòu)體。初始化時用這些參數(shù)生成畸變矯正網(wǎng)格建好左右眼各一張渲染紋理。紋理的尺寸建議設(shè)置成實際屏幕單眼分辨率的1.2倍以上給畸變矯正的位置偏移留余量。5.2 渲染循環(huán)階段左右眼各跑一遍完整光柵化主循環(huán)代碼如下while (running) { // 1. 預(yù)測姿態(tài)并分別構(gòu)建左右眼視圖矩陣 Quat predictedPose predictPose(headPose, currentFrameTime); mat4 leftView buildViewMatrix(predictedPose, -IPD * 0.5f, 0.0f); mat4 rightView buildViewMatrix(predictedPose, IPD * 0.5f, 0.0f); // 2. 渲染左眼到紋理 glBindFramebuffer(GL_FRAMEBUFFER, eyeFBO[0]); glViewport(0, 0, eyeWidth, eyeHeight); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); setViewProj(leftView, leftProj); drawScene(); // 3. 渲染右眼到紋理 glBindFramebuffer(GL_FRAMEBUFFER, eyeFBO[1]); glViewport(0, 0, eyeWidth, eyeHeight); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); setViewProj(rightView, rightProj); drawScene(); // 4. 畸變矯正合成單幀 compositeAndDistort(); // 5. 提交顯示 submitFrame(displayTexture); }每一幀都綁定兩次FBO、做兩次完整的場景光柵化這意味著場景里所有三角形都要被送去處理兩次頂點著色器跑兩遍圖元裝配做兩遍。有一次我圖省事想在頂點著色器里一次畫兩遍結(jié)果可讀性一塌糊涂。后來還是老老實實走兩遍管線畢竟清晰度比一兩毫秒的節(jié)省重要得多。5.3 合成階段如何把左右眼畫面拼到一塊屏幕上VR頭顯屏幕通常是一整塊左右眼畫面各自占據(jù)一半?yún)^(qū)域。這里的細節(jié)是畸變矯正合成階段的視口范圍要精確匹配屏幕實際顯示的左右眼區(qū)域并且采樣時要使用預(yù)計算的形變網(wǎng)格。合成階段用到兩張紋理的多次采樣但沒必要開MSAA對這些后處理目標做多重采樣樣點都浪費在透鏡邊緣了。我最終的做法是場景渲染目標開4x MSAA畸變合成的最終目標保持單樣本。這里順帶回應(yīng)一下熱詞里那個“vr渲染器切換cpu gpu模式”的問題。渲染器切CPU模式的問題在于CPU軟光柵化在桌面場景或許能跑但絕對無法達到VR要求的幀率和延遲指標。我的建議是在學(xué)習(xí)階段你可以用CPU軟渲染器驗證投影矩陣數(shù)學(xué)是否正確輸出兩張靜態(tài)圖貼在屏幕上對比但真要連上頭顯必須走GPU光柵化。CPU到GPU之間的切換不應(yīng)該發(fā)生在每幀內(nèi)部而是作為調(diào)試策略整體切換。5.4 驗證清單怎么確認每一步是對的這是我覺得最有用的部分。跑通之后別急著戴頭顯先做離線驗證。我把左右眼渲染結(jié)果并排導(dǎo)出成PNG然后用圖形工具疊加對比看同一物體的水平位移是否符合相對距離關(guān)系?；兂C正的驗證方法更絕把一張方格紋理掛在一個平面物體上通過畸變矯正渲染出來再用攝像頭拍屏幕上的最終畫面如果網(wǎng)格線是直的說明畸變參數(shù)沒寫錯。這套驗證流程花不了十分鐘時間能幫你擋住90%的“戴上去才發(fā)現(xiàn)暈到不行”的返工。6. 五大性能瓶頸與兩個經(jīng)典“亂碼”問題的實際排查錄跑通只是起點VR渲染真正拉開差距的是性能。這一節(jié)把vr-rd01調(diào)試過程中最有代表性的五個瓶頸和一個奇葩問題寫出來每個都帶排查思路不是單純給結(jié)論。6.1 像素過載為什么有效像素只剩七成畸變矯正有個副作用為了讓最終看到的畫面不露邊渲染目標的邊緣像素幾乎全被透鏡壓到用戶看不見的區(qū)域去了。因此實際有效像素率常常只有70%左右。你要展示的精細細節(jié)比如遠處物體上的文字如果被壓到邊緣區(qū)域就是純浪費。工程上兩個調(diào)整思路一是把畫面上最需要清晰度的區(qū)域約束到中心半徑范圍內(nèi)二是對邊緣區(qū)域采用LOD更低的模型。這不算夸張的優(yōu)化只要在兩眼的邊緣各砍400個三角形幀時間就能降下來1到2毫秒值得做。6.2 填充率和MSAA的取舍MSAA是抗鋸齒的好東西但在VR里有個特殊現(xiàn)象邊緣像素出現(xiàn)在每只眼睛各自不同的位置所以每只眼睛都要做一次抗鋸齒MSAA的開銷翻倍。我試過4x MSAA畫面確實干凈了但GPU在復(fù)雜場景下直接掉到80幀以下。最后我的選擇是場景簡單時用4x復(fù)雜時降到2x同時配合TAA實現(xiàn)時間維度上的邊緣平滑。這個方案比單純提升MSAA質(zhì)量要穩(wěn)得多。6.3 CPU和GPU不對稱導(dǎo)致的框架抖動VR應(yīng)用的幀時間預(yù)算比較緊張90Hz下一整幀的CPUGPU總耗時不能超過11.1毫秒。某些引擎的CPU提交成本很高場景里幾千個物體拆成上萬個繪制調(diào)用CPU用掉8毫秒GPU只剩3毫秒。這種狀態(tài)下哪怕GPU余量再大幀率照樣上不去。排查思路是逐個階段打時間戳CPU提交耗時、GPU執(zhí)行耗時、合成耗時。我發(fā)現(xiàn)過CPU耗時過高居然是因為著色器每次繪制前都在重新編譯變體這個坑不在渲染算法里卻在幀時間統(tǒng)計里尤為刺眼。6.4 一個“亂碼”問題的完整排查鏈路熱詞里提到的“godot引擎游戲亂碼”很多人會懷疑是渲染算法問題但我排查下來這類現(xiàn)象在VR相關(guān)項目里通常指向以下幾個固定原因按概率排序著色器編譯宏混亂導(dǎo)致輸出通道錯亂比如把深度值當成顏色輸出了屏幕后期效果節(jié)點的輸入綁定錯誤顯示的是未完成的舊紋理文本編碼問題——字體貼圖的圖集UV計算錯誤或者字符庫沒有正確加載呈現(xiàn)代理狀態(tài)殘留上一個Pass沒有恢復(fù)混合模式導(dǎo)致下一個Pass輸出異常。排查方法也固定打印每一幀的FBO紋理實際內(nèi)容先確認輸入紋理對不對再檢查著色器編譯錯誤日志有沒有未定義的宏或者閃爍的分支條件。絕大多數(shù)所謂“亂碼”都逃不出這四個框。渲染算法本身出問題的概率其實很低。6.5 “片源適配”為什么也不算渲染算法問題熱詞里還有“vr眼鏡3d電影片源”它其實觸到了另一個工程點市面上常見的立體影片是左右格式SBS或者上下格式而有一部分HMD設(shè)備只支持其中一種或者幀打包方式不對。當你把左右片源誤當成上下片源播放兩個畫面交替出現(xiàn)看起來就是“花屏”。這和渲染算法無關(guān)純粹是格式映射沒匹配上。但在自己做引擎的時候要留意你合成階段的輸出格式必須和屏幕面板支持的掃描方式一致否則再好的立體渲染也白搭。這些排查經(jīng)歷總結(jié)下來就是一句話VR渲染問題的根因九成在“數(shù)據(jù)的排布方式”不對而不是“算法本身”不對。所以排查時先查數(shù)據(jù)從哪來、往哪去再動算法。7. 最后說點我自己一直在用的調(diào)試心得vr-rd01這套基礎(chǔ)光柵化渲染路徑前前后后我調(diào)了快三周最大的感悟是不要一上來就戴頭顯。戴上頭顯的一瞬間你就失去了所有調(diào)試信息——眼睛看到的是合成后的最終畫面但如果畸變系數(shù)錯了、投影矩陣歪了、ATW沒生效你只會覺得頭暈或者畫面糊根本定位不了是哪一層出了問題。我的習(xí)慣是給渲染器的每個階段都設(shè)一個“導(dǎo)出開關(guān)”正常渲染、左右眼原始圖、畸變矯正后、ATW翹曲后分別可以導(dǎo)出到文件。調(diào)試時把這些圖導(dǎo)出來并排看一眼就能看出是哪層的鍋。特別是左右眼原始圖重疊之后如果物體邊緣有細微錯位那就是投影矩陣的瞳距或者非對稱參數(shù)出了問題如果邊緣是彎曲的那是畸變矯正如果感覺畫面整體粘滯那是ATW和預(yù)測窗口的問題。這套方法幫我縮短了大量調(diào)試時間。另外一個體積小但收益極高的操作在把每一幀提交給顯示之前畫一個十字掃描線到畫面邊緣用來肉眼判斷畫面刷新是否有跳幀。這個在現(xiàn)實設(shè)備上很難靠肉眼捕捉到但這個掃描線的位置能告訴你真正顯示到屏幕上的那一幀是哪一幀。有一個階段我的幀率在88Hz左右徘徊從統(tǒng)計數(shù)字上完全看不出問題但實際體驗就暈。畫了掃描線之后才發(fā)現(xiàn)有幾次合成器在等垂直同步時把舊幀重復(fù)掃描了這時候我再回頭修ATW問題才真正從根上解決。下一步我這個系列會往前推進到光照模型把Phong改成適用于VR亮度的HDR流程同時對比一下桌面渲染的HDR和VR渲染的HDR在色調(diào)映射上到底哪里不一樣。等vr-rd02做完我再回來寫一篇對比報告。 VR渲染光柵化管線全解析：立體投影、畸變矯正與時間扭曲
我從去年開始做自己的引擎時就一直死磕一個問題一個普通3D渲染器到底要改多少地方才能讓它變成能在VR眼鏡里穩(wěn)定輸出畫面的渲染器當時我天真地以為無非就是把攝像機從一臺改成兩臺左右眼各渲染一遍而已。結(jié)果第一次把畫面推上眼鏡屏幕看到的是畸變到離譜的畫面、延遲到讓人頭暈的拖影我才意識到VR渲染和桌面渲染差的不是一點半點而是整條渲染管線的底層邏輯都要推翻重來。這個系列做到第十七篇正好輪到虛擬與混合現(xiàn)實的渲染算法這塊。我給自己定的內(nèi)部代號是vr-rd01rd是renderer的縮寫01代表這是第一版純光柵化渲染路徑不依賴任何商業(yè)VR SDK從算法層面把立體渲染、畸變矯正、時間扭曲這些東西一點一點摳明白。這篇博文就把vr-rd01里最核心的內(nèi)容整理出來聊清楚VR渲染里光柵化管線到底改了什么、為什么改、以及實際跑通的流程和踩坑。適合正在做自研引擎、或者想從渲染底層理解VR工作原理的朋友也適合那些用現(xiàn)成游戲引擎轉(zhuǎn)VR開發(fā)、但總被各種詭異現(xiàn)象搞到頭疼的人。1. VR光柵化和桌面渲染的分水嶺為什么把攝像機改成兩臺還不夠先放一個最反直覺的結(jié)論在一個桌面渲染器里把場景攝像機從一臺變成左右兩臺渲染出兩張圖然后拼在一起推到屏幕上——這個操作只完成了VR渲染大約30%的工作。剩下的70%全花在解決“VR設(shè)備為什么會讓你頭暈”這件事上。1.1 幀率、延遲與有效像素三座繞不開的大山桌面游戲普遍做到30幀就能玩動作游戲做到60幀已經(jīng)很順滑。但VR頭顯里的屏幕刷新率起步就是90Hz現(xiàn)在的設(shè)備普遍120Hz甚至144Hz。為什么因為人的前庭系統(tǒng)對頭部轉(zhuǎn)動極其敏感一旦畫面更新跟不上頭部運動大腦立刻產(chǎn)生強烈的暈動感。VR行業(yè)里有個共識從光子到運動photon-to-motion的延遲必須控制在20毫秒以內(nèi)超過這個數(shù)絕大多數(shù)人會在十分鐘內(nèi)開始不適。這20毫秒里包含什么傳感器讀取姿態(tài)耗時、CPU提交渲染命令耗時、GPU完成一幀繪制耗時、畸變矯正和掃描輸出耗時、最后把畫面真正點亮在屏幕像素上的時間。每個環(huán)節(jié)都要斤斤計較。桌面渲染里你寫個慢一點的后處理特效沒人管你但VR里哪怕多出3毫秒等待都會明晃晃反映在體驗上。還有有效像素這個坑。很多人看VR頭顯參數(shù)說單眼分辨率2560x1440覺得還挺清晰。實際上呢人眼通過透鏡看到的是光學(xué)放大后的畫面只有畫面中心區(qū)域像素利用率高四周因為透鏡函數(shù)扭曲等效像素密度直線下降。行業(yè)里普遍估算VR屏幕上有將近30%的像素是被浪費掉的。桌面渲染優(yōu)化看三角形數(shù)量和填充率VR渲染還得多看一項別把寶貴像素浪費在用戶根本看不清的區(qū)域。1.2 渲染循環(huán)的形態(tài)從“一幀一張圖”變成“一幀兩張圖加一次合成”桌面渲染的經(jīng)典循環(huán)是模擬更新一次攝像機采樣一次畫到后緩沖交換顯示。VR的循環(huán)則長這樣讀取頭顯最新姿態(tài)對“下一次顯示時刻”的姿態(tài)做預(yù)測用預(yù)測姿態(tài)分別更新左眼和右眼的視圖矩陣左右眼各做一次完整的場景繪制輸出到兩張獨立紋理對兩張紋理做畸變矯正和透鏡匹配合成為一張幀提交給顯示器等待垂直同步。這還只是最樸素的基礎(chǔ)版本真正產(chǎn)品級的引擎還會在步驟4和5之間插入異步時間扭曲ATW這樣的兜底機制。但vr-rd01的第一步就是先把1到5這條主鏈路用純光柵化算法跑通。我隨時在代碼里提醒自己這里每多一次不必要的渲染就是在跟用戶的大腦前庭作對。1.3 混合現(xiàn)實MR其實走的也是這條主干道做VR渲染算法經(jīng)常會碰到“虛擬與混合現(xiàn)實”被放在一起提。MR設(shè)備和VR設(shè)備的渲染差異主要在于MR多了一層“環(huán)境感知”和“視頻透視VST”的疊加。也就是說在光柵化渲染主干的最后合成階段MR需要把攝像頭采集的真實環(huán)境畫面先做校正再和你渲染出來的虛擬物體融合。這條路線不是另起爐灶反而更依賴干凈的左右眼合成流程——因為真實世界畫面一歪虛擬物體疊上去就完全穿幫。所以先把vr-rd01的立體渲染做扎實未來要接MR只是多接一路攝像頭紋理的問題。2. 立體視覺的第一塊基石左右眼非對稱透視投影矩陣立體感從哪來從兩眼看到畫面的差異來。人眼瞳孔距離IPD通常在58到68毫秒之間這個差別導(dǎo)致左右眼看到的物體位置有細微偏移大腦就根據(jù)這些偏移計算出深度。渲染端要做的事就是精確模擬這個偏移。2.1 而投影矩陣“非對稱”才是關(guān)鍵普通3D渲染的透視投影是標準對稱平截頭體視錐中心正好在觀察方向上。你把攝像機往右移半個瞳距就得到右眼視角往左移半個瞳距就得到左眼視角——這樣做出來的立體感其實是錯的。原因是實際頭顯里左右眼并不正對屏幕中心透鏡把屏幕分成左右兩個顯示區(qū)域每只眼睛看的是自己那片區(qū)域而且因為光學(xué)設(shè)計的原因眼球的光軸和屏幕法線不重合這就導(dǎo)致左眼看到的視錐是向左偏斜的右眼則向右偏斜。所以VR攝像機的投影矩陣必須是非對稱平截頭體。以左眼為例它的近裁剪面是偏的左邊界拉大右邊界縮小形成一個向左開口的截錐體。這才是真正模擬人眼觀察方式的做法。如果偷懶用標準對稱矩陣表現(xiàn)在畫面上的效果是垂直方向沒有立體感水平方向的立體感方向還是錯的看久了必暈。2.2 vr-rd01里怎么計算這個矩陣我實現(xiàn)了一份通用的非對稱透視矩陣構(gòu)建函數(shù)核心是把眼睛相對屏幕中心的位置換算成平截頭體邊界的偏移量。代碼大致是這樣mat4 buildVRProjectionMatrix(float eyeOffset, float nearPlane, float farPlane, float halfFovX, float halfFovY) { // 先算出對稱平截頭體的四個邊界 float left -halfFovX * nearPlane; float right halfFovX * nearPlane; float bottom -halfFovY * nearPlane; float top halfFovY * nearPlane; // 關(guān)鍵一步按照眼睛相對透鏡的偏移量把左右邊界整體平移 left eyeOffset; right eyeOffset; float m00 2.0f * nearPlane / (right - left); float m11 2.0f * nearPlane / (top - bottom); float m22 -(farPlane nearPlane) / (farPlane - nearPlane); float m23 -2.0f * farPlane * nearPlane / (farPlane - nearPlane); float m20 (right left) / (right - left); float m21 (top bottom) / (top - bottom); return mat4( m00, 0.0f, m20, 0.0f, 0.0f, m11, m21, 0.0f, 0.0f, 0.0f, m22, m23, 0.0f, 0.0f, -1.0f, 0.0f ); }調(diào)用的時候左眼傳eyeOffset -IPD * 0.5f右眼傳eyeOffset IPD * 0.5f。這里的數(shù)值單位要和場景坐標保持一致三個單位統(tǒng)一為米最省事。IPD一定要從設(shè)備參數(shù)或者用戶設(shè)置里讀取不能拍腦袋寫一個固定值——我用65毫米測過再換成一個64毫米的用戶細微的立體感差異就會跳出來。2.3 位置渲染之外還有一個深度方向的問題投影矩陣搞定了左右眼的橫向視差但立體的真實感還依賴焦點深度focus plane的設(shè)置。實際上VR屏幕是被透鏡固定在某個光學(xué)距離上的人眼看遠處物體時焦距發(fā)生變化理論上光柵化渲染管線的透視模型是無窮遠對焦的也就是焦點深度無限大。這和真實人眼完全不同所以即便渲染管線完全正確依然會有“輻輳調(diào)節(jié)沖突”導(dǎo)致的視覺疲勞。這個問題的根治現(xiàn)在各廠商都在研究光場渲染但短期內(nèi)光柵化的做法是把UI和重要交互元素盡量放在一個固定的光學(xué)深度上減少眼睛頻繁對焦的負擔。這就屬于“渲染算法跑通之后設(shè)計層面還要補課”的案例了。3. 畸變矯正讓光柵化渲染出來的畫面適配透鏡的光學(xué)缺陷VR頭顯里屏幕和眼睛之間隔著一組放大透鏡。透鏡讓畫面變大、視野變寬代價是生產(chǎn)出徑向畸變。二維屏幕上本來橫平豎直的網(wǎng)格線經(jīng)過透鏡成像后會變成桶形或枕形畸變。如果不做處理你看到的世界是彎的稍微轉(zhuǎn)動頭部就像掉進哈哈鏡。3.1 矯正思路先畫歪再被鏡片拉正畸變矯正的工程思路非常樸素我知道透鏡會把畫面扭曲成什么樣那我就提前把畫面扭曲成反方向。渲染的時候先做桶形預(yù)畸變讓圖像邊緣向內(nèi)收縮經(jīng)過透鏡放大之后邊緣正好被拉伸回來最終看到的畫面就是平的。桶形畸變和枕形畸變可以用徑向畸變模型描述。前面提到的光柵化流程畫完正常透視圖像后畸變矯正會在合成階段對圖像做一次采樣重映射。對每個輸出像素計算它對應(yīng)鏡頭中心的方向和距離再根據(jù)徑向畸變系數(shù)重新采樣輸入圖像。一段GLSL片段著色器就能完成預(yù)畸變的核心計算uniform sampler2D eyeTexture; uniform vec2 lensCenter; uniform vec2 screenCenter; uniform float distortionScale; uniform vec4 distortionParams; // 存放k1, k2, k3, k4 vec2 distortUV(vec2 uv) { vec2 centered uv - screenCenter; float r2 dot(centered, centered); float r4 r2 * r2; float r6 r4 * r2 * r2; float scale distortionParams.x distortionParams.y * r2 distortionParams.z * r4 distortionParams.w * r6; return lensCenter (centered * scale) * distortionScale; } void main() { vec2 srcUV distortUV(gl_FragCoord.xy / screenSize); gl_FragColor texture(eyeTexture, srcUV); }注意這里的distortionScale它等同于畸變矯正中的“預(yù)放大倍數(shù)”。因為畸變矯正會把有效像素往中心壓縮如果不放大邊緣區(qū)域會因為采樣不足出現(xiàn)像素空洞。加上這個縮放后實際渲染分辨率要比屏幕分辨率高出一截。我實測下來典型取值在0.85到1.15之間具體數(shù)值取決于頭顯鏡片設(shè)計只能靠對著網(wǎng)格標定拍攝一張準確的照片來推算。3.2 預(yù)計算形變網(wǎng)格性能立刻提升一個檔次你不可能每幀都對整張屏幕做逐像素多項式計算雖然GPU算這個不慢但再快也比不上“查表”。成熟方案是初始化時離線算好一張網(wǎng)格把每個輸出像素對應(yīng)的輸入紋理坐標預(yù)計算出來存成偏移紋素。渲染時只要一行紋理采樣連浮點運算都省了。這也是為什么我反復(fù)強調(diào)vr-rd01的階段劃分里畸變矯正必須獨立成層——因為它和場景復(fù)雜度完全無關(guān)只依賴鏡頭參數(shù)完全可以只算一次。另外畸變矯正階段有個經(jīng)常被忽略的問題左右眼畫面的畸變中心并不是屏幕的幾何中心而是各自透鏡的光學(xué)中心。這兩個中心之間通常存在一點偏移。直接用屏幕中分線當矯正中心邊緣銜接處會出重影。我踩過這個坑后來在初始化階段用了設(shè)備標定參數(shù)里的鏡頭中心坐標問題立刻消失。4. 異步時間扭曲兜住“渲染趕不上轉(zhuǎn)頭”的那一幀先做個小實驗戴著頭顯快速左右搖頭再看屏幕上的畫面。理論上渲染幀率如果跟上刷新率畫面應(yīng)該不卡不暈。但實際光照峰值下GPU繪制復(fù)雜的場景總有一幀跟不上這時候如果直接重復(fù)上一幀畫面用戶轉(zhuǎn)頭看到的畫面就會比頭部慢了整整一幀眩暈感瞬間送走你。異步時間扭曲Asynchronous Time WarpATW就是為了解決這個場景誕生的。它的核心思想是與其重復(fù)舊幀不如把舊幀的圖像根據(jù)最新的頭部姿態(tài)“扭曲”一下讓它盡可能貼合用戶當前看到的角度。4.1 時間扭曲的幾何學(xué)本質(zhì)ATW本質(zhì)上是一層極輕量的后處理。GPU渲染完一幀并完成畸變矯正后如果發(fā)現(xiàn)頭部姿態(tài)變了就利用新姿態(tài)計算一個旋轉(zhuǎn)矩陣對這個二維圖像做重投影。在數(shù)學(xué)上它假設(shè)場景絕大部分內(nèi)容是遠場的忽略視差造成的圖像變化只做旋轉(zhuǎn)補償。這一招厲害的地方在于成本極低一次紋理采樣加一次旋轉(zhuǎn)旋轉(zhuǎn)修正普通的移動級GPU也能在1毫秒內(nèi)完成整幀扭轉(zhuǎn)。需要注意的是ATW能兜住旋轉(zhuǎn)兜不住平移。頭部平移會導(dǎo)致近景物體的視差變化這是二維重投影即使旋轉(zhuǎn)也恢復(fù)不了的。所以ATW的正確使用姿勢是“應(yīng)急”而不是“常態(tài)化”。我見過一些數(shù)據(jù)產(chǎn)品級VR應(yīng)用里ATW貢獻了約20%的流暢度體驗但即使有它畫面依然會有邊緣撕裂的偽影。另一條工程上的做法是壓低渲染分辨率來提升主渲染的余量讓ATW只在極端幀率波谷才被觸發(fā)而不是每一幀都重度依賴。4.2 vr-rd01的插入位置和實現(xiàn)思路我在vr-rd01里把ATW放在了畸變矯正之后、提交掃描之前。實現(xiàn)方式用的是網(wǎng)格重投影把上一幀已經(jīng)完成畸變矯正的圖像綁定到一張全屏三角形網(wǎng)格上用最新的旋轉(zhuǎn)四元數(shù)更新網(wǎng)格頂點的投影坐標再重采樣渲染。這個方案實現(xiàn)成本低效果也穩(wěn)定。建議想深入移植的朋友按三個版本遞進先做“旋轉(zhuǎn)四元數(shù)修正版”它能解決90%的問題再做“網(wǎng)格翹曲版”解決畫面的邊界偽影最后才過渡到“深度感知重投影”這個版本把渲染管線的深度緩沖引入進來用深度offset補償一部分平移視差但開銷大很多在基礎(chǔ)光柵化這個階段先不碰。4.3 還有一個容易被忽略的“預(yù)測窗口”頭顯的姿態(tài)數(shù)據(jù)從傳感器傳到渲染線程是有延遲的可能10到20毫秒。如果你拿到姿態(tài)那一刻直接渲染等畫面真正顯示出來時用戶頭已經(jīng)轉(zhuǎn)到別處了。所以渲染循環(huán)里要引入姿態(tài)預(yù)測根據(jù)傳感器歷史軌跡外推一個“下次顯示時刻”的姿態(tài)。圖上很簡單但工程上要處理時間基準的同步——GPU渲染這一幀用了8毫秒還是12毫秒直接影響姿態(tài)預(yù)測要外推多遠。我處理這個問題時給每一幀都打上了時間戳并且記錄了上一幀的真實GPU耗時用滑動平均來預(yù)估當前幀耗時。實踐下來能把圖像的“飄感”削掉一大半。5. 從場景到屏幕把vr-rd01第一條可運行管線完整搭起來講完了上面三個原理塊這段就進入純流水賬式的實操。我用OpenGL作為光柵化后端因為它是暴露渲染管線各階段最直接的選擇能讓人看清每一步到底發(fā)生了什么。如果你用的是Vulkan階段一樣只是命令緩沖的提交方式不同。以下步驟是我在vr-rd01里一晚上跑通的完整順序。5.1 初始化階段采集設(shè)備參數(shù)這一步不能省。我把設(shè)備的屏幕分辨率、左右眼屏幕區(qū)域、鏡頭畸變系數(shù)k1/k2/k3/k4、光學(xué)中心偏移、瞳距IPD全部讀入一個HardwareParams結(jié)構(gòu)體。初始化時用這些參數(shù)生成畸變矯正網(wǎng)格建好左右眼各一張渲染紋理。紋理的尺寸建議設(shè)置成實際屏幕單眼分辨率的1.2倍以上給畸變矯正的位置偏移留余量。5.2 渲染循環(huán)階段左右眼各跑一遍完整光柵化主循環(huán)代碼如下while (running) { // 1. 預(yù)測姿態(tài)并分別構(gòu)建左右眼視圖矩陣 Quat predictedPose predictPose(headPose, currentFrameTime); mat4 leftView buildViewMatrix(predictedPose, -IPD * 0.5f, 0.0f); mat4 rightView buildViewMatrix(predictedPose, IPD * 0.5f, 0.0f); // 2. 渲染左眼到紋理 glBindFramebuffer(GL_FRAMEBUFFER, eyeFBO[0]); glViewport(0, 0, eyeWidth, eyeHeight); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); setViewProj(leftView, leftProj); drawScene(); // 3. 渲染右眼到紋理 glBindFramebuffer(GL_FRAMEBUFFER, eyeFBO[1]); glViewport(0, 0, eyeWidth, eyeHeight); glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); setViewProj(rightView, rightProj); drawScene(); // 4. 畸變矯正合成單幀 compositeAndDistort(); // 5. 提交顯示 submitFrame(displayTexture); }每一幀都綁定兩次FBO、做兩次完整的場景光柵化這意味著場景里所有三角形都要被送去處理兩次頂點著色器跑兩遍圖元裝配做兩遍。有一次我圖省事想在頂點著色器里一次畫兩遍結(jié)果可讀性一塌糊涂。后來還是老老實實走兩遍管線畢竟清晰度比一兩毫秒的節(jié)省重要得多。5.3 合成階段如何把左右眼畫面拼到一塊屏幕上VR頭顯屏幕通常是一整塊左右眼畫面各自占據(jù)一半?yún)^(qū)域。這里的細節(jié)是畸變矯正合成階段的視口范圍要精確匹配屏幕實際顯示的左右眼區(qū)域并且采樣時要使用預(yù)計算的形變網(wǎng)格。合成階段用到兩張紋理的多次采樣但沒必要開MSAA對這些后處理目標做多重采樣樣點都浪費在透鏡邊緣了。我最終的做法是場景渲染目標開4x MSAA畸變合成的最終目標保持單樣本。這里順帶回應(yīng)一下熱詞里那個“vr渲染器切換cpu gpu模式”的問題。渲染器切CPU模式的問題在于CPU軟光柵化在桌面場景或許能跑但絕對無法達到VR要求的幀率和延遲指標。我的建議是在學(xué)習(xí)階段你可以用CPU軟渲染器驗證投影矩陣數(shù)學(xué)是否正確輸出兩張靜態(tài)圖貼在屏幕上對比但真要連上頭顯必須走GPU光柵化。CPU到GPU之間的切換不應(yīng)該發(fā)生在每幀內(nèi)部而是作為調(diào)試策略整體切換。5.4 驗證清單怎么確認每一步是對的這是我覺得最有用的部分。跑通之后別急著戴頭顯先做離線驗證。我把左右眼渲染結(jié)果并排導(dǎo)出成PNG然后用圖形工具疊加對比看同一物體的水平位移是否符合相對距離關(guān)系?；兂C正的驗證方法更絕把一張方格紋理掛在一個平面物體上通過畸變矯正渲染出來再用攝像頭拍屏幕上的最終畫面如果網(wǎng)格線是直的說明畸變參數(shù)沒寫錯。這套驗證流程花不了十分鐘時間能幫你擋住90%的“戴上去才發(fā)現(xiàn)暈到不行”的返工。6. 五大性能瓶頸與兩個經(jīng)典“亂碼”問題的實際排查錄跑通只是起點VR渲染真正拉開差距的是性能。這一節(jié)把vr-rd01調(diào)試過程中最有代表性的五個瓶頸和一個奇葩問題寫出來每個都帶排查思路不是單純給結(jié)論。6.1 像素過載為什么有效像素只剩七成畸變矯正有個副作用為了讓最終看到的畫面不露邊渲染目標的邊緣像素幾乎全被透鏡壓到用戶看不見的區(qū)域去了。因此實際有效像素率常常只有70%左右。你要展示的精細細節(jié)比如遠處物體上的文字如果被壓到邊緣區(qū)域就是純浪費。工程上兩個調(diào)整思路一是把畫面上最需要清晰度的區(qū)域約束到中心半徑范圍內(nèi)二是對邊緣區(qū)域采用LOD更低的模型。這不算夸張的優(yōu)化只要在兩眼的邊緣各砍400個三角形幀時間就能降下來1到2毫秒值得做。6.2 填充率和MSAA的取舍MSAA是抗鋸齒的好東西但在VR里有個特殊現(xiàn)象邊緣像素出現(xiàn)在每只眼睛各自不同的位置所以每只眼睛都要做一次抗鋸齒MSAA的開銷翻倍。我試過4x MSAA畫面確實干凈了但GPU在復(fù)雜場景下直接掉到80幀以下。最后我的選擇是場景簡單時用4x復(fù)雜時降到2x同時配合TAA實現(xiàn)時間維度上的邊緣平滑。這個方案比單純提升MSAA質(zhì)量要穩(wěn)得多。6.3 CPU和GPU不對稱導(dǎo)致的框架抖動VR應(yīng)用的幀時間預(yù)算比較緊張90Hz下一整幀的CPUGPU總耗時不能超過11.1毫秒。某些引擎的CPU提交成本很高場景里幾千個物體拆成上萬個繪制調(diào)用CPU用掉8毫秒GPU只剩3毫秒。這種狀態(tài)下哪怕GPU余量再大幀率照樣上不去。排查思路是逐個階段打時間戳CPU提交耗時、GPU執(zhí)行耗時、合成耗時。我發(fā)現(xiàn)過CPU耗時過高居然是因為著色器每次繪制前都在重新編譯變體這個坑不在渲染算法里卻在幀時間統(tǒng)計里尤為刺眼。6.4 一個“亂碼”問題的完整排查鏈路熱詞里提到的“godot引擎游戲亂碼”很多人會懷疑是渲染算法問題但我排查下來這類現(xiàn)象在VR相關(guān)項目里通常指向以下幾個固定原因按概率排序著色器編譯宏混亂導(dǎo)致輸出通道錯亂比如把深度值當成顏色輸出了屏幕后期效果節(jié)點的輸入綁定錯誤顯示的是未完成的舊紋理文本編碼問題——字體貼圖的圖集UV計算錯誤或者字符庫沒有正確加載呈現(xiàn)代理狀態(tài)殘留上一個Pass沒有恢復(fù)混合模式導(dǎo)致下一個Pass輸出異常。排查方法也固定打印每一幀的FBO紋理實際內(nèi)容先確認輸入紋理對不對再檢查著色器編譯錯誤日志有沒有未定義的宏或者閃爍的分支條件。絕大多數(shù)所謂“亂碼”都逃不出這四個框。渲染算法本身出問題的概率其實很低。6.5 “片源適配”為什么也不算渲染算法問題熱詞里還有“vr眼鏡3d電影片源”它其實觸到了另一個工程點市面上常見的立體影片是左右格式SBS或者上下格式而有一部分HMD設(shè)備只支持其中一種或者幀打包方式不對。當你把左右片源誤當成上下片源播放兩個畫面交替出現(xiàn)看起來就是“花屏”。這和渲染算法無關(guān)純粹是格式映射沒匹配上。但在自己做引擎的時候要留意你合成階段的輸出格式必須和屏幕面板支持的掃描方式一致否則再好的立體渲染也白搭。這些排查經(jīng)歷總結(jié)下來就是一句話VR渲染問題的根因九成在“數(shù)據(jù)的排布方式”不對而不是“算法本身”不對。所以排查時先查數(shù)據(jù)從哪來、往哪去再動算法。7. 最后說點我自己一直在用的調(diào)試心得vr-rd01這套基礎(chǔ)光柵化渲染路徑前前后后我調(diào)了快三周最大的感悟是不要一上來就戴頭顯。戴上頭顯的一瞬間你就失去了所有調(diào)試信息——眼睛看到的是合成后的最終畫面但如果畸變系數(shù)錯了、投影矩陣歪了、ATW沒生效你只會覺得頭暈或者畫面糊根本定位不了是哪一層出了問題。我的習(xí)慣是給渲染器的每個階段都設(shè)一個“導(dǎo)出開關(guān)”正常渲染、左右眼原始圖、畸變矯正后、ATW翹曲后分別可以導(dǎo)出到文件。調(diào)試時把這些圖導(dǎo)出來并排看一眼就能看出是哪層的鍋。特別是左右眼原始圖重疊之后如果物體邊緣有細微錯位那就是投影矩陣的瞳距或者非對稱參數(shù)出了問題如果邊緣是彎曲的那是畸變矯正如果感覺畫面整體粘滯那是ATW和預(yù)測窗口的問題。這套方法幫我縮短了大量調(diào)試時間。另外一個體積小但收益極高的操作在把每一幀提交給顯示之前畫一個十字掃描線到畫面邊緣用來肉眼判斷畫面刷新是否有跳幀。這個在現(xiàn)實設(shè)備上很難靠肉眼捕捉到但這個掃描線的位置能告訴你真正顯示到屏幕上的那一幀是哪一幀。有一個階段我的幀率在88Hz左右徘徊從統(tǒng)計數(shù)字上完全看不出問題但實際體驗就暈。畫了掃描線之后才發(fā)現(xiàn)有幾次合成器在等垂直同步時把舊幀重復(fù)掃描了這時候我再回頭修ATW問題才真正從根上解決。下一步我這個系列會往前推進到光照模型把Phong改成適用于VR亮度的HDR流程同時對比一下桌面渲染的HDR和VR渲染的HDR在色調(diào)映射上到底哪里不一樣。等vr-rd02做完我再回來寫一篇對比報告。