Frontend · Android · Flutter

A Former Impeller Engineer Built a Full 3D Engine Inside Flutter

By 恋猫de小郭 · Jul 23, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Flutter teams that needed 3D previously had to embed Unity or a native engine via PlatformView, losing seamless compositing and adding platform-specific complexity. flutter_scene keeps everything inside Flutter's render tree, so 3D content can be mixed with standard UI, overlaid, clipped, and deployed across mobile, desktop, and even HarmonyOS through custom embedders.

Summary

flutter_scene implements its own scene graph, material system, animation blending, and a forward renderer with SSAO, SSR, cascaded shadow maps, and post-processing. It imports glTF models, compiles custom `.fmat` shaders, and runs physics via Rapier or Box3D backends. A BVH acceleration structure handles frustum culling and per-object light assignment, while a flat `RenderItem` list feeds the GPU instead of walking the scene tree every frame.

The engine composites directly into Flutter's Canvas, so 3D views participate in standard layout, clipping, and overlay with 2D widgets. Each `SceneView` gets its own off-screen texture and RenderGraph, enabling picture-in-picture, split-screen cameras, and mixed 2D/3D UI. A standout feature places real Flutter widgets onto 3D surfaces, though the current CPU readback path makes high-resolution dynamic panels expensive.

Built by a former Impeller engineer after leaving Google, the project ships with a scene editor, MCP agent interface, and build-time asset preprocessing. It already runs a Minecraft-style demo entirely on Flutter GPU, filling a gap the official framework never addressed.

Takeaways

— Renders entirely on Flutter GPU/Impeller with a WebGL2 shim for web; no PlatformView or external engine required.

— Manages its own scene graph, PBR materials, animation blending, cascaded shadow maps, SSAO, SSR, depth of field, and post-processing.

— Uses a flat RenderItem list and BVH for culling and light assignment instead of walking the scene tree each frame.

— Each SceneView composites into Flutter's Canvas via an off-screen texture, supporting layout, clipping, and overlay with standard widgets.

— Live Flutter widgets can be placed onto 3D surfaces, but the current GPU→CPU→GPU readback adds several milliseconds per capture.

— Supports glTF import, build-time preprocessing to `.fsceneb`, and a custom `.fmat` shader DSL compiled by a Build Hook.

— Physics backends include Rapier (via Dart FFI to Rust) and Box3D, with fixed-timestep simulation and transform interpolation.

— Static shadow caching reuses cascade tiles across frames, only overlaying dynamic objects for large static worlds.

— Runs a Minecraft-style demo with 100-tile streaming scenes averaging 5.7ms frame build time on Metal.

— Missing glTF extensions like Clearcoat, Sheen, and Transmission mean high-fidelity industrial models may not render correctly.

Conclusions

A former Impeller engineer leaving Google and then shipping the 3D engine Flutter never had is a sharp data point on how organizational constraints, not technical impossibility, often block platform features.

The decision to keep the RenderGraph as a simple ordered pass list rather than a full graph compiler is pragmatic for a still-evolving GPU API, but it will become a bottleneck if the pass count grows significantly.

Embedding Flutter widgets into 3D scenes is the project's most distinctive capability and its biggest performance trap: the CPU round-trip per capture makes high-frequency dynamic UI impractical until a zero-copy path exists.

Object-level forward rendering with BVH-based light assignment sidesteps the complexity of clustered deferred shading while still avoiding per-fragment light loops, a sensible tradeoff for mobile-first targets.

Concepts & terms

Impeller

Flutter's next-generation rendering engine that compiles shaders ahead-of-time to avoid frame drops from runtime shader compilation, replacing Skia on mobile platforms.

BVH (Bounding Volume Hierarchy)

A tree structure that partitions objects by their bounding boxes, used here for frustum culling and assigning nearby lights to each object without looping over every light in the scene.

Forward Renderer

A rendering approach where lighting is calculated in a single pass per object, as opposed to deferred rendering which writes geometry data to multiple buffers first. flutter_scene uses an object-level forward approach with light assignment via spatial indexing.

Cascaded Shadow Maps

A technique that uses multiple shadow maps at different resolutions for different distance ranges from the camera, giving sharp shadows nearby and coarser shadows at a distance without consuming excessive memory.

SSAO / SSR

Screen Space Ambient Occlusion adds contact shadows in crevices; Screen Space Reflections approximate reflections using only what is visible on screen, both as post-process effects that do not require precomputed scene data.

From the discussion

The discussion orbits around flutter_scene's debut at FlutterCon USA 2026, with one person noting the project's long development arc before its polished conference reveal. A separate thread laments the absence of YouTube recordings from the event, singling out multi-window support as a topic of interest. The sheer ambition of a full 3D engine inside Flutter draws a mix of disbelief and amusement, while a lone question asks whether Toyota's own game engine effort has stalled.

— flutter_scene was promoted at FlutterCon USA 2026 after a long period of development and is now considered polished.

— FlutterCon USA 2026 content is not available on YouTube, frustrating those interested in specific talks like multi-window support.

— The idea of Flutter functioning as a game engine is met with exaggerated surprise.

— Toyota's previously announced game engine project appears to have gone silent.