Flutter Scene is a 3D engine that rides on Flutter GPU

Why an engine inside Flutter needed to get out first

The origin story explains the design. Scene began its life inside the Flutter Engine as a C++ module for Impeller with a declarative widget interface exposed through a 3D API in the Flutter SDK. Flutter GPU was built initially to set this project free, providing the low-level GPU access needed to develop Scene outside the engine as an ordinary ecosystem of Dart packages. The stated goal has always been to pave the way for advanced graphics in Flutter, and in line with the goals in Flutter GPU's original design document, Scene aims to de-fracture, unite and elevate Flutter's graphics ecosystem, so that building 3D experiences with Flutter and Dart no longer requires engine forks, complicated external renderer integrations, or giving up platforms to get advanced features. The author is the author of Flutter GPU and a former core Flutter engine team member who spent four years on Flutter, most of it building Impeller, which is the reason the project is credible rather than merely interesting.

The rendering stack

The rendering feature list is what a modern engine would be judged on. The materials are physically based, with image-based lighting, and the light types are directional, point, spot and area lights, all with shadows, plus probe-based global illumination. The post-processing stack includes bloom, depth of field, fog, god rays, screen-space reflections, colour grading, and both SMAA and TAA for antialiasing. Beyond that there are decals, Gaussian splatting, instancing, LODs, particles and sky materials. Two of those are worth pausing on. Gaussian splatting is the representation that made neural scene reconstruction widely practical, and its presence suggests an interest in importing captured environments rather than only authored assets. Probe-based global illumination is the older technique and is what makes a scene look lit in a room that was never measured.

Physics, audio, multiplayer and animation

The games feature list covers the parts of an engine that are not about drawing. Physics has two backends, Rapier and box3d, which means you can pick a modern rigid body solver or a lighter one. Audio is positional, with the SoLoud and FMOD implementations behind it. Multiplayer runs over dashwire, and the animation system covers skeletal and morph targets with blending, plus camera controllers, a gameplay kit, raycast picking, and interactive Flutter widgets on 3D surfaces, which is the feature that makes it a Flutter engine rather than a canvas in a widget. The example projects show the range. Dashsurfers is an endless runner with skinned characters, physics and particles, and Dashmap is a live 3D world map with streaming terrain, OpenStreetMap buildings and a physical sky. The examples application holds forty three runnable feature examples.

An editor an agent can drive

The tooling is where this project goes further than a typical package. There is a desktop scene editor with an MCP server for agent-driven editing, so a coding agent can operate the editor rather than only write code against it, and the screenshot of the editor in the README is captioned as being driven by a coding agent over MCP. Alongside that the package ships a set of agent skills, so a coding assistant writes idiomatic Scene instead of guessing, covering correct usage and traps, the run-settle-capture verification loop, copy-paste look presets, procedural content and performance. Those skills are installed by dart run flutter_scene:init, which offers to install them, or managed on their own with dart run flutter_scene:skills, which can install, update or check them without touching the build hook, and a check mode reports whether newer revisions are available. The asset pipeline runs at build time, and there is hot reload for models, shaders, textures and environments.

Formats and platforms

The format list is what tells you where the boundaries are. There is glTF import, the .fscene scene document, .fmat custom materials written in GLSL, KTX2 compressed textures, and HDR and EXR environments. The platform list is iOS, Android, macOS, Windows, Linux and the web, and the web detail is the one to notice, because there a built-in WebGL2 backend stands in for Impeller, so the web is not running the same renderer as the native platforms. Rendering on native goes through Flutter GPU, which is off by default, so it has to be enabled once per platform, while the web needs nothing. Impeller itself, which Flutter GPU builds on, is the default renderer on every native platform as of Flutter 3.47, so there is nothing to do for it. The set of formats is a sensible minimum for a modern pipeline, and the absence of a proprietary container format is a good sign for a project that wants to work with what artists already have.

Getting started in three commands

The setup is short. You add the package and run the init task, which sets up the asset pipeline and is the recommended way to use Scene:

flutter pub add flutter_scene
dart run flutter_scene:init

After that you drop sources under assets/ and load them by their source path:

final level = await loadScene('assets/level.glb');
scene.add(level);
// ...
SceneView(scene, cameraBuilder: (elapsed) => PerspectiveCamera(...));

The same code runs on the web, and the engine's shaders are compiled for you during the build by the package's own build hook. While you are developing you pass the flag on the command line:

flutter run --enable-flutter-gpu

and to turn it on permanently, for every run and for the app you ship, you edit the platform file, with a table in the README mapping each platform to its configuration file and the key to add, starting with the iOS Info.plist. The distinction between the development flag and the platform file is the kind of detail that trips people up, and the README spells it out.

The tests that feed back into the engine

The relationship between Scene and Flutter GPU is described as flowing both ways by design, and the mechanism is stated plainly. Scene's cross-backend render tests are where Flutter GPU regressions get caught, so Impeller and Flutter GPU get better because Scene exists. That is an unusual arrangement, because it means the consumer project is also the test suite for the platform it depends on, and it explains the presence of the example directories you would not otherwise expect, with a flutter_gpu_shim_smoke example, a smoke_render example and a stress_bench example. The project ships with a GitHub Actions test workflow, a Codemagic build status for a macOS smoke build, and Argos visual testing for screenshot comparison, which is the right tool for a renderer whose output is pixels. The releases are frequent, with 0.24.3 on 2026-10-09, 0.24.2 on 2026-10-08 and 0.24.1 on 2026-10-07, the last push was on 2026-10-15, and the licence is MIT. The tree also carries a materials document, a post-processing document and a widgets document at the top level, alongside the packages, apps and tools directories.

Editorial conclusion

Flutter Scene fits a team that wants real time 3D in a Flutter application without forking the engine, and the combination of a scene editor an agent can drive over MCP and a build time shader pipeline makes it closer to a full toolchain than a demo. It does not fit a project that needs to ship on the web today, since the web path depends on a WebGL2 backend standing in for Impeller rather than on the same renderer, and it does not fit a team that cannot accept a dependency on a graphics package that is still young. Before you start, run dart run flutter_scene:init, which sets up the asset pipeline, and read the platform table, because Flutter GPU has to be enabled per platform and the flag differs between development and a shipped app.

Frequently asked questions

Official sources

1. bdero/flutter_scene on GitHub
2. Issues
3. License: MIT
4. README
5. Releases