Join in
Orblit is pre-alpha and community-led, which in practice means the most useful thing anyone can do right now is try to use it and tell us what happened.
The repositories
Section titled “The repositories”orblit |
The engine | Twenty-one packages: the C++ core, the renderer, the interface layer, scene files, geometry, rigging, cameras, agents, weather, 2D, input, effects, sequencing. What each one is. |
orblit-editor |
The editor | A desktop application built from the same widgets, drawing with the same renderer. More. |
orblit-examples |
Worked examples | The gallery, the viewport app, and a headless simulation. Running them. |
orblit-craft |
A whole small game | A block world you walk around, dig and build in. It exists to put weight on the parts the small examples do not. |
orblit-net |
Multiplayer | Replicated component columns, ownership, acknowledged deltas. More. |
orblit-script |
Scripting | TypeScript on QuickJS, as a peer of Dart over the same core. |
orblit-filament |
The renderer fork | Filament, with the changes the engine needs carried on top. |
orblit-site |
This site | Every page has an “Edit this page” link at the bottom that goes straight to it. |
What is genuinely useful right now
Section titled “What is genuinely useful right now”Pre-alpha software needs a particular kind of help, and it isn’t the kind people expect. In rough order of how much it does for us:
Try to build something, and tell us where you stopped. Not a bug report: just the point at which you gave up, and what you were trying to do at the time. That’s the single most valuable thing anyone can send, because the people who wrote the engine can’t see their own assumptions.
Tell us when a page on this site is wrong. Every Dart snippet here gets compiled against a real checkout in CI, so the code should be correct. Correct code attached to a misleading explanation is still a broken page, though, and that is the sort we can’t catch automatically.
Run it on hardware we haven’t got. Platform support is precise about what renders where, and the gaps are mostly gaps in what has been tested rather than in what has been written. An Apple Silicon Mac, an Intel one, a Steam Deck: whichever way it goes, the result is something we don’t currently know.
Argue about an API before it sets. Nothing is API-stable yet. That’s a warning if you’re using it, and an opportunity if you’re willing to say “this name is wrong” while changing it is still cheap. After 1.0, that conversation gets a great deal more expensive.
Send a pull request. Fair warning about what that involves: every
repository runs check.sh, the documentation’s snippets get compiled, and
versions are checked. The gates are there so that a green build actually means
something.
What to expect back
Section titled “What to expect back”Being straight about this saves everyone time.
- Nothing is API-stable. Names in these pages can change between commits. Pin a git SHA if you need a week of quiet.
- Rendering has been seen on macOS, the iOS simulator, an Android handset and Chrome. Linux has only drawn against software rasterisers, and Windows builds but has never drawn a frame. Safari and Firefox haven’t been tried. Everything that doesn’t draw runs anywhere Dart does, including headless CI. Platform support has the detail.
- There’s no asset store, no asset cache and no physics solver. glTF loads, and FBX and OBJ are converted on the way in. Shapes, raycasts and overlap tests exist. A rigid-body integrator doesn’t.
- There’s no release cadence yet. Packages are versioned on every feature. See VERSIONING.md.
If that list would make the project unusable for you, then it will, and it’s better to find that out now than in three weeks. If it reads as an invitation, the Discord link is at the top of this page.