廣告位招商中 歡迎洽談

視錐體裁剪、遮擋剔除與LOD模型突變:3D遊戲引擎如何剔除不可見幾何體

365Finds Editorial
已收錄 11,430 篇 Wiki 文章

讓你的 AI 用上 365 Wiki

複製下方的提示詞,貼給你常用的 AI,然後直接提問。

下載完整版 Skill

先用提示詞體驗;經常使用時,安裝完整版 365Wiki Skill,以後無需重複複製。沒有常用 AI?Gemini、Microsoft Copilot 等網頁版也可以。

365Wiki Skill

引言:現代遊戲中的幾何渲染最佳化難題

在現代開放世界遊戲場景中——無論是《巫師3:狂獵》中茂密的原始森林、《電馭叛客2077》高密度的摩天大樓走廊,還是《地平線:期待黎明》廣袤的地貌——單影格場景往往包含數千萬個多邊形面片、數百個光源和數以吉位元組(GB)計的高解析度貼圖。如果圖形處理器(GPU)在每一影格都要對虛擬世界中的每一個三角形執行變換、光柵化和像素著色,任何現代旗艦顯示卡都會被龐大的計算量壓垮,影格率將跌至個位數。

即時3D渲染的核心本質是一門「做減法」的藝術。遊戲引擎之所以能夠維持60影格甚至更流暢的執行體驗,並非因為GPU渲染速度有多快,而是因為引擎在極早期階段就以極其激進的手段,剔除了絕大部分玩家肉眼根本看不到的幾何體。

這套剔除管線由三道核心技術防線組成:視錐體裁剪(View Frustum Culling)、**遮擋剔除(Occlusion Culling)與細節層次(LOD,Level of Detail)**系統。當這套體系協同運作良好時,能大幅削減CPU繪製呼叫(Draw Calls)和GPU光柵化負載;而一旦剔除過於激進,或由於鏡頭劇烈轉動導致資料流同步脫節,就會引發PC遊戲中最破壞沉浸感的視覺瑕疵之一——模型突變顯現(Geometry Pop-in)。

視錐體裁剪:剔除視野邊界之外的不可見圖元

視錐體裁剪是遊戲引擎在渲染管線中最先執行、也是計算成本最低的基礎可見性判定測試。

                   [攝影機觀察點 / 玩家眼睛]
                            / \
                           /   \
          近裁剪平面      /=====\
                         /   ▲   \
                        /    │    \   <--- 視錐體內部(執行渲染)
                       / [可見物件] \
                      /   模型網格   \
          遠裁剪平面     /=============\
                      /               \
       [視野左側剔除]   [視野深處剔除]   [視野右側剔除]

攝影機視錐體的幾何學定義

在3D圖形學中,攝影機所捕獲的可見空間並非一個無限延伸的長方體,而是一個被切去頂部的金字塔形台體,在幾何學上被稱為平截頭體(Frustum)。視錐體由六個數學平面嚴格界定:

  1. 近裁剪平面(Near Plane):比該平面距離攝影機更近的幾何體會被剔除,防止模型因破圖直接貼在虛擬鏡頭上產生破面。
  2. 遠裁剪平面(Far Plane):超出該極限距離的物體將被截斷,用於限定遊戲的最大視距。
  3. 左、右、上、下裁剪平面:由攝影機的視野角度(FOV)以及螢幕的長寬比(Aspect Ratio)決定。

包圍體與平面交叉測試

如果在CPU上逐個測試數百萬個頂點的三維坐標與六個平面的相對關係,同樣會造成極高的運算開銷。因此,遊戲引擎會為每個3D網格模型預先生成一個簡化包圍體(Bounding Volume):

在向DirectX、Vulkan或顯示卡驅動程式提交繪製呼叫(Draw Call)之前,引擎會透過極簡的點積運算,快速判斷模型的包圍球是否落在六個平面的外側。只要包圍體完全處於任一裁剪平面的外部,該網格就會被瞬間捨棄,GPU不會為其接收到任何一個頂點或渲染指令。

遮擋剔除:消除不可見像素的超額繪製(Overdraw)

雖然視錐體裁剪能夠清空玩家背後或鏡頭兩側的所有幾何體,但它無法解決**超額繪製(Overdraw)**的問題——即位於玩家正前方視錐體內、但被前景障礙物(如高牆、山體或門板)完全遮擋住的深層物體。

如果玩家正對著一座堅固的城堡石牆,而引擎依然在全力渲染石牆背後整座繁華城鎮的市集、NPC與鐵匠鋪,就會造成災難性的GPU光柵化資源浪費。遊戲引擎正是依靠**遮擋剔除(Occlusion Culling)**來消滅這些隱秘的繪製指令。

[玩家視點] ───► [巨大的城堡花崗岩石牆] ───X (視線阻斷)
                        │
                  (遮擋剔除判定測試)
                        │
              ┌─────────┴─────────┐
              ▼                   ▼
       [被遮擋的市集攤位]   [被遮擋的鐵匠工坊]
       (繪製呼叫完全扼殺)   (GPU光柵化開銷歸零)

三大主流遮擋剔除實現機制

  1. 潛在可見集(PVS)與房間-門廊系統(Cell-Portal):
    • 常見於早期的經典第一人稱射擊遊戲或現代室內走廊場景。
    • 地圖被人工或自動化分割為互不連通的獨立房間(Cell),房間之間透過門框或窗戶(Portal)相連。只要相連的門窗未處於當前視錐體內,門後的整座房間及其全部道具均不會觸發任何渲染。
  2. 硬體遮擋查詢(Hardware Occlusion Queries):
    • 引擎向GPU發送遠處物體的極簡粗糙包圍盒,並發出查詢:「這個包圍盒在深度測試(Z-Buffer)中是否有任何一個像素最終可見?」
    • 如果深度測試結果為0個像素可見,後續高精度網格便會在接下來的幾影格中被剔除。
    • 延遲陷阱:從GPU讀取查詢結果需要經過總線往返通訊,這往往帶來1至2影格的CPU-GPU同步延遲。當玩家猛轉滑鼠快速轉身時,可能導致本應可見的物體因延遲未來得及「解封」,產生肉眼可見的瞬時閃爍或延遲出現。
  3. 階層化Z緩衝(HZB,Hierarchical Z-Buffering)與計算著色器裁剪:
    • 虛幻引擎5(Unreal Engine 5)與現代高階引擎所普遍採用的終極方案。引擎將上一影格的深度緩衝區向下採樣成多級金字塔形的深度貼圖(HZB)。
    • GPU上的計算著色器(Compute Shader)並行並發地將數以萬計物體的包圍盒與該深度金字塔進行深度對比。由於全部計算在顯示記憶體內部完成,徹底擺脫了CPU-GPU管線停頓,能夠以極高的影格率支撐數以萬計的動態物件剔除。

細節層次(LOD)與模型突變(Pop-in)的物理成因

即使一個物體既在視錐體內、又沒有被障礙物擋住,如果它在遠方螢幕上只佔8個像素的寬度,強行渲染其擁有的10萬個頂點依然是一種巨大的算力浪費。為此,引擎構建了**細節層次(LOD)**體系。

離散LOD與虛擬化微多邊形幾何

模型突然出現(Pop-in)的根本瓶頸

玩家在遊戲中目睹高精度建築、樹木或紋理「突然跳入視野」(Pop-in),通常不是程式碼邏輯Bug,而是底層資產串流傳輸(Asset Streaming)子系統的硬體瓶頸所致:

  1. 硬碟I/O讀取延遲:傳統機械硬碟(HDD)或滿載的SATA固態硬碟無法及時在幾毫秒內將數百兆的模型資料從磁碟載入系統記憶體。
  2. PCIe總線與顯示記憶體上傳頻寬受阻:在極速旋轉視角時,大量資產的貼圖和頂點緩衝無法迅速透過PCIe通道推送至顯示記憶體。
  3. 遮擋預測滯後:玩家高速轉彎衝出掩體時,攝影機移動速度超過了HZB或遮擋查詢的失效判定速度,導致模型在解除遮擋標記前存在約數十毫秒的顯現延遲。

故障診斷矩陣:裁剪與LOD渲染瑕疵判定

準確辨識視覺缺陷的成因,有助於玩家與開發者針對性調整引擎設定或排查效能瓶頸:

視覺缺陷特徵關聯子系統底層技術機理應對調整方案
螢幕邊緣物體莫名消失破面視錐體裁剪(Frustum Culling)模型包圍盒計算過於嚴苛或FOV偏移不準調高引擎設定檔中的視野安全冗餘邊距
快速轉角時建築結構瞬時閃爍遮擋剔除(Occlusion Culling)硬體遮擋查詢帶來的CPU與GPU同步延遲在引擎中啟用階層化Z緩衝(HZB)取代傳統硬體查詢
貼近物體時模型細節生硬突變離散LOD切換(LOD Bias)引擎為節省Draw Call將LOD切換距離設得過短提升遊戲內的「可視距離品質」或「網格細節」檔位
前方十公尺處地面陰影突然重新整理級聯陰影貼圖(CSM)陰影分段裁切距離(Split Distance)臨界值過小調高畫質設定中的「陰影渲染距離」或級聯陰影層數
轉角後貼圖先模糊隨後才變清晰紋理Mipmap串流載入顯示記憶體耗盡或硬碟讀取受阻導致高精度Mip遲滯將遊戲遷移至NVMe高速固態;適度調低材質解析度以釋放顯存

即時渲染技術的本質是在有限的算力邊界內謀求視覺表現力的極致平衡。透過參考365Finds上的圖形架構分析,玩家與Mod開發者能夠深刻理解遊戲設定檔中視距、遮擋與串流傳輸參數的實際作用,在徹底消滅惱人的模型突變瑕疵的同時,守護流暢穩定的影格率與硬體壽命。

參考資料