Where this came from

Orblit was not started because nobody else had thought about 3D in Flutter. It was started after reading the people who had.

Three projects came up, in this order, and each one changed what Orblit was going to be. None of them is a competitor being dismissed here. Two of them are further along than Orblit is, and the third had proved the architecture before a line of Orblit existed.

Flame

Flame is the one you find first, and the one that made the case that Flutter is a serious place to write games at all. It is a 2D engine on top of Flutter, MIT-licensed, maintained by bluefireteam. It also has the thing none of the rest of us have yet: a real community, a game jam, and years of shipped games behind it.

Flame gets the shape of the thing right. A component tree, a game loop, and a deliberate decision to be part of Flutter instead of a window sitting on top of it. orblit_sprite exists because Flame showed that 2D in this ecosystem is worth doing properly.

Flame is 2D, by design and without apology, and it draws through Flutter’s canvas. That is the right answer for an enormous number of games. It is not the answer for the ones that need a depth buffer, a material model and shadows.

Flutter Scene

Flutter Scene is the closest thing to 3D-in-Flutter as an official answer. It began as a C++ component inside Impeller and is now a pure Dart package on top of the Flutter GPU API, written by the person who wrote Flutter GPU.

It is an ambitious piece of work: physically based materials, image-based lighting, shadows, skeletal animation, post-processing, a declarative widget API. It renders through Impeller, so it runs everywhere Impeller runs. That last part is worth saying plainly. On platform coverage, Flutter Scene is ahead of Orblit today, and has been the whole time.

Orblit did not build on it because of two bets. They really are bets, and not criticisms:

• Flutter GPU is itself in preview. Building a renderer on a preview API means inheriting its timeline. Filament is a decade old, it has shipped, and its material model is not going to be redesigned underneath us.
• We wanted a C++ entity-component core, not only a renderer. What makes a hundred thousand entities viable is the store, and that is a different project from drawing.

If those two bets turn out to be wrong, then Flutter Scene is the better answer. We would rather say so here than have you find out three weeks in.

Fluorite

Then Fluorite turned up, announced by Toyota Connected North America at FOSDEM in February 2026. It was a strange thing to read: Dart for game code, a C++ data-oriented ECS underneath, Filament doing the rendering, Flutter for the interface, and the phrase “console-grade” attached to it.

That is the Orblit architecture, described by a company that builds in-vehicle cockpits for a living and needs the thing to run on embedded hardware in a car.

The honest reaction to that is not defensiveness. It is relief. A team working independently, under automotive shipping constraints, arrived at the same four choices. That is about as good a signal as you get that the shape is right, and not merely appealing. Their target is the digital cockpit and ours is games on desktops and consoles. Both can exist, and a Dart game ecosystem with two serious engines in it is in far better health than one with none.

What Orblit does differently

Not better. Differently, and on purpose.

The scene is a widget, not a surface	The renderer draws into a texture Flutter composites, an IOSurface-backed buffer on Apple platforms, so the 3D view takes part in layout. A panel can overlap it and it clips to a rounded rectangle. See how it fits together.
The scene is stated, not mutated	No addChild. Every frame describes the whole scene and keys do the reconciliation, so game state and render state cannot drift apart. See stating a scene.
Time is sampled, not stepped	Effects, sprite animation and cutscenes are functions of a playhead, so scrubbing backwards gives the same answer as playing forwards. See sampled, not stepped.
Real photometric units	Lights in lux and lumens, cameras with an aperture, a shutter and a sensitivity. A number off a light fitting’s box is the number you type.
The documentation compiles	Every Dart block written for this site is extracted and analysed against a real engine checkout in CI, and the gallery’s code is copied from the examples themselves instead of retyped. A renamed field turns the build red instead of turning a page into a quiet lie.

What we want it to be

Community-led, and console-grade. Both halves matter.

Community-led means the engine is not a product with a roadmap handed down. The engine, the editor, the examples, the networking and the scripting are all public under MPL-2.0, an open source licence. The design arguments happen in the open, and the people using it set the shape of what gets built next. There is no paid tier planned, no per-seat licence, and no revenue share.

Console-grade is a target, not a claim about today. The working platform list is macOS, Linux and SteamOS including the Steam Deck, Windows, iOS, Android, Switch 1 and 2, and Xbox. PlayStation is out of scope for now. Platform support records what actually renders this week. That is a much shorter list, and it is the page to trust over this paragraph.

The name

It began as Orbis, which is Latin for a circle or a world, and which lasted about as long as the first proper search for it did. Several companies with nothing to do with graphics have taken the word already, and it says nothing about what this thing does.

Orblit keeps the world and adds a blit. A blit is a real graphics operation, and has been since the 1970s: a bit-block transfer, which means copying a rectangle of pixels from one place to another. That is very close to what this engine does for a living, because the renderer’s whole job is getting a finished frame into a buffer that Flutter’s texture registry can adopt.

Orbis plus blit. Nerdy, but clever, and nobody else had taken it.

The rename landed in September 2026 and went all the way down: the repositories, the Dart package names, the Android package identifier, the plugin classes and the C symbols. An orbis left anywhere in the source is a bug, not a survival. The git history is the only place it is meant to still exist.

One rule about all three

Nothing in Orblit is copied from Flame, Flutter Scene, Fluorite, Thermion or any other engine, in any form.

Part of that is licensing hygiene. Most of it is that a port carries the assumptions of the thing it was ported from, and those assumptions were correct for a different design. We read them for how they framed a problem, which is worth a great deal, and then go and write our own.