What Orblit is
Orblit is a 3D game engine you write in Dart. You write the game logic and the interface in Flutter. Underneath, the entity-component core is C++, and Google’s Filament does the rendering.
Each of those three parts was picked for a reason. Here is why.
Why Flutter
Section titled “Why Flutter”A game needs more than a 3D view. It also needs menus, inventories, dialogue boxes, settings screens and a pause screen. In most engines you build all of that with a second UI toolkit. That toolkit works only inside the engine, it has its own layout rules, and you have to launch the game to test it.
In Orblit the scene is a widget. It sits in the same widget tree as everything
else, takes part in the same layout, and goes through the same compositor.
Your inventory screen is a Column, and you can write a widget test for it.
This works because the renderer draws into a texture, and Flutter’s compositor uses that texture as it is. On Apple platforms the texture is an IOSurface-backed pixel buffer, adopted with no readback and no copy through the CPU. In a browser it is a canvas. The other way to embed 3D is a platform view, which puts the 3D content in a window of its own on top of everything. Engines that embed that way usually cannot let a panel overlap the viewport. Orblit can.
Why C++ underneath
Section titled “Why C++ underneath”Walking ten thousand entities in Dart, one object at a time, is slow enough to have made Orblit 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 them as one contiguous run. Dart reaches the store over a C ABI, and component data arrives as views over the store’s own memory, not as copies. Reading a column costs no translation step, and writing to one writes to the store.
You do not have to touch any of this, and most games never will. It is there for the games that need to walk a hundred thousand rows.
Why Filament
Section titled “Why Filament”Writing a physically based renderer takes about a decade, 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 instead of a colour ramp.
Orblit wraps it in a scene description you state instead of mutate, and adds the parts a game needs that a renderer does not 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.
That covers most of the places Flutter goes. The renderer draws on macOS, iOS, Android and the web. On Linux it has so far drawn only against software rasterisers. It also builds on Windows, and setting up Windows walks through a machine from nothing. What Windows still has not done is draw a frame: CI builds it on every change but has no GPU to draw with, and nobody has run it on a real Windows machine yet. If you have one, trying it is among the most useful things you could do.
Orblit is not for you today if you need consoles or a marketplace of ready-made assets. Those are missing, not promised.
What is here
Section titled “What is here”| Rendering | Filament, composited by Flutter. Draws on macOS, iOS, Android, Linux and the web, and builds on Windows |
| Simulation | Archetype ECS in C++, reached from Dart as views |
| Geometry | Parametric shapes and mesh editing operations |
| Rigging | Armatures, poses, bone constraints |
| Animation | Clips you own, keyed or imported from glTF, with marks and root motion |
| 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. Its 3D viewport runs on macOS so far |
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”Saying this plainly 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, and Linux only against software rasterisers. 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 does not draw runs anywhere Dart does, so you can test the simulation on CI. None of it means you can ship a game to a phone today.
- No asset store, and the asset pipeline is still being built. glTF loads, FBX and OBJ are converted on the way in, and textures can be cooked. Assets load over a network, and a scene can be exported as glTF, GLB or OBJ. There is no asset cache, no import settings and no material files. FBX export is not planned at all.
- Tile maps are read, not drawn. So are parallax layers in a scene file.
- Physics is young. There is a rigid-body solver with balls, boxes, capsules, cylinders, convex hulls, ground and joints, but nothing to stop fast things passing through walls, and nothing on the web.
- Nothing is API-stable. Pre-alpha means the names in these pages can change between commits.