What Orblit is
Orblit is a 3D game engine you write in Dart. The game logic and the interface are Flutter, the entity-component core underneath is C++, and the rendering is Google’s Filament.
That combination isn’t arbitrary. Each part is there because the alternative was worse in a specific way, and it’s worth saying how.
Why Flutter
Section titled “Why Flutter”Because a game is not only a viewport. It’s a viewport surrounded by menus, inventories, dialogue boxes, settings screens and a pause overlay. In most engines, all of that gets built with a second, worse UI toolkit: one that exists only inside that engine, has its own layout rules, and can’t be tested without launching the game.
In Orblit, the scene is a widget. It sits in the same tree as everything else,
takes part in the same layout, and is composited by the same compositor. The
inventory screen is a Column. It has a widget test.
This works because the renderer draws into a texture that Flutter’s compositor takes as it is. On Apple platforms that’s an IOSurface-backed pixel buffer, adopted with no readback and no copy through the CPU, and in a browser it’s a canvas. A platform view would have put the 3D content in a window of its own on top of everything, which is why engines that embed that way generally can’t let a panel overlap the viewport. Here it can.
Why C++ underneath
Section titled “Why C++ underneath”Because walking ten thousand entities in Dart, one object at a time, is the thing that would have made this a toy.
The core is an archetype entity-component store: entities with the same set of components are stored together, so a system that wants every transform gets a contiguous run of them. Dart reaches it over a C ABI, and component data arrives as views over the store’s own memory, not as copies. Reading a column isn’t a translation step, and writing to one writes to the store.
You don’t have to touch any of this, and most games never will. It’s there so that the ones needing to walk a hundred thousand rows can.
Why Filament
Section titled “Why Filament”Because writing a physically based renderer is a decade of work, and Google have already done it. Filament brings a real material model, image-based lighting, cascaded shadows, screen-space effects and a tone mapper that behaves like a camera rather than like a colour ramp.
Orblit wraps it in a scene description that is stated rather than mutated, and adds the parts a game needs that a renderer doesn’t provide: populations, level of detail, a render graph, weather, and a sky.
Who it is for
Section titled “Who it is for”Anyone who already writes Flutter and wants 3D without taking on a second ecosystem, a second UI toolkit, a second build system and a second language.
It isn’t, today, for anyone shipping to consoles or to Windows, or who needs a marketplace of ready-made assets. Those are missing rather than promised.
What is here
Section titled “What is here”| Rendering | Filament, composited by Flutter, on macOS, iOS, Android and the web |
| Simulation | Archetype ECS in C++, reached from Dart as views |
| Geometry | Parametric shapes and mesh editing operations |
| Rigging | Armatures, poses, bone constraints |
| Interface | One document, built into real Flutter widgets |
| Scene files | A .oscene document format, with migrations and diffs |
| Models | glTF, with FBX and OBJ converted on load. Clips, skins, variants |
| Textures | Cooked KTX2 sets chosen per device, and lighting from HDR or EXR |
| Splats | Gaussian splat captures from .ply, .spz and .osplat |
| 2D | Sprites in layers, atlas packing, sprite animation, parallax, tile maps |
| Agents | Steering behaviours and behaviour trees |
| Cameras | Shots that describe what to frame, and blend |
| Weather | Conditions, transitions, cloud, the day’s cycle |
| Cutscenes | Tracks of clips sampled at a playhead |
| Scripting | C++ scripts, and TypeScript on QuickJS |
| Multiplayer | Replicated component columns, with ownership |
| Editor | A desktop application, in the same widgets |
The package reference says which repository each of those lives in and what its public surface is.
What is not here
Section titled “What is not here”Being clear about this is more useful than a roadmap.
- Not every platform has been seen to draw. macOS is the reference. iOS draws on the simulator, Android on one handset, the web in Chrome, Linux only against software rasterisers, and Windows builds without ever having drawn a frame. Most of the newest asset work has been run on macOS, the iOS simulator, the Android emulator and Chrome, and nowhere else. Platform support has the detail. Everything that doesn’t draw runs anywhere Dart does, so you can test the simulation on CI. It does not mean you can ship a game to a phone today.
- No asset store, and the asset pipeline is half built. glTF loads, FBX and OBJ are converted on the way in, and textures can be cooked. There’s no asset cache, no import settings, no material files, no loading over a network and no way to export a scene. FBX export isn’t planned at all.
- Tile maps are read, not drawn. So are parallax layers in a scene file.
- No physics solver of its own. There are shapes, raycasts and overlap tests. There is no rigid-body integrator in the engine.
- Nothing is API-stable. Pre-alpha means the names in these pages can change between commits.