On this page

Rendering architecture

The renderer has two execution families. Forward+ and Mobile use RenderingDevice, Redot's graphics abstraction over Vulkan, Direct3D 12, and Metal. Compatibility calls OpenGL through the GLES3 implementation. Dummy implements renderer contracts without GPU drawing.

The scene-facing RenderingServer sits above both families. Scene nodes and resources create server objects and submit changes through that API. They do not submit a complete frame every time a property changes. Server components retain state until frame execution consumes it.

Scene objects reach shared rendering services, which dispatch to either the RD renderer and a native driver or the GLES3 renderer.

Responsibilities

Component	Responsibility	State it handles
RenderingServerDefault	Dispatch API calls, marshal threads, coordinate frames	Command queue and frame callbacks
RendererCanvasCull	Retain canvas items and select ordered 2D work	Canvas hierarchy and drawing commands
RendererSceneCull	Retain scenarios and instances, update dependencies, select visible work	Spatial indexes, cameras, instance relationships
RendererViewport	Schedule outputs and combine canvas, scene, and XR work	Viewports, render targets, render-buffer references
RendererCompositor implementations	Supply concrete renderer/storage components and frame hooks	Renderer implementation composition
RendererSceneRender implementations	Choose passes and draw visible 3D geometry	Render lists, scene shader state, method-specific buffers
Storage implementations	Maintain renderer resources	Meshes, materials, lights, textures, particles
`RenderingDevice`	Validate and track graphics resources and record commands	Device RIDs, resource dependencies, frames in flight
Context and device drivers	Integrate native graphics APIs	Devices, surfaces, native resources, queues, swapchains

The core class index and storage class index link these contracts to their headers and implementations.

Composition and access

RenderingServerDefault::_init() creates the canvas culler, viewport manager, scene culler, and camera attributes. It creates the selected compositor through RendererCompositor::create(), then obtains its storage and drawing interfaces. The scene culler receives the concrete scene renderer through set_scene_render().

RenderingServerGlobals, abbreviated RSG, publishes pointers to those components. This is a shared access mechanism; it does not express ownership. RSG::scene points to a RenderingMethod, normally RendererSceneCull. RSG::rasterizer points to a compositor. Historical names make these fields less descriptive than their types.

The RD compositor constructs RD storage objects and a shared canvas renderer, then selects RenderForwardClustered or RenderForwardMobile for 3D. The GLES3 compositor supplies a separate canvas renderer, scene renderer, and storage family. This distinction matters: Compatibility does not implement another RenderingDeviceDriver.

RD, GLES3, and dummy compositors implement the compositor interface.

Forward+ and Mobile specialize the RD scene renderer; GLES3 and dummy implement the shared scene interface separately.

RD, GLES3, and dummy canvas renderers implement the shared canvas interface.

Boundaries to preserve

The broad separation is scene semantics, retained server state, rendering policy, and native GPU execution. The implementation crosses that separation through global singletons, shared data structures, shader resources, and platform integration. Those crossings are described in the dependency map.

RenderingDeviceGraph is a command/resource dependency graph below the rendering methods. It does not own the semantic list of Forward+ or Mobile passes. Changing the device graph alone therefore does not provide a new scene pipeline API. See wrapper chains and boundary observations.

Source: startup and dispatch, scene execution, and backend selection.