Jackdaw: a Bevy 3D editor with a scene hierarchy, an inspector and a CLI

An editor for Bevy, by people who follow the Bevy editor prototypes

Jackdaw is a 3D editor built for and with Bevy, and the author is direct about its state: very early in dev, expect bugs and changes.

That framing is worth keeping in mind, because the release history supports it. The three most recent tags are all release candidates for the same Bevy version, v0.19.0-rc.10 on 2026-10-11, v0.19.0-rc.9 on 2026-10-10 and v0.19.0-rc.7 from 2026-08-07. Shipping three release candidates for one engine version, and skipping rc numbers, is what a project that has to track an unstable upstream looks like.

The design lineage is stated as well. The README links the Bevy Editor Vision, Architecture and Roadmap pages from the bevy_editor_prototypes repository, and says the project has refactored its UX and UI to be very similar to the official Bevy Editor Figma design, for consistency. There is a Figma link and a Discord invite badge.

So this is not a generic 3D editor with a Bevy exporter. It is an editor built inside the Bevy ecosystem, following a prototype roadmap that Bevy itself published, and matching an interface design that Bevy has drawn. That is a coherent bet: if Bevy ships its own editor one day, this project has already converged on the same shape.

The project is written in Rust, dual-licensed under MIT or Apache-2.0 at your option, and the last push was on 2026-10-18.

Installing means a shell one-liner, a PowerShell one-liner, or cargo

There are three install routes, and all of them need the same toolchain underneath.

On Linux (x86-64) or macOS (Apple Silicon) the README gives a curl piped to sh install script:

curl --proto '=https' --tlsv1.2 -LsSf https://github.com/jbuehler23/jackdaw/releases/latest/download/install.sh | sh

On Windows, in PowerShell, it is the equivalent:

irm https://github.com/jbuehler23/jackdaw/releases/latest/download/install.ps1 | iex

Or you can download an archive from the releases page, or install with Cargo:

cargo install jackdaw jd --locked

That Cargo line installs two binaries, and the naming is the point. jackdaw is the editor itself and jd is the command line tool that sits alongside it.

Every way you need rustup and a C/C++ toolchain, and jd doctor checks them. That diagnostic command is more useful than it sounds, because a missing C compiler or an incomplete rustup install produces errors deep inside a build rather than a clear message, and the doctor command tells you which of the two you are missing before you start.

There is an installation guide that covers each operating system and a troubleshooting page for common problems, both in the project book.

The command line does the project setup, not just the launching

The jd tool is not only a launcher. The README shows the same flows available from the terminal as from the editor interface:

jd new my-game && jd open my-game   # create
jd import /path/to/game             # preview integration for an existing game
jd import /path/to/game --apply
jd doctor --project /path/to/game   # why isn't this working?
jd upgrade /path/to/game --apply    # after a Jackdaw update

Read the comments on the right, because they are the actual documentation. jd new creates a project and opens it, jd import previews the integration for an existing game without applying anything, and adding --apply is what commits the change. jd doctor takes a project path, so the diagnostic is project-scoped rather than machine-scoped. And jd upgrade is how you move an existing project forward after a Jackdaw update, again with an explicit --apply.

The pattern throughout is preview then apply, with the destructive step behind a flag. That is the right shape for a tool that rewrites your manifest.

The safety property is stated plainly: import adds jackdaw_runtime to your manifest and wires its plugin in, and never edits your lockfile, toolchain, or target/. The lockfile point matters, because a tool that regenerated a lockfile would silently change every dependency version in your build, and a tool that touched the toolchain file would change your compiler without asking.

The editing features, and which of them are still rough

The feature list is where the maturity of each area shows, because the author annotates the uncertain ones.

Brush-based geometry is the headline: draw, edit, and CSG-combine concave brushes with vertex, edge and face editing modes. The materials system is marked VERY wip, with a texture browser, material definitions with ORM auto-detection and per-face application. Terrain is described as heightmap sculpting and texture painting, very WIP.

Scene serialization is more settled: save and load scenes in the .bsn format with full asset references, and older .jsn scenes are migrated on open. That migration note is a good sign, because it means the format has already changed once and there is a path for old files.

The transform tools are translate, rotate and scale with grid snapping and axis constraints. Undo and redo is a full command history, with some bugs atm. And the extensibility promise is that you can register custom components, add inspector panels, and integrate with your own game.

The undo caveat deserves emphasis in a level editor. An editor where undo silently loses the last operation is worse than one with no undo, because you stop trusting the history and start saving manually. The bugs are acknowledged, so this is a known state rather than a discovery.

The two work-in-progress areas, materials and terrain, are the two that a level editor is hardest without, since a scene with no materials and no terrain is a blockout at best.

A runtime crate, an editor crate, and a CLI to keep them apart

The crate structure is the interesting design decision, and it is spelled out clearly.

Jackdaw is a standalone editor. Game applications depend only on jackdaw_runtime. To build a custom standalone editor, you depend on jackdaw_editor instead, and the README gives the whole thing as a plugin setup:

use bevy::prelude::*;
use jackdaw_editor::prelude::*;

fn main() -> AppExit {
    App::new()
        .add_plugins((
            DefaultPlugins.set(editor_window_plugin()),
            PhysicsPlugins::default(),
            JackdawEditorPlugins::default(),
        ))
        .run()
}

The separation is the point. Your shipped game pulls in the runtime and not the editor, so the editor code, the assets and the tooling never reach the binary you ship.

Loading a scene into your own game is then two lines, because the runtime provides a scene root component:

use bevy::prelude::*;
use jackdaw_runtime::prelude::*;

fn spawn_scene(mut commands: Commands, asset_server: Res<AssetServer>) {
    commands.spawn(JackdawSceneRoot(asset_server.load("scene.bsn")));
}

Runtime extensions use a focused jackdaw_extension crate and install as signed .jdext bundles. In precompiled and shared-SDK builds, install, update, disable and uninstall take effect without restarting, and superseded native mappings are reclaimed when Jackdaw exits.

The published package manifest shows the same care about what ships. The jackdaw package includes only the library source, the assets referenced by embedded_asset!, the manifest, the licence files and small logos, with a comment explaining that everything else in the repository, including the book and the demo assets, stays out of the .crate so it fits under the crates.io 10 MiB upload limit. It also ships two binaries, the editor and a jackdaw-rustc-wrapper, a rustc interceptor used by scaffolded extension projects, with default-run set to the editor.

Shortcuts, documentation and the shape of the repository

The keyboard shortcut tables are short and worth having, because the navigation scheme is the thing you will feel first. Right mouse button plus drag looks around, WASD moves, Q and E move up and down, Shift is double speed, scroll dollies forward and back, and F focuses the selection. The editing table gives Esc, R and T for translate, rotate and scale modes, B and C to draw a brush for add and cut, 1 to 4 for brush editing in vertex, edge, face and clip modes, Ctrl+D to duplicate, Delete to remove the selection, Ctrl+Z and Ctrl+Shift+Z for undo and redo, and Ctrl+S to save the scene.

The focus key and the mode keys are the ones that make an editor feel like a tool rather than a demo, and their existence is a decent proxy for how far the implementation has come.

The documentation is a book hosted on GitHub Pages, with a user guide, a developer guide and a reference, plus runnable examples in the examples directory and rustdoc on docs.rs. The examples are not toy files: there is an author_bake_loop_world example, a grid_yield_verify, a remote_game, a scene_load, a terrain_clipmap_verify and a terrain_splat_verify, plus an extension folder. The verify and bake naming suggests the project is being used to check that its own terrain and grid systems behave.

The repository root has the crates/ directory for the multi-crate layout, a book/ directory for the documentation source, examples/, integrations/, scripts/, src/, tests/ and an xtask/, plus a rust-toolchain.toml, a clippy.toml and a .config/ directory. The .jsn/ directory at the root is the older scene format kept for the migration path.

Editorial conclusion

Adopt Jackdaw if you build games with Bevy and want a level editor that speaks the same engine, and you are willing to work with a project the author describes as very early in development. Do not adopt it for a production pipeline that needs stable file formats, since the .bsn format is new and the material system and terrain tools are both described as work in progress. Before you start, run jd doctor, which checks the rustup and C/C++ toolchain every installation route needs, and read the import preview carefully, because it shows every proposed change before applying it and never touches your lockfile, toolchain or target directory.

Frequently asked questions

Official sources

1. Issues
2. jbuehler23/jackdaw on GitHub
3. License: Apache-2.0
4. README
5. Releases