Forward+, Mobile, or Compatibility? Choose a Godot 3D Renderer

The renderer is a project constraint, not a quality score. A browser game, a compact mobile scene, and a desktop game with dynamic indirect lighting can need different choices. This guide helps you choose a starting renderer, identify the features your game really uses, and compare an exported scene without confusing a faster empty project with a faster finished game.

1. Write down the target before choosing effects

Start with a small target sheet: the weakest device you intend to support, the operating system, the output resolution, and the frame rate you want. Add one representative scene, such as the 3D test room, then gradually add the lights, materials, and objects your game will actually show.

For a first desktop experiment on modern supported hardware, Forward+ is a reasonable starting point. For a web export, use Compatibility. For a newer mobile device, evaluate Mobile and Compatibility using the same scene. These are starting choices based on platform and feature support, not benchmark results for your hardware.

2. Separate rendering method from graphics driver

Forward+, Mobile, and Compatibility are rendering methods. Vulkan, Direct3D 12, Metal, and OpenGL are graphics APIs used by drivers underneath them. Forward+ and Mobile use Godot’s RenderingDevice backend. Compatibility uses OpenGL. Seeing a Vulkan error does not mean “3D is unavailable”; it means you should check the hardware/driver requirements and an appropriate rendering path.

Record both method and driver in your test notes. A report that only says “the new renderer is slow” omits information needed to reproduce the result. Include the engine version, device, and resolution too. If the method changes through fallback, inspect the running result rather than assuming it retains the intended feature set.

3. Use a short feature checklist

Unfamiliar names? Use the short definitions of SDFGI, LightmapGI, and MSAA, then return to the checklist.

• All three methods can render a basic 3D scene with meshes, materials, cameras, and lights.
• Forward+ is the path for VoxelGI and SDFGI; Mobile and Compatibility do not support those GI methods.
• Baked LightmapGI can be displayed across the renderers. Baking requires hardware with RenderingDevice support, even if the final game uses Compatibility.
• Godot web exports use Compatibility. A desktop scene built around Forward+-only effects needs a deliberate visual fallback for the web.

Keep the full official renderer comparison linked below as your reference. This checklist intentionally covers the decisions in our three-part 3D path, not every post-processing effect. Avoid older blanket claims such as “Compatibility has no post-processing”: individual features and implementations change between Godot releases.

4. Make a scene that exposes the tradeoffs

Duplicate your room into RendererTest.tscn. Use the same Camera3D transform and output resolution in every run. Begin with one DirectionalLight3D, two roughness samples, and the WorldEnvironment from the lighting guide. Leave advanced GI disabled for this first comparison so all candidates have a common baseline.

• Run A: one light, ordinary opaque materials, shadows disabled.
• Run B: the same scene with shadows enabled.
• Run C: your expected number of visible objects and lights, while keeping the camera fixed.
• Run D: a representative movement route through the scene, including the busiest view.

Record the changed setting and observed frame time for each run. Also record whether the image still communicates the game clearly. You may discover that a visual problem can be fixed by repositioning a light rather than enabling another effect. The purpose of this exercise is to locate the expensive or missing feature, not to produce a winner from an artificially empty scene.

5. Compare frame time and image quality together

Frame time is easier to budget than a large FPS number: 60 frames per second gives roughly 16.7 milliseconds per frame, while 30 gives roughly 33.3. Those are total frame budgets, not promises of spare GPU time. Use Godot’s profiler and monitors to distinguish CPU work, rendering work, and the effect of synchronization instead of adding every displayed number together.

Test an exported build as well as the editor run. Keep the same resolution, camera route, synchronization settings, and background workload. Allow initial loading and shader work to settle before collecting a steady-state comparison, but also note first-use stalls separately because players experience them. A capped 60 FPS reading by itself cannot tell you which renderer has more headroom.

Do not claim a percentage speedup from one unrepeatable run. Write a useful note instead: the device, the scene revision, the renderer and driver, the settings you changed, and whether the frame-time behavior improved consistently. This gives your future self enough context to repeat the experiment after a Godot update.

6. Change a setting that tests your hypothesis

• If disabling shadows helps substantially, inspect shadow-casting lights, their coverage, and shadow distance before reducing unrelated textures.
• If lowering the output resolution helps, investigate rendering costs that scale with pixels; this is a clue, not proof of one particular bottleneck.
• If removing a script-heavy group helps while rendering changes do little, inspect CPU behavior before switching renderers.
• If the image changes after a switch, inspect unsupported features, environment settings, and material behavior before assuming the scene is corrupt.

Switch the rendering method using the renderer selector in the editor’s upper-right corner and restart when prompted. Save a copy or use version control before the experiment. Switching is not a guarantee of identical output: review the environment, shadows, transparent materials, and reflections in the exported target build.

7. Make the choice explicit in your project

Write down a decision with one reason and one follow-up test. For example: “Compatibility, because the game must run in a browser; next check the level on our weakest target laptop.” Or: “Forward+, because the desktop art direction needs SDFGI; next measure the busiest room on the minimum GPU.” These are example decision formats, not claims about your project’s performance.

Keep the scene as a regression test when updating the engine. The 4.7.2 update guide explains what to recheck in a maintenance release, and the lighting guide gives a baseline for visual comparisons. If you are porting a Unity game, revisit the 3D migration workflow before treating your old render pipeline as a one-to-one mapping.