All three renderers share the same scene graph and node API. The difference is entirely in how geometry gets lit, how many lights you can have active at once, and which GPU API backs the pipeline. Switching renderers requires only a project setting change — no scene restructuring — but shaders are not portable across the RenderingDevice-based renderers (Forward+, Mobile) and the Compatibility renderer.
Clustered forward renderer. Full feature set. Desktop and console targets only. The default for new Godot 4 projects.
Single-pass forward renderer. Reduced feature set tuned for tile-based mobile GPUs. Also usable on desktop for lightweight games.
OpenGL-based renderer. Lowest hardware bar. Required for Web exports. No compute shaders, no RenderingDevice access.
Key distinction: Forward+ and Mobile both use Vulkan (or equivalent modern API) and the RenderingDevice abstraction. Compatibility is a fundamentally different implementation — the Godot 3 renderer, forward-ported — and exists as a separate code path rather than a "lite mode" of the others.
This is where the three backends diverge most sharply. Forward+ uses a clustered light grid that subdivides the view frustum into 3D cells; each cell stores an index list of nearby lights. This lets you have hundreds of lights active simultaneously with no per-object limit. Mobile and Compatibility use a UBO-based approach where a maximum of 8 omni or spot lights affect any single object, and only 1 directional light is supported.
| Property | Forward+ | Mobile | Compatibility |
|---|---|---|---|
| Omni / spot lights | 512 per cluster cell | 8 per object (UBO) | 8 per object (UBO) |
| Directional lights | 4 | 1 | 1 |
| Global illumination | VoxelGI + SDFGI | None | None |
| LightmapGI | Full (with denoiser) | Full (with denoiser) | Partial (no denoiser) |
| ReflectionProbe | Static + dynamic | Static only | Static only |
Both GI methods are Forward+ exclusives. VoxelGI voxelizes a bounded scene region and works well for enclosed environments: rooms, corridors, indoor spaces. It produces stable, low-noise results but requires a defined probe region and is expensive to update dynamically. SDFGI (Signed Distance Field Global Illumination) operates on an infinite cascaded volume that follows the camera, making it suited to open-world scenarios. It is more expensive than VoxelGI and sensitive to scene density.
Neither method is available on Mobile or Compatibility. If you need any form of indirect lighting on those backends, LightmapGI is the only option.
Shadow quality differences are significant but not as dramatic as the lighting differences. All three renderers support PCF filtering and hard shadows. Forward+ additionally supports PCSS (Percentage Closer Soft Shadows), which produces contact-hardening shadows — sharper near the caster, softer at a distance — at a higher GPU cost.
| Property | Forward+ | Mobile | Compatibility |
|---|---|---|---|
| Shadow modes | Hard, PCF, PCSS | Hard, PCF | Hard, PCF |
| Directional PSSM splits | 4 | 2 | 2 |
| Max shadow atlas size | 16384 | 4096 | 4096 |
PSSM (Parallel Split Shadow Maps) controls how directional shadow resolution is distributed across depth. With 4 splits (Forward+) you can maintain sharp shadows both close to the camera and far away. With 2 splits (Mobile / Compatibility) you'll typically see a visible quality drop at mid-range distances unless the shadow distance is kept short.
Forward+ has the full post-processing stack. Mobile and Compatibility drop the screen-space effects that require reading from the depth buffer or running compute passes.
| Effect | Forward+ | Mobile | Compatibility |
|---|---|---|---|
| Screen-space | |||
| SSAO + SSIL | Yes | No | No |
| SSR | Yes | No | No |
| Volumetrics | |||
| Volumetric fog | Yes | No | No |
| FogVolume nodes | Yes | No | No |
| Camera / image effects | |||
| Depth of field | Yes | Yes | Yes |
| Glow / bloom | Full (bicubic upsample) | Limited | Limited |
| Procedural sky shader | Yes | Yes | Yes |
| Adjustments (color correction) | Yes | Yes | Yes |
TAA (Temporal Anti-Aliasing) is Forward+ only. It produces the cleanest results on geometry edges and on specular highlights, but introduces ghosting on fast-moving objects if not tuned. Mobile and Compatibility fall back to MSAA (multisampling) and FXAA (screen-space post-process).
| Method | Forward+ | Mobile | Compatibility |
|---|---|---|---|
| MSAA | 2×, 4×, 8× | 2×, 4× | 2×, 4×, 8× |
| TAA | Yes | No | No |
| FXAA | Yes | Yes | Yes |
On tile-based mobile GPUs, MSAA is relatively cheap because it resolves within the tile before writing to main memory. Forward+'s MSAA runs on desktop-class hardware where multisampling is more expensive, making TAA the preferred option for high-quality anti-aliasing there.
Shaders are not portable between the RenderingDevice-based renderers and Compatibility. Forward+ and Mobile compile shader source to SPIR-V for Vulkan; Compatibility compiles to GLSL 3.30 or ESSL 3.00. The high-level shader syntax looks similar, but the available built-ins, the lighting model hooks, and supported features differ.
| Capability | Forward+ | Mobile | Compatibility |
|---|---|---|---|
| Shader backend | SPIR-V (Vulkan) | SPIR-V (Vulkan) | GLSL 3.30 / ESSL 3.00 |
| Compute shaders | Yes | Yes | No |
| RenderingDevice API | Yes | Yes | No |
| GPU particles | Yes (compute) | Yes (compute) | No (CPU fallback) |
| Shader portability (Forward+ ↔ Mobile) | Yes | Yes | No |
The RenderingDevice API gives you direct access to GPU buffers, pipelines, and barriers. You can write custom render passes, readback data to the CPU, and use compute for general-purpose GPU work. None of this is available in Compatibility — it exposes only what OpenGL 3.3 exposes.
GPU particle note: In Compatibility, GPUParticles3D nodes fall back silently to CPU simulation. For large particle systems this is a significant performance difference. If particles are a core part of your game, this is a real cost to switching to Compatibility.
| Platform | Forward+ | Mobile | Compatibility |
|---|---|---|---|
| Windows / Linux / macOS | Yes | Yes | Yes |
| Android | No | Yes (primary target) | Yes |
| iOS | No | Yes (Metal) | Yes |
| Web (HTML5) | No | Limited (WebGL2 path) | Yes (primary target) |
| Min GPU requirement | Vulkan 1.0 capable | Vulkan 1.0 / GLES3 | OpenGL 3.3 / GLES3 2.0 |
For Web exports, Compatibility is the correct choice. Forward+ has no WebGL path. Mobile technically exports to Web via a WebGL2 code path, but support is partial and not recommended for production.
For Android and iOS, Mobile is the intended renderer. It was specifically designed around the constraints of tile-based GPU architectures (Adreno, Mali, Apple GPU) where bandwidth is expensive and on-chip tile memory is the dominant performance factor.
The decision is mostly determined by your target platform. Feature preferences only come into play when you have flexibility on platform.
| Scenario | Use |
|---|---|
| Desktop / console, high-fidelity 3D | Forward+ |
| Android or iOS primary target | Mobile |
| Web (HTML5) export required | Compatibility |
| 2D-heavy game, any platform | Compatibility (lowest overhead) |
| Desktop game, low visual requirements | Mobile or Compatibility (both work) |
| Needing SDFGI, VoxelGI, SSR, SSAO | Forward+ only |
| Needing compute shaders or RenderingDevice | Forward+ or Mobile |
| Targeting legacy or integrated GPUs | Compatibility |
Multi-renderer strategy: Godot does not support running different renderers per platform in a single project export configuration. If you need both Vulkan features on desktop and a Web build, you must maintain two export configurations pointing at different project settings, or target Compatibility for everything and accept its constraints.