flutter3d and Flutter Scene

Flutter Scene is the other engine built on Flutter GPU. It is maintained by the author of Flutter GPU itself, a former core Flutter engine team member who spent four years on Flutter, most of it building Impeller. That gives it a relationship with the underlying API that no third-party package can have: Scene's render tests are where Flutter GPU regressions get caught, because the author of Flutter GPU also writes the engine. flutter3d uses flutter_gpu the way any other package does, through the public surface.

The two projects are not after the same thing. Scene is a complete 3D game engine and toolkit for anyone building on Flutter, pre-1.0 and moving quickly. flutter3d answers a narrower question: whether a HAL, a scene graph and a game layer of this shape can be built by someone with no inside access to Impeller, tested against three complete games of different genres that needed no engine-level code changes between them. The flutter3d half of this page was read against the source tree of 0.8.1 on 2026-09-27. The Scene half describes its README, which was last changed on 2026-09-03, and its repository at the same date was searched for every capability the README does not name.

Quick facts #

	flutter3d	Flutter Scene
First commit	2026-08-08	2024-02-01
Core package version	0.8.2	0.23.0
Maintainer	An independent developer, unaffiliated with the Flutter team	The author of Flutter GPU, formerly on the core Flutter engine team
Licence	MIT	MIT
Web backend	WebGL2, and WebGPU behind a flag	Built-in WebGL2
Physics	Pure Dart, in-tree (`flutter3d_physics`)	Native: `flutter_scene_rapier` (prebuilt binaries + wasm) or `flutter_scene_box3d`
Audio	`flutter_soloud`, an FFI binding to the SoLoud engine, behind a pluggable backend interface	`flutter_scene_soloud`, the same SoLoud engine, or `flutter_scene_fmod` (commercial middleware)
CPU / GPU-less test backend	Yes: `flutter3d_cpu`, a software rasteriser used in CI	No backend of its own; CI renders its smoke scenes through Impeller on Mesa's software rasterisers (Linux), SwiftShader (Android emulator), headless Chrome and Windows, and Metal on Codemagic, compared in Argos
Multiplayer	Rollback netcode for two peers (`flutter3d_net`, WebSocket or WebRTC transport), on pub.dev	`flutter_scene_net`, over `dashwire`: replicated state, client-side prediction, and physics rollback for the entity a client owns
Editor with an MCP server	Yes: `flutter3d_editor_mcp`, published to pub.dev with the rest of the set	Yes: the Flutter Scene Editor stack, shipped as a desktop app, not on pub.dev, and explicitly "in active development"

Feature by feature #

A green dot is a capability the engine has; a red one is a capability it does not. For flutter3d that is read from its source. For Flutter Scene it is read from its README and then checked against its repository: a red dot there means neither names it in the engine's packages. Where Scene has something close in another form, the row is worded to the difference, and here is the form: an XPBD cloth solver in its example app rather than in the engine, physics rollback for the one entity a client owns against a server rather than every player's input between peers, a pure-Dart physics backend for queries and triggers with no dynamics, and occlusion culling through planes an application supplies rather than a depth pyramid. Each row is one capability, so where both engines have something in different depths (physics, global illumination, the editor) the sections below say how they differ.

Capability	flutter3d	Flutter Scene
Rendering
Physically based materials with clearcoat, sheen, anisotropy and transmission	yes	yes
Rectangle area lights	yes	yes
Clustered lights, so a scene can hold many	yes	yes
Cascaded sun shadows with soft penumbrae and contact shadows	yes	yes
Exponential variance shadow maps (EVSM) for the sun	yes	no
Irradiance probe field with a visibility test per probe	yes	yes
Horizon-based ambient occlusion and screen-space bounced light	yes	yes
Screen-space reflections, depth of field, bloom, automatic exposure	yes	yes
Volumetric fog	yes	no
Order-independent transparency	yes	no
Motion blur	yes	no
Local exposure, and HDR output (WebGPU only)	yes	no
Temporal anti-aliasing and FXAA	yes	yes
SMAA	no	yes
Lens flares and radial lens distortion	no	yes
Projected decals	no	yes
Gaussian splats	yes	yes
Octahedral impostors for distant models	yes	no
Automatic occlusion culling (Hi-Z)	yes	no
Assets and animation
Skinning, morph targets and blended animation	yes	yes
glTF material variants	yes	yes
glTF animation pointers (a clip moves a material or a light)	yes	no
Retargeting a clip onto another skeleton	yes	no
Models converted at build time by a build hook	yes	yes
Hot reload for models and textures	no	yes
Backends
Impeller through Flutter GPU	yes	yes
WebGL2 in the browser	yes	yes
WebGPU in the browser	yes	no
A software rasteriser in Dart, so rendering tests run without a GPU	yes	no
Games
Rigid-body dynamics in pure Dart, with no native binaries	yes	no
Native physics through Rapier or box3d	no	yes
Rigid bodies that rotate	no	yes
Cloth in the engine's packages	yes	no
Particles	yes	yes
Audio through SoLoud	yes	yes
Multiplayer	yes	yes
Peer-to-peer rollback of every player's input	yes	no
Genre packages: shooter, platformer, racing, strategy	yes	no
A bridge to the Flame 2D engine	yes	no
Tools and app integration
A scene editor with an MCP server for coding agents	yes	yes
A declarative widget API for the scene	no	yes
The scene described to a screen reader	yes	yes

What Scene has that flutter3d doesn't #

Reading its README against flutter3d's own feature table:

Decals. Scene projects boxes onto existing geometry. flutter3d has no decal pass; its renderer mentions decals only in doc comments describing where a raycast hit could place one.
SMAA, lens flares and radial lens distortion. Scene has SMAA beside FXAA and TAA, flares on its bloom and a radial distortion pass, and it grades from .cube LUTs. flutter3d has FXAA with contrast-adaptive sharpening and, since 0.8, temporal anti-aliasing; it has no SMAA, no flares and no distortion pass, and it grades from a strip LUT.
Native physics through a mature third-party engine. Rapier or box3d, pluggable, where flutter3d has an implementation scoped to this project alone. flutter3d's physics package covers overlap, sweeps, rays, a character controller, an XPBD cloth solver and rigid bodies that settle their contacts with sequential impulses; its bodies do not rotate, and it has no joints and no continuous collision. Audio is not really a difference between the two, since both wrap the same SoLoud engine; Scene additionally offers FMOD, commercial middleware, as a second backend.
A declarative widget API (SceneNode, SceneMesh, SceneModel) alongside the imperative scene graph. flutter3d's scene graph is imperative only. Both describe the scene to a screen reader through Flutter semantics.
Hot reload for assets. Scene reloads models, shaders, textures, environments and scene documents while the app runs. flutter3d reloads a shader bundle in place (LoadedShaderLibrary.refresh, which the editor uses to watch one), but picks up a changed model or texture only on the next build. Both convert models at build time through a build hook (flutter3d_build here).
Two projects built on it, the Dashsurfers endless runner and the Dashmap live world map, plus 43 runnable feature examples in the example app.
More than two and a half years in its own repository, and an earlier life inside the Flutter engine, against flutter3d's seven weeks.

Global illumination was on this list until 0.8. Both engines now read a world-space irradiance probe field with a visibility test per probe and add horizon-based ambient occlusion and screen-space indirect light. Scene bakes its field offline or progressively; flutter3d traces it with the CPU raycaster and can update it on the GPU. Temporal anti-aliasing moved off the list the same way.

What flutter3d has that Scene doesn't #

No native dependencies outside audio. Physics, cloth and rig retargeting are plain Dart, with no dart:ffi, prebuilt binaries or wasm module to vendor. Audio is the one exception: flutter3d_audio wraps flutter_soloud, an FFI binding to the same SoLoud engine Scene's flutter_scene_soloud wraps. Physics is where the gap is real: flutter pub get is the entire dependency story for it on every platform, where flutter_scene_rapier ships prebuilt native binaries.
A CPU software backend. flutter3d_cpu rasterises entirely in Dart, gives the renderer a second, independent implementation to check the GPU backends against, and runs the golden-image suite in CI with no GPU at all. Scene has no software backend of its own; its CI renders through Impeller on Mesa and SwiftShader software rasterisers, in headless Chrome, and on Codemagic's Apple hardware, and checks the frames in Argos.
A second web backend. flutter3d ships both WebGL2 and an experimental WebGPU backend behind --dart-define=FLUTTER3D_WEBGPU=true. Scene ships WebGL2 only on the web.
Three complete games of different genres on one engine, with no genre-specific code shared between them. A shooter, a platformer and a racing game, each built without editing the engine packages the other two depend on, with the boundary enforced by structural scans (tool/structure.dart) and not only by convention. A fourth genre, strategy, is in the workspace too, and its genre package is on pub.dev.
A bidirectional bridge to Flame, the established Flutter 2D game engine. flame_flutter3d composites a Flame layer and a flutter3d layer in one widget, each drawing itself, with transform, ECS (through flutter3d_sim's own actor system), physics, input and camera reconciled between the two, so neither engine drives the other's renderer. A fifth demo, Meteor Yard, uses all five end to end and plays in a browser. Scene's README does not describe an equivalent.
Rendering features Scene's README does not list. Order-independent transparency, motion blur, volumetric fog, local exposure, and HDR output on the WebGPU backend; octahedral impostors and occlusion culling; and adaptive quality, which picks each frame the best-looking row of a quality table that fits a frame budget (off by default, and its costs are measured on the software rasteriser until each device class is measured on its own GPU). Scene has fog, god rays and resolution scaling, which are near relatives of some of these, and it may have more than its README says.

These are different bets on where a young engine spends its first year, not a scoreboard. Scene put that time into rendering depth, native-grade physics and audio, and a widget-level API, with more than two and a half years behind it and a maintainer who wrote Flutter GPU. flutter3d put it into proving the architecture across three shipped games and keeping physics, cloth and rig retargeting in pure Dart, plus a software rendering backend of its own, written in Dart, so rendering tests need no GPU and no graphics driver at all. Both are pre-1.0, both MIT, both sit on the same `flutter_gpu` foundation.

Picking one #

If a project needs decals, a mature physics backend with joints and rotating bodies, asset hot reload, or a declarative widget API today, Scene already has it. If a project's constraints run the other way (no native physics binaries in the build, rendering tests that have to run with no GPU or graphics driver, inside flutter test, or an interest in how the genre-package split holds up across three real games), flutter3d is built to show exactly that.