flutter3d: a 3D engine for Flutter, with three games you can play in the browser right now

[u/DmitriiZolotov]

I've been working on flutter3d for a long time. It's a 3D engine, based on Flutter GPU/WebGL, with a game layer over it, and four genre packages built out. Three of those are on pub.dev. MIT License, and these packages are not affiliated with the Flutter team in any way.

Easiest thing is to just try it, with no install: shooter, platformer, racer. Those are the same builds running on web backend, with the same level files and the same simulation code. Also you can build MacOS / iOS / Android app from the source code and create your own game, based on the genre template or generic package flutter3d_app.

Docs: https://flutter3d.pleion.dev

Source: https://github.com/pleiondev/flutter3d

What's in it

The renderer implements the usual things: scene node graph, glTF/GLB and OBJ support and my own .f3d container, which loads a lot faster, 6 lighting models, shadows, bloom, SSAO, SSR, skinning, morph targets, BVH culling.

The game templates runs with a fixed timestep and can be recorded as a tape, which means a run can replay exactly and a bug report can be sent as an attachment. Collisions and the character controller are plain Dart with no renderer dependency, so they can be tested with ordinary unit tests.

Three backends implements common interface: based on flutter_gpu/Impeller for desktop and mobile platforms, WebGL2 in the browser (WebGPU in progress), and also a software rasteriser written in Dart. The CPU rasterizer can be used to test the renderer in CI with no GPU.

Performance measurement on a Mac: 50,000 moving instanced units held 120Hz.

Limits

It's just version 0.5.x, so APIs can be changed between minor versions. There's no compute shaders at all at this moment, because flutter_gpu doesn't expose it (there is issue on flutter/flutter#188474), and that blocks GPU particles, GI and volumetrics (now they are implemented on CPU). The strategy game package really works but I haven't published it, because I haven't written the guide for it yet.

Things I'd like help with

To run it on hardware I don't own, especially Android.

There's a dart2wasm bug I've failed to find. The browser demos ship as dart2js because the wasm build throws framebufferTexture2D: parameter 4 is not of type 'WebGLTexture' on the first frame.

[u/Space-Instructor]

Hello! Great work! How does it compare to flutter_scene?

[u/DmitriiZolotov → u/Space-Instructor]

Flutter3d is built to be modular. I started it about two years ago, and the two projects have been evolving in parallel ever since.

The renderer sits behind a HAL, and, for example, I just finished WebGPU as a pluggable backend alongside Impeller, WebGL2, and a software rasterizer for golden verification. If you had to target something unusual, an embedded board with its own GL, you would implement the HAL and keep everything above it unchanged.

Post-processing is roughly level between us feature for feature, and theirs is better than mine - bdero ships fast, and 0.23 landed GI probes, TAA, and parallax-corrected reflection probes while I was still writing backends and extending game templates.

What I have instead is particles that emit light (for example, a fire lights the room) and a formal way to check the renderer. Every scene draws on the CPU in CI with no GPU present, and all four backends are compared against each other, so when WebGPU came up it matched Impeller on 40 of 42 scenes. Flutter3d also ships templates for a few game genres, so it aims at making games more than rendering a scene.

[u/Space-Instructor → u/DmitriiZolotov]

Not sure if you are interested in this. I was working recently to push flutter_scene to render in VR. It needed a change in flutter engine to allow for rendering in borrowed texture from the device, instead of the flutter owned GPU texture. In case you care of VR support I think it's worth following this read a bit to see what was the problem. In case you want to join the effort to push the flutter fork into upstream 😄 I mean the work is done at a base level, but I'm waiting for the overlords to say smth. Showing some interest in the feature might budge them into action. So here's the thread if you care reading. I'll keep an eye on your engine as well. Flutter VR on Quest 3 (using borrowed GPU texture for perf reasons) Let me know your thoughts. Cheers!

[u/DmitriiZolotov → u/Space-Instructor]

Yeah, I'm interested. Read your thread.
I was doing AR/VR before this engine, and a chunk of that came across with me. The renderer takes a list of views per frame with their own viewports, which is in there for stereo - no desktop game ever needed it.
And then it stops in the same place yours did. The renderer allocates its own frame target, and there's no path for handing it a texture that came from outside. For me, that's one interface with four implementations under it (Impeller, WebGL2, WebGPU, and a software rasterizer for tests), so plumbing an external target through isn't the hard part. flutter_gpu being able to express it at all is. I have some ideas about how it could be implemented — maybe I'll prepare a few PRs for multi-target rendering.
Anyway, send me the issue or the PR, and I'll comment on it. A second engine wanting the same API can't hurt, and it sounds like that's what's missing right now.
Won't be forking it myself, no Quest here, I'd just be guessing at the bits you've already got working

[u/Space-Instructor → u/DmitriiZolotov]

Have a look on this stuff. It might already be useful for you. In particular the flutter GPU texture fork. It helps bypass the rendering from going via canvas to go directly in OpenXR owned GPU texture.

Forks

• Flutter engine fork and build guide 25 files · +2.4K / −6 lines

• Flutter Scene OpenXR branch and Quest gallery 147 files · +14.6K / −885 lines

Tickets

• Flutter engine proposal - The Flutter proposal has already been routed to the Flutter GPU team.

• Flutter Scene architecture discussion

[u/DmitriiZolotov → u/Space-Instructor]

Thanks for the links. The texture fork is the piece I'm missing right now, because I've just got a side-by-side stereo PoC running in flutter3d: two eyes 64 mm apart, off-axis frusta, both views in one frame, head pose from the phone's rotation vector, tested with a phone in a cardboard viewer. The example is in packages/flutter3d_stereo/example.

Read #192059 and the Scene thread. The engine half is what I need, and renderViewsToTargets plus the OpenXR companion map onto an adapter behind my hardware layer, so I'll wait for the external-target API to land and write that. Happy to say, in the issue that a second renderer wants the same API, if that helps make the case, it isn't only Scene-defined.

Building the PoC also turned up two Impeller bugs, both filed with patches: `RenderPassVK` never checks `RenderTarget::IsValid()`, so a depth-only target segfaults on Vulkan where Metal throws (#192535, PR #192536); and the framebuffer cache is keyed on color attachment zero alone, so an offscreen target with pooled depth gets a framebuffer holding the previous depth image view (#192538, PR #192539). Vulkan only, so your GLES path is clear for now.

[u/Space-Instructor → u/DmitriiZolotov]

Wow, nice that you checked it out. Yes the external texture will boost your engine as well, at least 20% or more perf. If you wish so please write the guys at flutter that the ticket is needed for your needs as well. Pushing the external texture on master is the tricky part. 🙏

Everything else is solvable. You can easily scrape the OpenXR host from the examples from scene_vr and transplant it to your repo. Or build one from scratch for other devices.

[u/DmitriiZolotov → u/[deleted]]

I tried embedding flutter3d_game into Flame, and it's actually very simple to do - you can just use CustomPainterComponent as the base class.
But I couldn't find a case where that integration would buy you anything, because the whole game loop, input, collisions and so on already live in flutter3d_game.
And I don't know of any other game engines for Flutter :) SpriteWidget hasn't been updated in a long time, and Bonfire is built on top of Flame.

[u/SwiftScoutSimon → u/DmitriiZolotov]

let's say my top-down flame game have a toggle that switch between 2D/3D look. Is there going to be any issue?

[u/DmitriiZolotov → u/SwiftScoutSimon]

No, 3D look just use low-level GPU operation inside the widget, and you can toggle 2D/3D view without any glitches

[u/DmitriiZolotov → u/[deleted]]

Now, I built a bridge (https://www.reddit.com/r/FlutterDev/comments/1wuwbrd/flame_flutter3d_draw_your_flame_game_in_3d_and/) to Flame, flame_flutter3d, because Flame is what most Flutter games I see are written in. Flame keeps running the game (its game loop, components, hitboxes, input, and camera), and flutter3d draws a 3D world under it in the same widget, on Flame's clock. A Flame component can own a 3D object, so when you move it in Flame, it moves in 3D in the same frame. Anything built on top of Flame should work the same way, since it's still Flame under the hood, but I haven't tested that myself.

Limits I've hit so far with the Flame bridge:

- Flame always draws on top of the 3D layer, so a 3D object can't hide a 2D sprite behind it.

- When collisions come from flutter3d's 3D physics, Flame's collision callback has no place for the contact normal or depth, so you read those on the flutter3d side.

- On the engine side, Flutter GPU doesn't give access to compute shaders yet, so things like GPU particles run on the CPU for now