Attention: Here be dragons

This is the latest (unstable) version of this documentation, which may document features not available in or compatible with released stable versions of Godot.

Checking the stable version of the documentation...

內部算繪架構

本頁提供 Godot 4 內部算繪器設計的高階綜覽，內容不適用於舊版 Godot。

本頁旨在記錄為了最符合 Godot 的設計理念 所做的設計決策，同時也為新的算繪貢獻者提供起點。

若你有關於算繪內部原理的問題未在此解答，歡迎加入 Godot 貢獻者聊天室 的 #rendering 頻道提問。

備註

若你在理解本頁內容時遇到困難，建議先參閱 LearnOpenGL 等 OpenGL 教學資源。

現代低階 API（如 Vulkan、Direct3D 12、Metal）要能有效使用，需具備中等以上的高階 API（如 OpenGL、Direct3D 11）知識。幸好，貢獻者很少需要直接操作這些底層 API。Godot 的算繪器完全建立在 OpenGL 與 RenderingDevice 之上，後者是針對 Vulkan／Direct3D 12／Metal 的抽象層。

算繪方法

Forward+

這是一個採用*集群式*光源處理的前向算繪器（Forward Renderer）。

集群光照會以運算著色器將燈光分組到 3D 視錐體對齊的格點內。算繪時，像素會查詢其所在柵格受哪些燈光影響，僅針對這些燈光進行光照運算。

這種方法能大幅提升桌面硬體的算繪效能，但在行動裝置上效率則較低。

行動裝置

這是一個前向算繪器，採用傳統的單通道光照方法。在內部稱為 Forward Mobile。

本方法主要針對行動平臺設計，但同樣可於桌面平臺執行。其針對行動 GPU 進行優化，由於行動 GPU 在耗電、散熱與資料頻寬等條件和桌面 GPU 差異極大，因此對計算著色器支援通常有限甚至完全不支援。因此，行動裝置的算繪器僅採用光柵（頂點／片段）著色器。

行動 GPU 不同於桌面 GPU，會採用*基於圖塊（Tile-based）*的算繪方式。整張畫面不是一次處理，而是分割為可放入 GPU 內部高速記憶體的小圖塊。每個圖塊獨立算繪後再寫入目標紋理。這過程由圖形驅動自動完成。

這會對傳統算繪流程帶來瓶頸。桌面算繪通常先處理不透明幾何、再處理背景、再繪製透明物件，最後做後處理。每個步驟都必須將目前結果讀入圖塊記憶體、處理完再寫回。每個階段都需等所有圖塊完成後方可進入下一步。

The first important change in the mobile renderer is that the mobile renderer does not use the RGBA16F texture formats that the desktop (Forward+) renderer does. Instead, it uses an R10G10B10A2 UNORM texture format unless the rendering/viewport/hdr_2d project setting is enabled. This halves the bandwidth required and has further improvements, as mobile hardware often further optimizes for 32-bit formats. The tradeoff is that by default, the mobile renderer has limited HDR capabilities due to the reduced precision and maximum values in the color data.

When the rendering/viewport/hdr_2d project setting is enabled, the mobile renderer uses the same RGBA16F renderers as Forward+. This allows for full HDR support, but also increases bandwidth usage and can reduce performance on mobile GPUs or integrated graphics.

第二個重要改變是盡可能使用子通道（sub-pass）。這讓我們能在每個圖塊內一次完成所有算繪步驟，節省每階段之間頻繁讀寫圖塊的開銷。使用子通道的限制在於無法跨圖塊讀取相鄰像素，只能於單一圖塊範圍內運算。

子通道的這項限制，導致無法高效實作輝光、景深等效果。同樣地，若需讀取畫面紋理或深度紋理，也必須將算繪結果完整寫出，限制了子通道的應用。當這些功能啟用時，會混合使用子通道與一般通道，並導致明顯效能損失。

在桌面平臺，使用子通道對效能影響不大。但對於簡單場景，這個方法因複雜度低、頻寬需求小，仍可勝過 Forward+。在低階 GPU、整合型顯示晶片或 VR 應用上尤為明顯。

由於著重支援低階裝置，本方法不支援 SDFGI、體積霧和霧體積 等高階算繪功能，亦不支援多種後期處理效果。

相容性

備註

這是在使用 OpenGL 驅動時唯一可用的算繪方法。若使用 Vulkan、Direct3D 12 或 Metal 則不支援此方法。

這是一個傳統（非集群）的前向算繪器，內部稱為 GL Compatibility。其主要目的是支援不支援 Vulkan 的舊 GPU，但在新硬體上效率同樣不錯。特別是針對舊型與低階行動裝置做了優化，許多優化也適用於舊型或低階桌面，因此也是低效能電腦的好選擇。

與行動算繪器類似，相容性算繪器在 3D 算繪時也採用 R10G10B10A2 UNORM 紋理。不同之處在於顏色會經過色調映射並以 sRGB 格式儲存，因此不支援 HDR。這樣可省略色調映射階段，並以較低位元紋理避免明顯條帶問題。

相容性算繪器對帶光源的物件採用傳統單通道前向算繪，但對有陰影的光源則使用多通道算繪。具體來說，第一個通道可繪製多個無陰影光源及一個帶陰影的 DirectionalLight3D，其後每個通道最多各可繪製一個帶陰影的 OmniLight3D、SpotLight3D 及 DirectionalLight3D。有陰影的光源會以 sRGB 空間（非線性空間）混合光照，產生與無陰影光源不同的場景外觀，設計場景時須注意此差異。

由於本方法重點在低階裝置，因此不支援高階算繪功能（甚至比行動版還少），大多數後期處理效果亦不可用。

為什麼不採用延遲算繪？

前向算繪在性能與彈性之間通常能取得較佳平衡，特別是採用集群光照時。延遲算繪雖在部分情境下更快，但其彈性較低，且需特殊處理才能支援 MSAA。由於許多非寫實風格遊戲極需 MSAA，因此 Godot 4（如同 Godot 3）選擇前向算繪。

話雖如此，前向算繪器的部分處理*確實*採用延遲算繪手法，以在合適時進行最佳化。這尤其應用於 VoxelGI 與 SDFGI。

未來有可能開發集群延遲算繪器。此渲染器適用於需極致效能而可犧牲彈性的場景。

算繪驅動

Godot 4 支援以下圖形 API：

Vulkan

這是 Godot 4 的主要驅動，開發重心多集中於此。

Vulkan 1.0 為最低需求，若可用則將額外利用 Vulkan 1.1 及 1.2 功能。Godot 使用 volk 作為 Vulkan 載入器，並透過 Vulkan Memory Allocator 來管理記憶體。

Vulkan 驅動同時支援 Forward+ 與 Mobile 算繪方法 算繪方法。

Vulkan Context 建立：

Direct3D 12 Context 建立：

Direct3D 12

如同 Vulkan，Direct3D 12 驅動僅支援現代平臺，並專為 Windows 與 Xbox 設計（Vulkan 無法直接於 Xbox 使用）。

Direct3D 12 可同時用於 Forward+ 與 Mobile 算繪方法 算繪方法。

核心著色器 與 Vulkan 算繪器共用。 著色器會透過 Mesa NIR 將 SPIR-V 轉譯為 DXIL ，詳見 更多資訊 。

此驅動仍屬實驗性，僅於 Godot 4.3 及以後版本提供。 雖然 Direct3D 12 能支援 Windows 11 上專屬的 Direct3D 功能（如視窗化最佳化與自動 HDR），但大多數專案仍建議使用 Vulkan。詳情請參閱新增 Direct3D 12 支援的「pull request <https://github.com/godotengine/godot/pull/70315>」。

Metal

Godot 提供原生 Metal 驅動，適用於所有 Apple Silicon 硬體（macOS ARM）。與透過 MoltenVK 轉譯層相比，原生 Metal 驅動效能顯著提升，特別在受限於 CPU 的情境下更為明顯。

Metal 驅動可同時使用 Forward+ 與 Mobile 算繪方法 算繪方法。

核心著色器 與 Vulkan 算繪器共用。著色器透過 SPIRV-Cross 從 GLSL 轉譯為 MSL 。

Godot 也可透過 MoltenVK 支援 Metal 算繪，當原生 Metal 不可用時（如 x86 macOS）會自動切換使用。

Since Godot 4.7, Metal 4 is now used when supported. All Apple Silicon hardware supports Metal 4, but it must be running macOS 26 or later, or iOS 26 or later. Metal 3 is automatically used as a fallback on older macOS and iOS versions. See the pull request that introduced Metal 4 support for more information.

OpenGL

此驅動採用 OpenGL ES 3.0，主要針對不支援 Vulkan 的舊型與低階裝置。桌面版則以 OpenGL 3.3 Core Profile 執行（因大多數桌面驅動不支援 OpenGL ES），Web 匯出則用 WebGL 2.0。

你也可以在桌面平臺直接使用 OpenGL ES 3.0，只要於命令列加上 --rendering-driver opengl3_es 參數，但僅支援原生 OpenGL ES 的圖形驅動（如 Mesa）。

OpenGL 驅動僅支援 相容性 算繪方法。

核心著色器 與 Vulkan 算繪器完全不同。

由於此驅動主要鎖定低階裝置，因此不支援多項進階功能。

算繪驅動／方法總覽

目前可用的算繪 API 與算繪方法組合如下：

  • Vulkan + Forward+（macOS 與 iOS 可選用 MoltenVK）

  • Vulkan + Mobile（macOS 與 iOS 可選用 MoltenVK）

  • Direct3D 12 + Forward+

  • Direct3D 12 + Mobile

  • Metal + Forward+

  • Metal + Mobile

  • OpenGL + 相容性（Windows 與 macOS 可選用 ANGLE）

每種組合皆有其限制與效能特性。建議你在送出 Pull Request 前，盡量於所有算繪方法下測試你的變更。

RenderingDevice 抽象層

備註

OpenGL 驅動不使用 RenderingDevice 抽象層。

為了讓現代低階圖形 API 的複雜性更易於管理，Godot 採用自有的抽象層——RenderingDevice。

這表示在為現代算繪方法撰寫程式碼時，你實際上不會直接操作 Vulkan、Direct3D 12 或 Metal API。雖然這層仍比 OpenGL 更貼近底層，但可讓算繪器的開發更容易，因為 RenderingDevice 已為你封裝許多 API 相關的細節。其抽象層級與 WebGPU 類似。

Vulkan RenderingDevice 實作：

Direct3D 12 RenderingDevice 實作：

Metal RenderingDevice 實作：

核心算繪類別架構

下圖展示 Godot 的算繪類別結構，包含 RenderingDevice 抽象層：

../../_images/rendering_architecture_diagram.webp

View at full size

核心著色器

雖然 Godot 專案內的著色器多以 GLSL 為靈感的自訂語言 編寫，但核心著色器則直接以 GLSL 撰寫。

這些核心著色器於編譯時嵌入編輯器及匯出模板二進位檔。若你修改了這些 GLSL 著色器，必須重新編譯編輯器或匯出模板才能看到效果。

部分材質功能（如高度貼圖、折射與鄰近淡出）並非核心著色器的一部分，而是透過 BaseMaterial3D 的 Godot 著色器語言（非 GLSL）來實作。系統會依據啟用的功能，程序化產生對應的著色器程式碼。

按照慣例，檔名含 _inc 的著色器檔會被其他 GLSL 檔案 include，以利程式碼重用。這是利用標準 GLSL 前處理器實作。

警告

場景中所有材質（不論使用 BaseMaterial3D 或自訂著色器）都會用到核心材質著色器。因此，這些著色器必須盡量簡潔，以避免效能問題並確保著色器編譯速度。

在著色器中使用 if 分支會導致 VGPR 占用量增加，進而降低效能。即使同一幀所有像素的判斷結果都一樣，也會如此。

如在著色器中用 #if 前處理分支，會導致場景中需編譯的著色器版本數量暴增。最壞情況下，單一布林 #define 便可能使需要編譯的著色器數量加倍。有時可以用 Vulkan 的專用常數作為較快（但較有限）的替代方案。

這也代表 Godot 無論於核心著色器還是 BaseMaterial3D，要新增內建材質功能都具備高度門檻。雖然 BaseMaterial3D 可動態產生程式碼並僅針對啟用功能產生對應著色器，但專案若啟用多項功能仍會導致編譯更多著色器版本，複雜 3D 場景中會明顯增加編譯卡頓。

詳情請參閱「著色器排列問題 <https://therealmjp.github.io/posts/shader-permutations-part1/>」及「GPU 上的分支 <https://medium.com/@jasonbooth_86226/branching-on-a-gpu-18bfc83694f2>」部落格文章。

核心 GLSL 材質著色器：

材質著色器產生：

Forward+ 與 Mobile 算繪方法的其他 GLSL 著色器：

Compatibility 算繪方法的其他 GLSL 著色器：

2D 與 3D 算繪分離

備註

以下內容僅適用於 Forward+ 與 Mobile 算繪方法，在 Compatibility 模式下不適用。若使用 Compatibility 算繪器，可透過多重 Viewport 模擬分離，或用於執行 2D 解析度縮放。

2D 與 3D 會分別算繪到不同的緩衝區，因為 Godot 的 2D 算繪是在 LDR sRGB 空間下進行，而 3D 算繪則在 HDR 線性空間中。

2D 算繪使用的色彩格式為 RGB8；若 Viewport 啟用 Transparent 屬性則為 RGBA8。3D 算繪則採用 24 位元無符號標準化整數深度緩衝區，若硬體不支援 24 位深度，則以 32 位元有符號浮點。2D 算繪則不使用深度緩衝區。

3D 解析度縮放的方式會根據選擇雙線性縮放或 FSR 1.0 縮放而有所不同。若使用雙線性縮放，不會執行特殊放大著色器，而是將視窗紋理直接拉伸，並以線性取樣器顯示（過濾直接交由硬體處理）。這可最大化雙線性 3D 縮放的效能。

當解析度或縮放比例變更時，RenderSceneBuffersRD 的 configure() 函式會重新分配 2D／3D 緩衝區。

目前尚未支援動態解析度縮放，未來 Godot 版本計畫加入此功能。

2D 與 3D 算繪緩衝區配置 C++ 程式碼：

FSR 1.0：

2D 算繪技術

2D 燈光算繪以單通道進行，以提升大量燈光下的效能。

所有算繪方法都有 2D 批次處理以提升效能，當畫面上有大量文字時尤其明顯。

2D 算繪可開啟 MSAA 以自動處理線條和多邊形的抗鋸齒，但 FXAA 不會影響 2D 算繪，因為它在 2D 算繪開始前已計算完畢。Godot 的 2D 繪製方法（如 Line2D 節點或部分 CanvasItem 的 draw_*() 方法）會以三角帶與頂點色進行自家抗鋸齒，不需倚賴 MSAA。

若使用者著色器有需求，系統會自動產生代表 Viewport 內 LightOccluder2D 節點的 2D 簽名距離場。這可用於自訂著色器的多種效果（如 2D 全域照明），也可用來計算 2D 粒子碰撞。

2D SDF 產生 GLSL 著色器：

3D 算繪技術

Reverse Z

All of Godot's renderers use reverse Z. This means that the depth buffer is inverted, with 1.0 representing the near plane and 0.0 representing the far plane. This allows for better precision, especially at long distances.

批次與實例化

在 Forward+ 算繪器中，會使用 Vulkan 實例化將相同的、不透明或經 Alpha 測試的物件分組算繪以提升效能（Alpha 混合的物件則永遠不會做實例化）。這雖不如靜態網格合併快，但仍可讓個別實例被獨立剔除。

燈光、貼花與反射探查算繪

備註

目前 Compatibility 算繪器尚不支援貼花（Decal）算繪。

Forward+ 算繪器採用集群光照（Clustered Lighting），可讓你任意增加燈光數量；效能主要取決於燈光在螢幕的覆蓋範圍。若無陰影且佔螢幕面積小的燈光，幾乎不會造成效能負擔。

所有算繪方法都支援同時算繪最多 8 個定向光源（若多於一個光源啟用陰影，則陰影品質會降低）。

Mobile 算繪器採用單通道光照，每個 Mesh 資源最多受 8 個 OmniLight 與 8 個 SpotLight 影響（攝影機視野內總數分別上限為 256）。這些限制為硬編碼，無法在專案設定中調整。

Compatibility 算繪器採用混合單通道＋多通道光照。無陰影的燈光在單通道內算繪，有陰影的燈光則需多通道處理。這主要是為了行動裝置效能考量，因此若場景中同時存在大量投射陰影的燈光，效能不易線性擴展。建議每次攝影機視錐內僅保留少量陰影光源，且盡量分散，讓每個物件同時僅受 1～2 個陰影燈光影響。最大可見燈光數可於專案設定調整。

在這三種算繪方法中，無陰影的燈光運算成本遠低於有陰影的燈光。為了提升效能，只有當燈光本身或其半徑內物件變動時，才會更新燈光。Godot 目前尚未將靜態陰影與動態陰影算繪分離，未來版本計畫加入此功能。

Forward+ 算繪器也利用集群技術進行反射探查與貼花算繪。

Area lights make use of the Linearly Transformed Cosines technique.

陰影貼圖

Forward+ 與 Mobile 算繪方法都會使用 PCF 來處理陰影貼圖並產生柔和的半影。這兩種方法採用 vogel disk（渦格圓盤）取樣，可調整樣本數量並平順地切換陰影品質，而非固定 PCF 取樣方式。

Godot 亦支援 PCSS（百分比接近軟陰影），可產生更真實的半影效果。PCSS 僅於 Forward+ 算繪器中提供，因行動裝置效能無法負荷。PCSS 同樣使用 vogel disk 形狀的取樣核心。

此外，這兩種陰影貼圖技術都會針對每個像素旋轉取樣核心，以減輕取樣不足造成的偽影。

Compatibility 算繪器支援 DirectionalLight3D、OmniLight3D 及 SpotLight3D 的陰影貼圖。

時間性抗鋸齒（TAA）

備註

僅於 Forward+ 算繪器中提供，Mobile 與 Compatibility 算繪器不支援。

Godot 採用自訂的 TAA（時間性抗鋸齒）實作，基於 Spartan Engine <https://github.com/PanosK92/SpartanEngine> 舊版 TAA 實現。

時間性抗鋸齒需要運動向量支援。若運動向量未正確產生，則攝影機或物件移動時會出現重影。

運動向量於 GPU 端的主材質著色器中產生，會同時運行前一影格（含前一攝影機變換）與目前影格的頂點著色器，然後將其差異存於顏色緩衝區。

另外也可使用 FSR 2.2 作為升頻方案，內建自家時間性抗鋸齒演算法。Godot 的 FSR 2.2 是基於 RenderingDevice 抽象層重新實作，並非直接採用 AMD 官方程式碼。

TAA 解算：

FSR 2.2：

全域照明

備註

VoxelGI 與 SDFGI 僅於 Forward+ 算繪器中提供，Mobile 與 Compatibility 算繪器不支援。

LightmapGI 的*烘焙*僅於 Forward+ 與 Mobile 算繪器中提供，且只能於編輯器內操作（無法在匯出專案時進行）。LightmapGI 的*算繪*則由 Compatibility 算繪器支援。

Godot 支援體素式全域照明（VoxelGI）、有符號距離場全域照明（SDFGI），以及光照貼圖烘焙與算繪（LightmapGI）。這些技術可依需求同時應用。

光照貼圖烘焙會在 GPU 上以 Vulkan 運算著色器執行。GPU 版光照貼圖器實作於 LightmapperRD 類別，並繼承自 Lightmapper，故未來可新增更多光照貼圖法，也可讓 Godot 3.x 的 CPU 版光照貼圖器移植至 4.x，進而在 Compatibility 算繪器下實現光照貼圖烘焙。

全域照明（GI）核心 C++ 程式碼：

全域照明（GI）核心 GLSL 著色器：

光照貼圖器 C++ 程式碼：

光照貼圖器 GLSL 著色器：

景深

備註

僅於 Forward+ 與 Mobile 算繪器中提供，Compatibility 算繪器不支援。

Forward+ 與 Mobile 算繪器採用不同的景深（DOF）算繪方法，視覺效果也各異。這是為了最佳適配不同硬體的效能特性。Forward+ 採用運算著色器實作 DOF，Mobile 則以片段著色器（光柵）完成。

支援方形、六角形與圓形光斑（bokeh），順序由快至慢。開啟時間性抗鋸齒（TAA）時，也可選擇讓景深每幀抖動以改善視覺效果。

景深 C++ 程式碼：

景深 GLSL 著色器（運算用於 Forward+）：

景深 GLSL 著色器（光柵用於 Mobile）：

螢幕空間效果（SSAO、SSIL、SSR、SSS）

備註

僅於 Forward+ 算繪器中提供，Mobile 與 Compatibility 算繪器不支援。

Forward+ 算繪器支援螢幕空間環境光遮蔽（SSAO）、螢幕空間間接照明（SSIL）、螢幕空間反射（SSR）及次表面散射（SSS）。

SSAO 採用 Intel 的 ASSAO 實作（改寫為 Vulkan 版本）。SSIL 則以 SSAO 為基礎，提供高效能的間接照明。

當 SSAO 與 SSIL 同時啟用時，兩者部分運算資源會共用，以減少效能損耗。

SSAO, SSIL, and SSR are performed at half resolution by default to improve performance.

SSR makes use of a Hi-Z buffer to improve performance. This Hi-Z buffer is generated from the depth buffer in a compute shader. See the pull request that overhauled SSR for more information.

螢幕空間效果 C++ 程式碼：

螢幕空間環境光遮蔽 GLSL 著色器：

螢幕空間間接照明 GLSL 著色器：

螢幕空間反射 GLSL 著色器：

次表面散射 GLSL 著色器：

天空算繪

也參考

天空著色器

Godot 支援使用著色器進行天空背景算繪。輻射度貼圖（用於為 PBR 材質提供環境光及反射）會根據天空著色器自動更新。

SkyMaterial 資源（如 ProceduralSkyMaterial、PhysicalSkyMaterial、PanoramaSkyMaterial）會自動產生內建天空算繪著色器，與 BaseMaterial3D 為 3D 場景材質產生著色器機制類似。

詳細技術實作可參見「Godot 4.0 的自訂天空著色器 <https://godotengine.org/article/custom-sky-shaders-godot-4-0>」文章。

天空算繪 C++ 程式碼：

天空算繪 GLSL 著色器：

體積霧

備註

僅於 Forward+ 算繪器中提供，Mobile 與 Compatibility 算繪器不支援。

也參考

霧著色器

Godot 採用視錐體對齊體素（froxel）方法進行體積霧算繪，這與傳統後處理濾鏡不同，更具通用性，能適用於各種光源。體積霧亦可用著色器自訂行為，例如製作動畫效果或用 3D 紋理表示密度。

FogMaterial 資源會自動為 FogVolume 節點產生內建著色器，與 BaseMaterial3D 處理 3D 場景材質的方式相同。

詳細技術說明可參見「Godot 4.0 新增 Fog Volumes <https://godotengine.org/article/fog-volumes-arrive-in-godot-4>」一文。

體積霧 C++ 程式碼：

體積霧 GLSL 著色器：

遮蔽剔除

即使現代 GPU 能處理大量三角形，複雜場景中的繪製呼叫數（Draw Call）仍然可能成為瓶頸（即便使用 Vulkan、Direct3D 12 或 Metal 亦然）。

Godot 4 supports occlusion culling to reduce overdraw (when the depth prepass is disabled) and reduce vertex throughput. This is done by rasterizing a low-resolution buffer on the CPU using Embree. The buffer's resolution depends on the number of CPU threads on the system, as this is done in parallel. This buffer includes occluder shapes that were baked in the editor or created at runtime. The occlusion culling buffer is jittered by a small amount every frame to help reduce under-sampling artifacts, which would lead to false positives (objects getting occluded when they shouldn't be).

複雜遮蔽物會大幅增加 CPU 負擔，故於編輯器產生遮蔽物時可自動簡化其形狀。

Godot 的遮蔽剔除尚未支援動態遮蔽物，但 OccluderInstance3D 節點仍可切換可見性或移動。然而，這種方式若遇到複雜遮蔽物會極慢，因此建議僅對簡單形狀（如四邊形、立方體）於執行時更新遮蔽物。

這種以 CPU 為基礎的剔除方式，相較於門戶（Portals）房間法或 GPU 剔除方案有數項優勢：

  • 無需人工設置（但可自訂調整以達最佳效能）。

  • 無畫面延遲（Frame Delay）問題，這對於過場動畫、鏡頭切換或快速穿越牆壁的情境尤其有利。

  • 各種算繪驅動與方法間行為一致，不會因驅動或 GPU 硬體不同而出現不可預期行為。

遮蔽剔除是透過註冊遮蔽物網格完成，方法為放置 OccluderInstance3D 節點*（其本身連結 Occluder3D *資源）。RenderingServer 會於 RendererSceneOcclusionCull 中呼叫 Embree 執行遮蔽剔除。

遮蔽剔除 C++ 程式碼：

可見範圍（LOD）

Godot 支援手動建立的階層式細節層級（HLOD），可於屬性面板為每個 LOD 指定啟用距離。

在 RenderingSceneCull 類別中，_scene_cull() 與 _render_scene() 函式負責決定 LOD。每個 Viewport 可對同一網格採用不同 LOD（以正確支援分割畫面算繪）。

可見範圍 C++ 程式碼：

自動網格 LOD

ImporterMesh 類別用於編輯器內 3D 網格匯入流程。其 generate_lods() 函式會呼叫 meshoptimizer 函式庫自動產生多層 LOD。

LOD 網格產生時，也會同步產生陰影網格。這些陰影網格會將頂點焊接（無論平滑或材質），以降低陰影算繪所需的頂點數，提升陰影效能。

RenderingSceneCull 類別的 _render_scene() 函式會決定算繪時使用哪個網格 LOD。每個 Viewport 可對同一網格採用不同 LOD（以正確支援分割畫面算繪）。

網格 LOD 會根據畫面覆蓋率自動選擇，會考慮解析度與攝影機視角變化，無需使用者手動調整。閾值倍數可於專案設定調整。

為提升效能，陰影算繪與反射探查算繪可自訂專用的網格 LOD 閾值（可與主場景不同）。

匯入時網格 LOD 產生 C++ 程式碼：

網格 LOD 判定 C++ 程式碼：