搞渲染或者引擎底層相關的東西繞不開“投影矩陣”Projection Matrix這個東西。很多人藍圖里拖個節(jié)點就能拿到手但一旦遇到自定義渲染、深度重建、鏡像平面、特殊鏡頭效果就得親自跟矩陣打交道。這篇就按我實際摸過的路子把UE4里的投影矩陣掰開揉碎講一遍原理、獲取方式、實操案例和踩坑記錄都在里面了。1. 投影矩陣到底在做什么從三維場景到屏幕的那一步1.1 一張屏幕截圖背后的完整變換鏈路你先想一個問題場景里一個三維點憑什么最后能變成屏幕上某個像素中間其實經(jīng)歷了四步模型空間到世界空間世界空間到視圖空間也就是相機空間視圖空間到裁剪空間裁剪空間做透視除法變成NDC歸一化設備坐標最后視口變換映射到屏幕像素坐標。投影矩陣干的就是第三步把視圖空間里的視錐體Frustum壓成一個標準裁剪立方體。透視投影和正交投影的矩陣長不一樣本質區(qū)別就在“xyz怎么壓、w怎么參與”。透視投影里w分量會被設置成視圖空間的深度值這就是近大遠小的根源正交投影里w恒為1所以沒有透視縮放。很多人把“投影”理解成“把3D變成2D”這個說法不嚴謹。投影矩陣之后還沒有真正變成2D它只是把視錐體變成了裁剪空間的立方體真正的降維發(fā)生在透視除法除以w之后。1.2 為什么UE4要單獨擰出投影矩陣來講因為UE4在現(xiàn)代圖形API的約定上有自己的習慣。首先UE4是左手坐標系Z軸朝上相機朝X方向看這跟很多圖形學教材里的右手坐標系不一樣。其次UE4在絕大多數(shù)平臺上默認使用反向ZReversed-Z深度近裁剪面映射到深度1.0遠裁剪面映射到0.0這樣能大幅提升深度的浮點精度。這兩個習慣直接決定了矩陣長得跟教材上的公式不完全一樣。你如果直接拿一篇OpenGL教程里的矩陣塞進UE4大概率渲染出來是錯的。這也是項目里經(jīng)常有人“矩陣調不動”的真實原因——不是矩陣本身錯了是約定沒對齊。2. UE4里投影矩陣的實現(xiàn)細節(jié)與獲取方式2.1 UE4坐標系約定和矩陣存儲方式先把這個搞明白UE4的FMatrix在內存里是一維數(shù)組M[0][0]到M[3][3]但它在HLSL Shader里通常配合mul(float4(pos, 1.0), Matrix)這種寫法也就是行向量左乘矩陣。很多從OpenGL/OpenGL ES遷過來的人習慣mul(Matrix, vec4(pos, 1.0))拿到UE4就發(fā)現(xiàn)矩陣要轉置一下。這里有一個我實戰(zhàn)里養(yǎng)成的習慣碰到從網(wǎng)上扒來的投影矩陣公式先在CPU端打印一遍UE4自己的投影矩陣跟自己構造的矩陣做對比元素對不上就先轉置再對比別盲改Shader。UE4源碼里FMatrix的存儲雖然看著像行優(yōu)先但跟渲染管線的整體約定是配套的你要改的是自己那顆“外來矩陣”。2.2 FPerspectiveMatrix與反向ZUE4默認投影矩陣的真相UE4里常用的透視投影矩陣封裝有幾個FPerspectiveMatrix、FPerspectiveMatrixFov、FReversedZPerspectiveMatrix等。默認情況下場景視圖的投影矩陣是帶反向Z的也就是把原來的z映射公式反過來用。反向Z的好處在于浮點深度緩沖在近處精度高、遠處精度低而一般的深度線性化之后分母里有far值導致遠處精度浪費嚴重。反向Z把1.0留給近處0.0留給遠處配合浮點緩沖能把精度分布調得跟視覺敏感度正好匹配。理解了這一點你就知道為什么自己手動搭一個標準透視矩陣時場景里會出現(xiàn)離相機越遠越容易抖動花片的詭異現(xiàn)象——因為你的深度范圍和平臺默認的深度約定反了。2.3 C和藍圖中獲取投影矩陣的幾種實用姿勢藍圖層面上最常見的節(jié)點是“Project World Space To Screen Position”和“Get View Size”這兩個節(jié)點底層就是在用投影矩陣做換算。你不需要手動拼接但如果你需要的是原始矩陣值藍圖里沒有現(xiàn)成節(jié)點必須走C。在C里我常用的獲取位置是在FSceneView的ViewMatrices結構里。具體來說const FViewMatrices ViewMatrices View.ViewMatrices; const FMatrix ViewProjectionMatrix ViewMatrices.GetViewProjectionMatrix(); const FMatrix ProjectionMatrix ViewMatrices.GetProjectionMatrix(); const FMatrix ViewMatrix ViewMatrices.GetViewMatrix();FViewMatrices里還提供了GetInvProjectionMatrix()和GetInvViewProjectionMatrix()做深度重建或者反向投影時直接拿逆矩陣省得自己求逆。這里有個提醒FSceneView的投影矩陣默認包含了反向Z和平臺差異比如某些移動平臺甚至會用不對稱投影矩陣做單眼渲染所以一定不要用自己MakeProjectionMatrix的普通矩陣去替代它。3. 實操案例三個能落地能跑的投影矩陣玩法3.1 從屏幕像素反推世界坐標自己動手寫深度重建屏幕空間特效、自定義水波紋、后處理里做體積光經(jīng)常需要從當前像素的UV和深度反推世界坐標。思路很清楚拿到屏幕UV對應的NDC坐標再把NDC坐標乘上“視圖投影矩陣的逆”就能得到世界空間位置。在材質編輯器里我常用的Custom節(jié)點寫法大致長這樣float2 UV screenPosition * ViewSizeAndInvSize.zw; // 或者直接用 ScreenPosition 節(jié)點 float DeviceDepth GetSceneTextureUV(Parameters, 14).r; // 這里是場景深度非反向Z需額外處理 float4 ndc; ndc.x UV.x * 2.0 - 1.0; ndc.y (1.0 - UV.y) * 2.0 - 1.0; // 注意Y軸翻轉 ndc.z DeviceDepth; ndc.w 1.0; float4 worldPos mul(ndc, ResolvedView.InverseViewProjection); worldPos.xyz / worldPos.w;注意幾點設備的深度在非反向Z情況下需要做Depth Depth * 2.0 - 1.0的換算但在反向Z管線里深度值本身就是反的如果直接按標準公式來重建出來的位置會在相機身后亂跑。判斷自己項目是不是反向Z最快的辦法就是C里打印FReversedZPerspectiveMatrix之類的類型或者看第一個深度值在近裁剪面時是接近1還是接近0。這個案例做出來后你可以順便加一個“點擊屏幕高亮像素對應的世界坐標點”的小工具調試其他渲染問題時特別有用。3.2 用自定義寬高比和FOV做“鏡頭畸變”風格的投影某些演出效果或者游戲開場動畫里需要模擬魚眼鏡頭的透視畸變或者瞬間改變FOV營造速度感。直接修改主相機的FOV在藍圖里也能做但顆粒度太粗而且會導致UI、粒子等所有跟隨相機的東西都變。更好的方式是單獨構造一個投影矩陣用在特定的網(wǎng)格材質上或者做全屏后處理。舉個例子假設你要做一個“邊緣拉伸”的偽魚眼效果思路是改變透視除法時使用的w值。標準透視矩陣中w分量來自視圖空間的 -z也就是深度。你可以把矩陣最后一行改成“部分乘以一個系數(shù)這個系數(shù)依賴x或y”讓同一個像素在不同屏幕位置擁有不同的“縮放程度”。具體的矩陣改法不唯一我給出一個參數(shù)化的偽代碼思路// 假設 baseFov 90度scaleFactor 控制畸變強度 float fovRad FMath::DegreesToRadians(BaseFov); float cot 1.0f / FMath::Tan(fovRad * 0.5f); FMatrix DistortionProj FMatrix::Identity; DistortionProj.M[0][0] cot / AspectRatio; DistortionProj.M[1][1] cot; DistortionProj.M[2][2] -(Far Near) / (Far - Near); DistortionProj.M[2][3] -1.0f; DistortionProj.M[3][2] -2.0f * Far * Near / (Far - Near); // 關鍵讓 w 分量隨屏幕位置變化 DistortionProj.M[3][0] 0.3f; DistortionProj.M[3][1] 0.3f;上面這個矩陣第4行不再只由z決定而是摻入了x和y的信息透視除法的分母在不同位置就會不同從而出現(xiàn)桶形畸變。不過要提醒的是這種做法會讓影子和深度計算變得不可預測只適合后處理或非光照的裝飾性網(wǎng)格不適合一上來就替換主相機的投影矩陣。3.3 鏡像/傳送門效果里的反射視角投影矩陣的“歪用”做鏡面反射或傳送門效果時核心不只是“畫一個平面”而是讓相機相對于反射平面翻轉拿到一張正確的反射紋理。這里其實分兩步視圖矩陣要翻轉投影矩陣的裁剪面也要跟著調整才能把反射后視錐體以外的內容正確切掉。我在某個模擬項目里實現(xiàn)過一個簡版鏡面復制一個SceneView然后手工修改視圖矩陣的Y軸方向把相對于鏡面的觀察方向翻轉再把近裁剪面設置為鏡面到相機距離減去一個小的偏移避免反射內容穿到相機背后導致畫面撕裂。投影矩陣在這一步不需要大改但必須同步更新近遠裁剪面。如果只翻轉視圖矩陣不調整投影矩陣反射畫面里會出現(xiàn)物體被“砍掉一半”或者被背后遮擋的現(xiàn)象像是有一道看不見的墻。具體代碼我不全貼了核心是// 在CustomDepthPass或者SceneExtension里 NewViewMatrix SceneView-ViewMatrices.GetViewMatrix(); // 對鏡面平面做反射 NewViewMatrix.M[0][2] -NewViewMatrix.M[0][2]; NewViewMatrix.M[1][2] -NewViewMatrix.M[1][2]; NewViewMatrix.M[2][2] -NewViewMatrix.M[2][2]; NewViewMatrix.M[3][2] -NewViewMatrix.M[3][2]; ProjMatrix SceneView-ViewMatrices.GetProjectionMatrix(); // 保證近裁剪面不會比鏡面還近 float DistanceToMirror FVector::DotProduct(...); float NewNear FMath::Max(1.0f, DistanceToMirror - 5.0f); // 重新生成投影矩陣這里面的關鍵教訓是不要試圖手動“補”一個翻轉矩陣而是把視圖矩陣里跟鏡面法線相關的分量直接翻轉投影矩陣只改近裁剪面。這套路說白了就是“渲染半條命”的老玩法但放到UE4里細節(jié)特別多一幀里要處理的東西比想象中多。4. 投影矩陣常見問題與排查實錄4.1 畫面拉伸變形、深度閃爍、轉置迷局我整理了一張實操問題速查表做渲染相關調試時基本都能用到。現(xiàn)象最可能的原因怎么處理場景物體橫豎比例不對圓球變橢圓寬高比Aspect算錯投影矩陣使用了錯誤的ViewWidth/ViewHeight核對一下用到的分辨率是“視圖實際渲染分辨率”還是“視口UI分辨率”別混用遠處物體瘋狂閃爍近處正常深度精度不夠常見于near/far比例過大或者改了非反向Z矩陣調小Far/Near比值、開啟反向Z或者把深度緩沖改成浮點格式自定義Shader里位置對不上世界空間亂飛矩陣乘法順序錯了或者行列向量約定不一致先打印一次引擎原始矩陣和自定義矩陣逐元素對比確認行優(yōu)先還是列優(yōu)先渲染結果和藍圖節(jié)點算出來差一點點沒考慮平臺特定的裁剪矩陣比如VR單目渲染的不對稱投影獲取ProjectionMatrix時用FSceneView平臺裁剪的那一套不要自己重建深度閃爍這個我多說一點。假設你的Near是10Far是10000場景又比較大傳統(tǒng)的24位深度緩沖下只要相機稍微移動一點巨遠處的山體交界線就會瘋狂跳動。但如果你把Far改成5000Near保持10又會看不到很遠的東西。這種情況下有的團隊會改用“對數(shù)深度”或者“反向Z”。在UE4里最簡單的路徑反而是保證自己不要覆蓋引擎默認的投影矩陣因為默認矩陣已經(jīng)做了大部分優(yōu)化。4.2 用RenderDoc和斷點調試投影矩陣排查渲染問題我最推薦的思路是分三路走。第一路是抓RenderDoc。RenderDoc的Mesh Viewer可以看每一幀VS頂點著色器輸入的常量和輸出。如果發(fā)現(xiàn)網(wǎng)格跑飛到十萬八千里外直接看VS輸出的Clip Position跟CPU端的投影矩陣算出來的結果做比對很快就能鎖定是矩陣的問題還是Shader代碼的問題。第二路是在C里斷點打印。在SceneView的調DisplayDebug或自定義延遲渲染插件代碼里拿到ViewProjection矩陣然后打印關鍵元素比如M[2][2]和M[3][2]。反向Z矩陣和標準矩陣這兩個位置的值差異極其明顯一眼就能看出來你是在用默認矩陣還是一顆“野生矩陣”。第三路是寫一個像素調試器把深度值和屏幕UV編碼成顏色輸出到屏幕。算出來之后跟“Project World Space To Screen Position”節(jié)點結果交叉驗證如果偏差超過0.5像素那基本可以斷定是矩陣或者UV翻轉的問題不用去懷疑數(shù)學公式本身。5. 關于改動投影矩陣我想說的幾件小事5.1 別亂動SceneView的三條軍規(guī)每一條都是從實際項目里摔出來的第一條不要在渲染線程中途直接改SceneView-ViewMatrices的投影矩陣。那玩意兒是每幀同步好的讀的地方很多你中途改了后處理、陰影、粒子、UI全都跟著亂。真要改就在CameraManager或者SceneViewExtension里做一個副本然后在合適的位置覆蓋渲染用的矩陣。第二條凡是涉及深度重建、屏幕空間光線步進、自定義ShadowProjection的永遠要用“同一份”視圖投影矩陣。有時候你會因為省事分別拿GetProjectionMatrix()和GetViewMatrix()再拼一次但里面可能有一個已經(jīng)包含平臺差異一個沒包含最后差之毫厘謬以千里。第三條不要隨手復用其他項目的投影矩陣代碼。不同引擎的投影矩陣公式看著差不多但Z的范圍0到1還是-1到1、Y軸朝向向上還是向下、坐標系手性左手還是右手這三板斧只要有一個不一樣渲染出來就是完全不同的畫面。復制粘貼前先花十分鐘把MakeProjectionMatrix的參數(shù)和函數(shù)注釋看清楚。5.2 一正一反兩個實際項目踩坑記錄先講一個反面的。之前做某個跨平臺系統(tǒng)項目我在PC上自定義了一個投影矩陣做某種“非均勻縮放鏡頭”的特效PC上看起來一切正常。打包到某移動設備上一看畫面直接半邊全綠半邊全紅后來排查半天發(fā)現(xiàn)是移動端的旋轉屏幕邏輯會重新構造視口而我的自定義矩陣沒有跟著朝向一起旋轉導致投影矩陣和視口尺寸交叉錯位。從那以后我養(yǎng)成了一個習慣在項目里寫一個“矩陣鏈路自檢”的隱藏調試模式每幀打印視口寬高、投影矩陣前兩行至少能快速看出分辨率方向變了沒。再看一個正面的經(jīng)驗。另一個模擬類項目里需要在指定區(qū)域顯示一種“透視透明”的預覽效果當時不想改動材質和寫深度去排除物體索性直接構造了一個帶逆向深度偏移的小范圍透視矩陣把FOV故意調大讓邊緣物體輕微拉伸配合深度越小越清晰的邏輯最后效果既省開銷又可控。這個案例告訴我投影矩陣不只是一個“把3D變2D”的數(shù)學工具它本身就是一種可以靈活調用的表現(xiàn)資源關鍵在于你要知道自己在改哪一行、改了之后會影響哪些依賴它的功能。要在UE4里玩轉投影矩陣核心就是三件事搞懂約定手性、Z范圍、行列向量、掌握獲取/備份/替換的代碼路徑、最后習慣用RenderDoc一幀一幀地比對驗證。這三點做到了你基本就能駕馭絕大部分跟投影相關的奇怪需求了。