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...

Architettura interna di rendering

Questa pagina è una panoramica generale della progettazione del renderer interno di Godot 4. Non si applica alle versioni precedenti di Godot.

L'obiettivo di questa pagina è documentare le decisioni di progettazione prese per adattarsi al meglio alla filosofia di progettazione di Godot, fornendo allo stesso tempo un punto di partenza per i nuovi contributori al rendering.

Se hai domande sui componenti interni del rendering a cui non hai trovato risposta qui, sentiti libero di chiedere nel canale #rendering della Godot Contributors Chat.

Nota

Se hai difficoltà a comprendere i concetti di questa pagina, ti consigliamo di seguire un tutorial OpenGL come LearnOpenGL.

Le API moderne di basso livello (Vulkan/Direct3D 12/Metal) richiedono una conoscenza intermedia delle API di livello più alto (OpenGL/Direct3D 11) per utilizzarle efficacemente. Fortunatamente, i contributori raramente hanno bisogno di lavorare direttamente con le API di basso livello. I renderer di Godot sono basati interamente su OpenGL e RenderingDevice, che è la nostra astrazione su Vulkan/Direct3D 12/Metal.

Metodi di rendering

Forward+

Questo è un forward renderer che utilizza un approccio clusterizzato all'illuminazione.

L'illuminazione clusterizzata usa uno shader di calcolo per raggruppare le luci in una griglia 3D allineata al tronco. Quindi, in fase di rendering, i pixel possono cercare quali luci influenzano la cella della griglia in cui si trovano ed eseguire calcoli di luce solo per le luci che potrebbero influenzare quel pixel.

Questo approccio può velocizzare notevolmente le prestazioni di rendering sull'hardware desktop, ma è sostanzialmente meno efficiente sui dispositivi mobili.

Mobile

Questo è un forward renderer che utilizza un approccio tradizionale a passaggio singolo per l'illuminazione. Internamente, si chiama Forward Mobile.

Progettato per le piattaforme mobili, ma può funzionare anche sulle piattaforme desktop. Questo metodo di rendering è ottimizzato per avere buone prestazioni sulle GPU mobili. Le GPU mobili hanno un'architettura molto diversa rispetto alle GPU desktop, a causa dei loro vincoli relativi al consumo di batteria, al calore e ai limiti generali di banda per leggere e scrivere dati. Anche gli shader di calcolo hanno un supporto molto limitato oppure non sono supportati affatto. Di conseguenza, il renderer mobile utilizza esclusivamente shader raster (frammento/vertice).

A differenza delle GPU desktop, le GPU mobili eseguono un tile-based rendering. Invece di renderizzare l'intera immagine come un'unica unità, l'immagine è suddivisa in tasselli più piccoli che si adattano alla memoria interna più veloce della GPU mobile. Ogni tassello viene renderizzato e poi scritto nella texture di destinazione. Tutto questo avviene automaticamente sul driver grafico.

The problem is that this introduces bottlenecks in our traditional approach. For desktop rendering, we render all opaque geometry, then handle the background, then transparent geometry, then post-processing. Each pass will need to read the current result into tile memory, perform its operations and then write it out again. We then wait for all tiles to be completed before moving on to the next pass.

Il primo cambiamento importante nel renderer mobile è che esso non utilizza i formati di texture RGBA16F che il renderer desktop (Forward+) utilizza. Invece utilizza un formato di texture UNORM R10G10B10A2 a meno che l'impostazione del progetto rendering/viewport/hdr_2d non sia abilitata. Ciò dimezza la larghezza di banda richiesta e porta a ulteriori miglioramenti, poiché l'hardware mobile spesso ottimizza ulteriormente per i formati a 32 bit. Il compromesso è che, normalmente, il renderer mobile ha funzionalità di HDR limitate a causa della precisione ridotta e dei valori massimi nei dati dei colori.

Quando l'impostazione del progetto rendering/viewport/hdr_2d è abilitata, il renderer mobile utilizza gli stessi renderer RGBA16F di Forward+. Ciò consente il supporto HDR completo, ma aumenta anche l'uso della larghezza di banda e può ridurre le prestazioni sulle GPU mobili o sulla grafica integrata.

The second important change is the use of sub-passes whenever possible. Sub-passes allows us to perform the rendering steps end-to-end per tile saving on the overhead introduced by reading from and writing to the tiles between each rendering pass. The ability to use sub-passes is limited by the inability to read neighboring pixels, as we're constrained to working within a single tile.

This limitation of subpasses results in not being able to implement features such as glow and depth of field efficiently. Similarly, if there is a requirement to read from the screen texture or depth texture, we must fully write out the rendering result limiting our ability to use sub-passes. When such features are enabled, a mix of sub-passes and normal passes are used, and these features result in a notable performance penalty.

Sulle piattaforme desktop, l'uso dei sub-pass non avrà alcun impatto sulle prestazioni. Tuttavia, questo metodo di rendering può comunque offrire prestazioni migliori di Forward+ in scene semplici grazie alla sua minore complessità e al minor consumo di banda. Ciò è particolarmente evidente sulle GPU di fascia bassa, schede grafiche integrate o applicazioni in VR.

Given its low-end focus, this rendering method does not provide high-end rendering features such as SDFGI and Nebbia volumetrica e volumi di nebbia. Several post-processing effects are also not available.

Compatibilità

Nota

Questo è l'unico metodo di rendering disponibile quando si utilizza il driver OpenGL. Questo metodo di rendering non è disponibile quando si utilizza Vulkan, Direct3D 12 o Metal.

Questo è un forward renderer tradizionale (non clusterizzato). Internamente, si chiama GL Compatibility. È pensato per le vecchie GPU che non supportano Vulkan, ma funziona comunque molto efficientemente su hardware più recente. In particolare, è ottimizzato per dispositivi mobili più datati e di fascia bassa. Tuttavia, molte ottimizzazioni sono state mantenute, rendendolo un'ottima scelta anche per i desktop più datati e di fascia bassa.

Come il renderer Mobile, il renderer Compatibilità utilizza una texture UNORM R10G10B10A2 per il rendering 3D. A differenza del renderer Mobile, i colori sono mappati nei toni e memorizzati in formato sRGB, quindi non è supportato l'HDR. Questo evita la necessità di un passaggio di mappatura dei toni e ci consente di utilizzare la texture con meno bit senza notevole banding.

Il motore di rendering Compatibilità utilizza un approccio tradizionale a passaggio singolo per disegnare oggetti con luci, ma utilizza un approccio multi-passaggio per disegnare luci con ombre. Nello specifico, nel primo passaggio, può disegnare più luci senza ombre e fino a un solo DirectionalLight3D con ombre. In ogni passaggio successivo, può disegnare fino a un OmniLight3D, uno SpotLight3D e un DirectionalLight3D con ombre. Le luci con ombre influenzeranno la scena diversamente rispetto alle luci senza ombre, poiché l'illuminazione è fusa nello spazio sRGB anziché in quello lineare. Tale differenza di illuminazione influirà sull'aspetto della scena e bisogna tenerla presente quando si progettano scene per il motore di rendering Compatibilità.

Given its low-end focus, this rendering method does not provide high-end rendering features (even less so compared to Mobile). Most post-processing effects are not available.

Perché non il rendering differito?

Il forward rendering generalmente offre un compromesso migliore tra prestazioni e flessibilità, soprattutto quando si utilizza un approccio clusterizzato all'illuminazione. Sebbene il rendering differito possa essere più veloce in alcuni casi, è anche meno flessibile e richiede l'uso di hack per poter utilizzare l'MSAA. Poiché i giochi con uno stile artistico meno realistico possono beneficiare molto dall'MSAA, abbiamo scelto di utilizzare il forward rendering per Godot 4 (così come per Godot 3).

Detto questo, alcune parti del forward renderer sono eseguite con un approccio differito per consentire alcune ottimizzazioni quando possibile. Ciò vale per VoxelGI e SDFGI in particolare.

In futuro si potrebbe sviluppare un renderer differito clusterizzato. Questo renderer si potrebbe utilizzare in situazioni in cui le prestazioni sono preferibili alla flessibilità.

Driver di rendering

Godot 4 supporta le seguenti API grafiche:

Vulkan

Questo è il driver principale di Godot 4, su cui si è concentrata gran parte dello sviluppo.

Vulkan 1.0 è richiesto come linea di base, con le funzionalità opzionali di Vulkan 1.1 e 1.2 utilizzate quando disponibili. volk è utilizzato come caricatore Vulkan e Vulkan Memory Allocator è utilizzato per la gestione della memoria.

Entrambi i Metodi di rendering Forward+ e Mobile sono supportati quando si utilizza il driver Vulkan.

Creazione di contesto in Vulkan:

Creazione di contesto in Direct3D:

Direct3D 12

Come Vulkan, il driver Direct3D 12 è destinato solo alle piattaforme moderne. È progettato per funzionare sia con Windows sia con Xbox (mentre Vulkan non si può utilizzare direttamente su Xbox).

Entrambi i Metodi di rendering Forward+ e Mobile si possono utilizzare con Direct3D 12.

Shader principali sono condivisi con il motore di rendering Vulkan. Gli shader sono convertiti da SPIR-V a DXIL tramite Mesa NIR (ulteriori informazioni).

Questo driver è ancora sperimentale e disponibile solo in Godot 4.3 e versioni successive. Sebbene Direct3D 12 consenta il supporto di funzionalità esclusive a Direct3D su Windows 11, come le ottimizzazioni in finestra e l'Auto HDR, Vulkan è ancora consigliato per la maggior parte dei progetti. Per ulteriori informazioni, consultare la richiesta di pull che ha introdotto il supporto per Direct3D 12.

Metal

Godot fornisce un driver Metal nativo che funziona su tutti gli hardware Apple Silicon (macOS ARM). Rispetto all'utilizzo del livello di traduzione MoltenVK, questo è significativamente più veloce, soprattutto in scenari con un utilizzo intensivo della CPU.

Entrambi i Metodi di rendering Forward+ e Mobile si possono utilizzare con Metal.

Shader principali sono condivisi con il renderer Vulkan. Gli shader sono convertiti da GLSL a MSL tramite SPIRV-Cross.

Godot supporta anche il rendering Metal tramite MoltenVK, che è utilizzato come alternativa di riserva quando il supporto Metal nativo non è disponibile (ad esempio su macOS x86).

A partire da Godot 4.7, Metal 4 è utilizzato quando supportato. Tutto l'hardware Apple Silicon supporta Metal 4, ma si deve eseguire su macOS 26 o superiore, oppure iOS 26 o superiore. Metal 3 è utilizzato automaticamente come alternativa sulle versioni precedenti di macOS e iOS. Consultare la pull request che ha introdotto il supporto per Metal 4 per ulteriori informazioni.

OpenGL

Questo driver utilizza OpenGL ES 3.0 ed è destinato a dispositivi legacy e di fascia bassa che non supportano Vulkan. Il profilo OpenGL 3.3 Core è utilizzato sulle piattaforme desktop per eseguire questo driver, poiché la maggioranza dei driver grafici su desktop non supporta OpenGL ES. WebGL 2.0 è utilizzato per le esportazioni web.

È possibile utilizzare OpenGL ES 3.0 direttamente sulle piattaforme desktop passando l'argomento della riga di comando --rendering-driver opengl3_es, anche se questo funzionerà solo sui driver grafici che supportano OpenGL ES nativo (come Mesa).

È possibile utilizzare solo il metodo di rendering Compatibilità con il driver OpenGL.

Shader principali sono completamente diversi dal renderer Vulkan.

Molte funzionalità avanzate non sono supportate da questo driver, poiché è destinato principalmente ai dispositivi di fascia bassa.

Riepilogo dei driver/metodi di rendering

Attualmente sono possibili le seguenti combinazioni di API di rendering + metodo di rendering:

  • Vulkan + Forward+ (facoltativamente tramite MoltenVK su macOS e iOS)

  • Vulkan + Mobile (facoltativamente tramite MoltenVK su macOS e iOS)

  • Direct3D 12 + Forward+

  • Direct3D 12 + Mobile

  • Metal + Forward+

  • Metal + Mobile

  • OpenGL + Compatibilità (facoltativamente tramite ANGLE su Windows e macOS)

Ogni combinazione ha i suoi limiti e le sue caratteristiche sulle prestazioni. Assicurarsi di testare le modifiche su tutti i metodi di rendering, se possibile, prima di aprire una richiesta di pull.

Astrazione RenderingDevice

Nota

Il driver OpenGL non utilizza l'astrazione RenderingDevice.

Per rendere più gestibile la complessità delle API grafiche moderne di basso livello, Godot utilizza una propria astrazione chiamata RenderingDevice.

Ciò significa che quando si scrive codice per i metodi di rendering moderni, non si utilizzano direttamente le API di Vulkan, Direct3D 12 o Metal. Sebbene si tratti comunque di un livello più basso rispetto a un'API come OpenGL, rende più facile lavorare con il renderer, poiché RenderingDevice astrarrà molte peculiarità specifiche delle API. RenderingDevice presenta un livello di astrazione simile a quello di WebGPU.

Implementazione di RenderingDevice in Vulkan:

Implementazione di RenderingDevice in Direct3D 12:

Implementazione di RenderingDevice in Metal:

Architettura delle classi fondamentali di rendering

Questo diagramma rappresenta la struttura delle classi di rendering in Godot, inclusa l'astrazione RenderingDevice:

../../_images/rendering_architecture_diagram.webp

Visualizza a grandezza originale

Shader principali

Mentre gli shader nei progetti Godot vengono scritti attraverso un linguaggio personalizzato ispirato a GLSL, gli shader principali vengono scritti direttamente in GLSL.

Questi shader principali sono incorporati nei binari dell'editor e del modello di esportazione in fase di compilazione. Per vedere le modifiche apportate a questi shader GLSL, è necessario ricompilare il binario dell'editor o del modello di esportazione.

Alcune caratteristiche dei materiali, come l'height mapping, la rifrazione e la dissolvenza in prossimità, non fanno parte degli shader principali e sono eseguite nel BaseMaterial3D predefinito attraverso il linguaggio di shader di Godot (non GLSL). Questo avviene generando proceduralmente il codice dello shader richiesto in base alle caratteristiche abilitate nel materiale.

Per convenzione, i file shader con _inc nel nome sono inclusi in altri file GLSL per un migliore riutilizzo del codice. È utilizzata la pre-elaborazione GLSL standard pur di fare ciò.

Avvertimento

Gli shader dei materiali principali saranno utilizzati da tutti i materiali nella scena, sia con il BaseMaterial3D predefinito sia con gli shader personalizzati. Pertanto, è necessario che questi shader siano mantenuti il più semplici possibile per evitare problemi di prestazioni e garantire che la compilazione degli shader non diventi troppo lenta.

Se si utilizza la ramificazione if in uno shader, le prestazioni potrebbero diminuire poiché l'utilizzo di VGPR aumenterà nello shader. Ciò accade anche se tutti i pixel vengono valutati come true o false in un determinato frame.

If you use #if preprocessor branching, the number of required shader versions will increase in the scene. In a worst-case scenario, adding a single boolean #define can double the number of shader versions that may need to be compiled in a given scene. In some cases, Vulkan specialization constants can be used as a faster (but more limited) alternative.

This means there is a high barrier to adding new built-in material features in Godot, both in the core shaders and BaseMaterial3D. While BaseMaterial3D can make use of dynamic code generation to only include the shader code if the feature is enabled, it'll still require generating more shader versions when these features are used in a project. This can make shader compilation stutter more noticeable in complex 3D scenes.

Consultare i post del blog The Shader Permutation Problem e Branching on a GPU per ulteriori informazioni.

Shader dei materiali GLSL principali:

Generazione di shader per i materiali:

Altri shader GLSL per i metodi di rendering Forward+ e Mobile:

Altri shader GLSL per il metodo di rendering Compatibilità:

Separazione tra rendering 2D e 3D

Nota

Quanto segue è applicabile solo ai metodi di rendering Forward+ e Mobile, non a quello Compatibilità. È possibile utilizzare più Viewport per emulare questa funzionalità quando si utilizza il renderer Compatibilità o per cambiare lo scaling della risoluzione 2D.

Il 2D e 3D sono renderizzati su buffer separati: il rendering 2D in Godot è effettuato nello spazio sRGB LDR), mentre il rendering 3D utilizza lo spazio lineare HDR.

Il formato colore utilizzato per il rendering 2D è RGB8 (RGBA8 se la proprietà Trasparente sulla Viewport è abilitata). Il rendering 3D utilizza un buffer di profondità a 24 bit intero, senza segno e normalizzato, oppure a 32 bit in virgola mobile con segno se l'hardware non supporta un buffer di profondità a 24 bit. Il rendering 2D non utilizza un buffer di profondità.

Lo scaling della risoluzione 3D è effettuato diversamente a seconda che si utilizzi lo scaling bilineare o FSR 1.0. Quando si utilizza lo scaling bilineare, non viene eseguito alcuno shader di upscaling specifico. Invece, la texture della viewport viene stirata e visualizzata con un campionatore lineare (che fa sì che il filtraggio avvenga direttamente sull'hardware). Ciò consente di massimizzare le prestazioni dello scaling 3D bilineare.

La funzione configure() in RenderSceneBuffersRD riassegna i buffer 2D/3D quando cambia la risoluzione o la scala.

Lo scaling dinamico della risoluzione non è ancora supportato, ma è previsto in una futura versione di Godot.

Codice C++ per la configurazione del buffer di rendering 2D e 3D:

FSR 1.0:

Tecniche di rendering 2D

Il rendering delle luci 2D è effettuato in un unico passaggio per consentire prestazioni migliori con un elevato numero di luci.

Tutti i metodi di rendering utilizzano batching 2D per migliorare le prestazioni, il che è particolarmente evidente con molto testo sullo schermo.

L'MSAA può essere abilitato in 2D per fornire un antialiasing "automatico" di linee e poligoni, ma l'FXAA non influisce sul rendering 2D poiché è calcolato prima che il rendering 2D abbia inizio. I metodi di disegno 2D di Godot, come il nodo Line2D o alcuni metodi draw_*() di CanvasItem, forniscono un proprio metodo di antialiasing basato su strisce di triangoli e colori dei vertici, che non richiede l'MSAA per funzionare.

Se richiesto da uno shader utente, è generato automaticamente un SDF 2D che rappresenta i nodi LightOccluder2D nella viewport. Questo può servire per vari effetti negli shader personalizzati, come l'illuminazione globale 2D. Serve inoltre per calcolare le collisioni delle particelle in 2D.

Shader GLSL di generazione SDF 2D:

Tecniche di rendering 3D

Z inverso

Tutti i renderer di Godot utilizzano lo Z inverso. Ciò significa che il buffer di profondità è invertito, con 1.0 che rappresenta il piano vicino e 0.0 che rappresenta il piano lontano. Questo consente una migliore precisione, soprattutto a grandi distanze.

Batching and instancing

Nel renderer Forward+, l'istanziazione Vulkan è utilizzata per raggruppare il rendering di oggetti identici, opachi o sottoposti a test alfa, per migliorare le prestazioni. (Gli oggetti sottoposti a fusione alfa non sono mai istanziati.) Questa soluzione non è veloce quanto combinare le mesh statiche, ma consente comunque di effettuare il culling sulle single istanze.

Rendering di luce, decalcomanie e sonde di riflessione

Nota

Al momento, il rendering delle decalcomanie non è disponibile nel renderer Compatibilità.

Il motore di rendering Forward+ utilizza un illuminazione clusterizzata. Ciò consente di utilizzare tutte le luci desiderate; le prestazioni dipendono in gran parte dalla copertura nello schermo. Le luci senza ombre possono essere quasi senza costo se non occupano molto spazio sullo schermo.

Tutti i metodi di rendering supportano anche il rendering di un massimo di 8 luci direzionali contemporaneamente (anche se con una qualità delle ombre inferiore quando più di una luce ha le ombre abilitate).

Il renderer Mobile utilizza un approccio di illuminazione a passaggio singolo, con un limite di 8 OmniLight + 8 SpotLight per ogni risorsa Mesh (oltre a un limite di 256 OmniLight + 256 SpotLight nella vista della telecamera). Questi limiti sono codificati e non si possono cambiare nelle impostazioni del progetto.

Il renderer Compatibilità utilizza un approccio di illuminazione ibrido a passo singolo + multi-passaggio. Le luci senza ombre sono renderizzate in un singolo passaggio. Le luci con ombre sono renderizzate in più passaggi. Questo è necessario per motivi di prestazioni sui dispositivi mobili. Pertanto, le prestazioni non scalano bene con molte luci che proiettano ombre. Si consiglia di avere solo poche luci con ombre alla volta nel tronco della telecamera e di distribuirle in modo che ogni oggetto sia influenzato da 1 o 2 luci con ombre alla volta. Il numero massimo di luci visibili alla volta si può regolare nelle impostazioni del progetto.

In tutti e 3 i metodi, le luci senza ombre sono molto più performanti di quelle con ombre. Per migliorare le prestazioni, le luci vengono aggiornate solo quando vengono modificate esse o gli oggetti nel loro raggio. Godot attualmente non separa il rendering delle ombre statiche dal rendering delle ombre dinamiche, ma ciò è previsto in una versione futura.

Il clustering è utilizzato anche per il rendering delle sonde di riflessione e delle decalcomanie nel renderer Forward+.

Le luci d'area utilizzano la tecnica Linearly Transformed Cosines.

Mappatura delle ombre

Sia il metodo Forward+ sia il metodo Mobile utilizzano il filtro PCF per filtrare le mappe delle ombre e creare una penombra sfocata. Invece di utilizzare un pattern PCF fisso, questi metodi utilizzano un pattern a disco di Vogel, il che consente di cambiare il numero di campioni e di cambiarne gradualmente la qualità.

Godot supporta anche il percentage-closer soft shadows (PCSS) per renderizzare la penombra delle ombre in modo più realistico. Le ombre PCSS sono limitate al renderer Forward+, in quanto sono troppo esigenti per essere utilizzabili nel renderer Mobile. Anche PCSS utilizza un kernel a forma di disco di Vogel.

Inoltre, entrambe le tecniche di mappatura delle ombre ruotano il kernel pixel per pixel, al fine di attenuare gli artefatti di sottocampionamento.

Il renderer Compatibilità supporta la mappatura delle ombre per le luci DirectionalLight3D, OmniLight3D e SpotLight3D.

Antialiasing temporale

Nota

Disponibile solo nel renderer Forward+, non nei renderer Mobile o Compatibilità.

Godot utilizza un'implementazione personalizza del TAA, basata sulla vecchia implementazione del TAA di Spartan Engine.

L'antialiasing temporale richiede vettori di movimento per funzionare. Se i vettori di movimento non vengono generati correttamente, si verificherà un effetto ghosting quando la telecamera o gli oggetti si muovono.

I vettori di movimento vengono generati sulla GPU nello shader del materiale principale. Questo è fatto eseguendo il vertex shader corrispondente al frame renderizzato precedente (con la trasformazione della telecamera precedente) in aggiunta al vertex shader del frame attualmente renderizzato, poi memorizzando la differenza tra i due in un buffer di colore.

In alternativa, FSR 2.2 può essere utilizzato come soluzione di sovracampionamento che fornisce anche un proprio algoritmo di antialiasing temporale. FSR 2.2 è implementato sopra l'astrazione di RenderingDevice anziché utilizzare direttamente il codice di riferimento di AMD.

TAA resolve:

FSR 2.2:

Illuminazione globale

Nota

VoxelGI e SDFGI sono disponibili solo nel renderer Forward+, non nei renderer Mobile o Compatibilità.

La preparazione delle LightmapGI è disponibile solo nei renderer Forward+ e Mobile e si può eseguire solo all'interno dell'editor (non in un progetto esportato). Il rendering delle LightmapGI è supportato dal renderer Compatibilità.

Godot supporta l'illuminazione globale basata su voxel (VoxelGI), quella basata su signed distance field (SDFGI) e la preparazione e il rendering delle lightmap (LightmapGI). Queste tecniche si possono utilizzare simultaneamente, se desiderato.

La preparazione delle lightmap avviene sulla GPU attraverso shader di calcolo Vulkan. Il lightmapper basato sulla GPU è implementato nella classe LightmapperRD, la quale eredita dalla classe Lightmapper. Ciò consente di implementare lightmapper aggiuntivi, preparando la via per un futuro port del lightmapper basato sulla CPU presente in Godot 3.x. Ciò consentirebbe la preparazione delle lightmap mentre si utilizza il renderer Compatibilità.

Codice C++ fondamentale di GI:

Shader GLSL fondamentali di GI:

Codice C++ di Lightmapper:

Shader GLSL di Lightmapper:

Profondità di campo

Nota

Disponibile solo nel renderer Forward+ e Mobile, non nel renderer Compatibilità.

I renderer Forward+ e Mobile utilizzano approcci diversi per renderizzare la DOF (profondità di campo), con risultati visivi diversi. Ciò si fa per adattarsi al meglio alle caratteristiche prestazionali dell'hardware di destinazione. In Forward+, la DOF viene eseguita attraverso uno shader di calcolo. In Mobile, la DOF viene eseguita attraverso uno shader di frammento (raster).

Sono disponibili forme bokeh a rettangolo, esagono e cerchio (dalla più veloce alla più lenta). La profondità di campo si può facoltativamente cambiare a ogni frame per migliorarne l'aspetto quando l'antialiasing temporale è abilitato.

Codice C++ della profondità di campo:

Shader GLSL della profondità di campo (calcolo - utilizzato per Forward+):

Shader GLSL della profondità di campo (raster - utilizzato per Mobile):

Effetti nello spazio dello schermo (SSAO, SSIL, SSR, SSS)

Nota

Disponibile solo nel renderer Forward+, non nei renderer Mobile o Compatibilità.

Il renderer Forward+ supporta l'occlusione ambientale nello spazio dello schermo, l'illuminazione indiretta nello spazio dello schermo, i riflessi nello spazio dello schermo e il subsurface scattering.

SSAO utilizza un'implementazione derivata da ASSAO di Intel (convertito in Vulkan). SSIL è derivato da SSAO per fornire illuminazione indiretta ad alte prestazioni.

Quando sono abilitati sia SSAO sia SSIL, certe parti di SSAO e SSIL sono condivise per ridurre l'impatto sulle prestazioni.

Come predefinito, SSAO e SSIL sono eseguiti a metà risoluzione per migliorare le prestazioni.

L'SSR utilizza un buffer Hi-Z per migliorare le prestazioni. Questo buffer Hi-Z è generato dal buffer di profondità in uno shader di calcolo. Consultare la pull request che ha completamente rinnovato l'SSR per ulteriori informazioni.

Codice C++ per gli effetti nello spazio dello schermo:

Shader GLSL per l'occlusione ambientale nello spazio dello schermo:

Shader GLSL per illuminazione indiretta nello spazio dello schermo:

Shader GLSL per i riflessi nello spazio dello schermo:

GLSL per subsurface scattering:

Rendering del cielo

Vedi anche

Shader di cielo

Godot supporta l'utilizzo di shader per renderizzare lo sfondo di cielo. La mappa di radianza (utilizzata per fornire luce ambientale e riflessi per i materiali PBR) è aggiornata automaticamente in base allo shader del cielo.

Le risorse SkyMaterial come ProceduralSkyMaterial, PhysicalSkyMaterial e PanoramaSkyMaterial generano uno shader integrato per renderizzare il cielo. Ciò è simile a quanto fornito da BaseMaterial3D per i materiali delle scene 3D.

Un'implementazione tecnica dettagliata si può trovare nell'articolo Custom sky shaders in Godot 4.0.

Codice C++ del rendering del cielo:

Shader GLSL per il rendering del cielo:

Nebbia volumetrica

Nota

Disponibile solo nel renderer Forward+, non nei renderer Mobile o Compatibilità.

Vedi anche

Shader di nebbia

Godot supporta un approccio froxel (frustum-aligned voxel) per il rendering della nebbia volumetrica. A differenza di un filtro di post-elaborazione, questo approccio è più generico, in quanto può funzionare con qualsiasi tipo di luce. La nebbia può anche utilizzare shader per un comportamento personalizzato, il che consente di animarla o di utilizzare una texture 3D per rappresentarne la densità.

La risorsa FogMaterial genera uno shader integrato per i nodi FogVolume. È simile a quanto fornito da BaseMaterial3D per i materiali delle scene 3D.

Una spiegazione tecnica dettagliata si può trovare nell'articolo Fog Volumes arrive in Godot 4.0.

Codice C++ per nebbia volumetrica:

Shader GLSL per nebbia volumetrica:

Occlusion culling

Sebbene le GPU moderne riescano a disegnare tantissimi triangoli, il numero di draw call nelle scene complesse può comunque essere un collo di bottiglia (persino con Vulkan, Direct3D 12 e Metal).

Godot 4 supporta l'occlusion culling per ridurre l'overdraw (quando il depth prepass è disabilitato) e il rendimento dei vertici. Ciò avviene rasterizzando un buffer a bassa risoluzione sulla CPU tramite Embree. La risoluzione del buffer dipende dal numero di thread della CPU sul sistema, poiché questa operazione è eseguita in parallelo. Questo buffer include le forme di occlusione preparate nell'editor o create in fase di esecuzione. Il buffer dell'occlusion culling è leggermente oscillato a ogni frame per aiutare a ridurre gli artefatti di sottocampionamento, che porterebbero a falsi positivi (oggetti occlusi quando non dovrebbero esserlo).

Poiché gli occlusori complessi possono sforzare moltissimo la CPU, gli occlusori preparati si possono semplificare automaticamente quando vengono generati nell'editor.

L'occlusion culling di Godot non supporta ancora gli occlusori dinamici, ma è comunque possibile cambiare la visibilità dei nodi OccluderInstance3D o spostarli. Tuttavia, ciò risulterà lento quando si aggiornano occlusori complessi. Pertanto, in fase di esecuzione, è meglio aggiornare gli occlusori solo se hanno forme semplici, come quadranti o cuboidi.

Questo approccio basato sulla CPU ha alcuni vantaggi rispetto ad altre soluzioni, come portali e stanze oppure una soluzione di culling basata sulla GPU:

  • Non è richiesta alcuna configurazione manuale (ma è possibile regolarla manualmente per ottenere le migliori prestazioni).

  • Nessun ritardo di frame, il che è problematico nelle cutscene durante i cambi di inquadratura, o quando la telecamera si muove velocemente dietro un muro.

  • Funziona allo stesso modo su tutti i driver e metodi di rendering, senza comportamenti imprevedibili che dipendono dal driver o dall'hardware GPU.

L'occlusion culling è eseguito registrando le mesh occlusori, utilizzando i nodi di OccluderInstance3D (che a loro volta utilizzano le risorse di Occluder3D). RenderingServer esegue quindi l'occlusion culling chiamando Embree in RendererSceneOcclusionCull.

Codice C++ per occlusion culling:

Campo di visibilità (LOD)

Godot supporta il livello di dettaglio gerarchico (HLOD) creato manualmente, con distanze specificate dall'utente nell'ispettore.

In RenderingSceneCull, le funzioni _scene_cull() e _render_scene() sono quelle in cui avviene maggiormente la determinazione del LOD. Ogni viewport può renderizzare la stessa mesh con LOD diversi (per consentire al rendering a schermo diviso di apparire corretto).

Codice C++ di campo di visibilità:

LOD automatico di mesh

La classe ImporterMesh è utilizzata per la procedura di importazione delle mesh 3D nell'editor. La sua funzione generate_lods() gestisce la generazione attraverso la libreria meshoptimizer.

La generazione dei mesh LOD genera anche mesh di ombre allo stesso tempo. Queste sono mesh i cui vertici sono saldati a prescindere da smussatura e materiali. Ciò è utilizzato per migliorare le prestazioni di rendering delle ombre, riducendo il rendimento dei vertici necessari per renderizzarle.

La funzione _render_scene() della classe RenderingSceneCull determina quale LOD della mesh utilizzare durante il rendering. Ogni viewport può renderizzare la stessa mesh con LOD diversi (per consentire al rendering a schermo diviso di apparire corretto).

Il LOD della mesh viene scelto automaticamente secondo una metrica di copertura dello schermo. Questa tiene conto dei cambiamenti di risoluzione e del campo visivo della telecamera, senza richiedere l'intervento dell'utente. Il moltiplicatore di soglia si può regolare nelle impostazioni del progetto.

Per migliorare le prestazioni, anche il rendering delle ombre e delle sonde di riflessione scelgono le proprie soglie degli LOD di mesh (le quali possono essere diverse dal rendering della scena principale).

Codice C++ della generazione dei LOD di mesh all'importazione:

Codice C++ della determinazione dei LOD: