The editor

The editor is a desktop application for building Orblit projects. It is written in Flutter, with the same widgets a game uses, and it draws its viewports with the same renderer a game does. So what it shows you is what ships, not an approximation of it.

Getting it

There are no signed builds yet. Clone and run:

git clone https://github.com/ChxisB/orblit.git
git clone https://github.com/ChxisB/orblit-editor.git
cd orblit-editor
flutter run -d macos

macOS is the only platform it draws on. The repository has Linux and Windows runners as well, but the editor only starts the renderer on macOS. On those two, every viewport reads “The 3D viewport is not available on this platform yet.” CI builds the macOS app and nothing else.

The two checkouts must be siblings, and must be named exactly orblit and orblit-editor. The editor depends on the engine by path, not by git revision, and that is deliberate. The renderer and the editor change together, and a git dependency would put a push and a pub upgrade between writing a renderer change and seeing it.

What is in it

Scene	Hierarchy, inspector, gizmos, four viewports and a game view
Materials	Authoring, preview, per-face assignment
Geometry	Parametric shapes and mesh editing, in the viewport
Terrain	Brushes for shaping ground, painting materials and placing scatter
Interface	A canvas for the same UI document a game draws
Prefabs	Reusable objects as .oprefab assets, placed as linked instances that keep their own changes
Animation	A timeline for .oclip clips, with a dope sheet, a curve view, and keys set from the inspector
Cinematics	Cutscenes that cut between the scene’s cameras, with each shot framed by steering the view
Examples	The worked examples, live, beside your projects
Scripting	Writing and compiling scripts, and checking them

Virtual cameras that frame what a shot should hold are in the engine, as orblit_camera, but the editor has no panel for them yet. The timeline keys a clip on what the scene holds, and doesn’t yet pose a model’s bones.

Workspaces

The tabs at the top follow the work: Scene, Modelling, Terrain, Animation, Cinematics, and Interface. Each has its own panels. They share the scene, selection, camera and undo history. Code opens in your outside editor.

• Scene places objects and shows what the game’s camera sees.
• Modelling edits a shape’s points, edges and faces, with texture coordinates below the view.
• Terrain shapes and paints the ground. Brush tools have labels; scroll the shelf sideways if the window is narrow.
• Animation opens an object’s first assigned clip. Make a clip creates one and links it to the selected object. The top Play button previews assigned clips on a copy of the scene. It does not run scripts or physics.
• Cinematics makes cutscenes. Cut between cameras in the shot list, key the scene on the timeline under the view, and watch the finished shot beside it. Use this view puts a camera where the view is, and Look through frames a shot by moving.
• Interface lays out menus and controls on the canvas. An empty canvas offers New interface.

View › Reset panels restores the current workspace’s default. Save layout, Load layout, and Delete layout keep named arrangements for this project and workspace. Saving an existing name replaces that arrangement. Deleting a name leaves the current panels alone.

View › Focus view hides the surrounding panels. Show panels brings the same arrangement back. Each workspace remembers focus separately during the session. Stats reveals rendering counts and frame timings.

In every scene in the Hierarchy contains objects shared by the whole project. Snap in the view switches grid snapping on and off.

Every edit is a command

Nothing in the editor changes the document directly. An edit is an object with an apply and a revert, and the document is what you get by applying the ones on the stack.

That is why history came first, before most of the panels existed. Adding undo to an editor that mutates its document means rewriting it. Building panels on top of a command stack does not. It also means every panel gets undo for free, and no panel can get it subtly wrong.

The examples are in it

The worked examples show up in the launcher, beside your projects. They come from the same package the gallery application uses, so an example is written once and the two cannot drift apart.

They sit there, and not inside a project, because that is where the question gets asked. “How is a day cycle done?” comes up while you are deciding what to build. If you have to close your work to reach the answer, you will go and look it up somewhere else.

What it is not

It is not required. A game is a Flutter application, so you can write one in a text editor and never open the editor at all. The editor is for the work that is easier with a viewport in front of you: placing things, tuning materials, modelling a shape, laying out an interface. What it saves you is files you could have written by hand.