Anvil Level Design gives Blender a Trenchbroom style level design workflow

A level design toolset that lives inside Blender

Anvil Level Design is a Blender addon intended to speed up and support video game level design, and the project states plainly that it is particularly inspired by Trenchbroom and Source 1 and 2 Hammer. That inspiration is the design brief. Trenchbroom and Hammer are dedicated level editors built around a specific way of working: you pick a brush, you point at a face, you apply a material, you place a prefab, and the tool handles the geometry bookkeeping for you. Blender is a general 3D package, so none of that comes for free. Anvil adds it. The combination is described as material application and adjustment tools, navigation user experience including 3D view navigation and specialised material and prefab browsers, geometry helpers including blockout tools, and a collection of miscellaneous user experience improvements. The audience is therefore environment artists and level designers who already live in Blender for modelling and texturing but want the ergonomics of a level editor for the blockout phase.

Materials and prefabs get their own browsers

The material and prefab browsers are the part of Anvil that most directly reflects the Trenchbroom lineage. A dedicated browser for materials means you are not hunting through a dropdown of every datablock in the file, and a separate browser for prefabs means the level is assembled from a browsable, categorised set of pieces rather than from whatever happens to be in the outliner. That sounds mundane until you consider what level design actually costs. In a blockout, the work is repetitive by nature: place a wall, check the material, adjust, place another wall. Every second spent in a file browser or a search dialog is multiplied by hundreds of placements. The repository layout backs up the claim that these are real subsystems rather than a couple of operators. There is a dedicated texture_browser/ directory, a prefabs/ directory holding the prefab content, a hotspot_mapping/ directory, and handlers/ and operators/ directories for the behaviour, with panels/ for the interface and core/ for the underlying framework, plus properties.py for the property definitions and workspace.py for workspace management. A materials_and_prefab browser is exactly the kind of thing that needs those separations, because the data model of Blender objects, meshes and datablocks does not give you that structure for free.

Blockout helpers and the hidden data behind them

Geometry helpers including blockout tools sit alongside the browser work, and a blockout tool in a level designer is not a modelling tool. It is a way to stamp a shape into a level with the right dimensions, the right grid alignment and the right material, and to keep that alignment as you move and rotate things. The repository makes visible that Anvil deals with the bookkeeping a level needs and a general 3D package does not. The hotspot_mapping/ directory points at a feature the project surfaces elsewhere: the examples/ folder ships a hotspot_tutorial.blend file, which suggests a hotspot concept where specific points on a piece of geometry carry semantic meaning. That is the sort of thing a level needs and a mesh does not. The workspace.py and workspaces.blend files at the root indicate that Anvil manages its own workspace layout, and the .blend file name in the repository root is a giveaway that the addon ships a prepared workspace rather than assuming you will build one. The presence of workspaces.blend alongside the addon code is a small signal about how the project expects to be used: open the provided workspace, work in the designed layout, and the tools behave the way the author intended.

Engine agnostic means the export is the boundary

Anvil is currently engine agnostic. Levels are intended to be exported to .fbx and .gltf / .glb, and the project says it currently includes .glb export helper functions, that in future it will include .fbx helper functions, and that it may include reference implementations for game engine import workflows. Those three sentences describe the whole state of the pipeline honestly. Today the tool takes you as far as a glTF binary with some helper functions around it. FBX, which many engines still prefer, is future work. Reference import implementations, the thing that turns an exported file into a working level in Unreal or Unity, are may. So if your workflow needs a clean, configured import on the engine side, Anvil will not do that for you yet, and you should expect to write that half. The alternative approach is a dedicated editor such as Trenchbroom, which is engine aware by construction and knows how to write the data an engine expects, at the cost of leaving Blender for the blockout and coming back for the polish. Anvil wins when the artist already works in Blender and the interchange is a glTF file the engine side can already consume.

The project is a tool in progress, with a funding model attached

A few things about how the project is run are worth knowing before you invest time in it. The documentation does not give installation steps in the repository itself; it points to an installation page on the documentation site with tutorial videos, and a separate quick start page the same way, so the real setup guidance lives at anvilleveldesign.com/docs. There is a Discord server for discussion, a Patreon page for the author, a project website, and the author runs a separate site for the work. The repository has a CHANGELOG.md and a CONTRIBUTING.md, a LICENSE.md, and a tests/ directory alongside a run_tests.bat script, which is a Windows batch file for running the test suite, with a scripts/ directory for tooling. The last push to the repository was on 2026-08-06 and the repository is not archived, so the code is present and being worked on, but there are no GitHub releases, so there is no tagged version history to anchor to and an upgrade means tracking the main branch. One more detail stands out. The project states plainly that LLM coding assistance is used in the development of Anvil. That is a statement about how the code is written rather than about what it does, but it is a reasonable thing to know when you are deciding how much of the source you want to read, and it is unusual enough that the project evidently considers it worth stating.

Editorial conclusion

Adopt Anvil if you block out levels in Blender and want material assignment, prefab placement and navigation to behave the way they do in Trenchbroom or Hammer, and you are willing to work inside Blender's data model rather than a dedicated editor. Do not adopt it if you need a finished engine import pipeline today, since the project says it is engine agnostic, ships glTF export helpers, and describes FBX helpers as future work. Before you commit, read the installation and quick start pages on the documentation site, check that the Blender version you use is supported, and verify in the changelog whether the workflow features you depend on have changed recently.

Frequently asked questions

Official sources

1. alexjhetherington/anvil-level-design on GitHub
2. Issues
3. License: GPL-3.0
4. README