Step2

The brick kit

18 September 2026 · 3 min read

blenderbrickspipeline

A wide review sheet of a small blue brick tank, a purple and grey round tower and a tiny brick person, each shown from three angles.

Every unit and building in Brick & Mortar is built from plastic bricks. Nobody sat in a 3D program placing them. This step is about the script that does it, which we wrote on 17 September and spent most of the 18th fixing.

The idea

A brick model is a list of parts, each with a position and a rotation. That is a data structure. If Claude can write the list, Blender can build the model, and the same list can be exported for Unreal Engine.

We needed three things:

A parts library. The open LDraw library has about 24,700 parts under a CC-BY 2.0 licence. We keep it outside the repository and credit it in the game.
A loader. scripts/ldraw.py reads LDraw files, follows sub-part references, fixes winding order (so faces do not render inside out), swaps expensive round primitives for cheaper ones, and culls faces nobody can ever see between two bricks that touch.
A kit. The kit script is a grid API: place a brick at a stud position, stack a plate, build a wall, add a slope. A model script reads like a build manual.

The model scripts live in a single file (it has grown to nearly 25,000 lines by the time we are writing this). Blender runs them headless and writes one FBX per model, plus a rigs.json that tells the game where the turret pivots, where the muzzle is, which parts spin.

What Claude did, what the owner did

Claude wrote the loader, the kit and the first set of models. The owner supplied photos of existing brick builds by hobbyists and their own concept images, and judged every result by eye. That split held for the whole project: the AI proposes a model, the human gives the verdict, and we do not iterate past what the human judged.

For anything that is going to be shot to pieces we added a trick on day one. Blender records every piece it places. A k-means clustering step groups those pieces into 4 to 23 chunks per model, and the game spawns the chunks as wreckage when the model dies. A building does not vanish; it falls into the bricks it was made of.

The bugs of day two

None of these were deep. All of them were embarrassing.

The headless tanks. Every unit's menu icon (we call them cameos) was rendered by a script that placed each part at the hull's origin. Turret vertices are stored relative to the turret's own pivot, so every cameo showed the turret sunk inside the hull and the barrel hanging off the front corner. In the game itself the turrets were always fine. We re-rendered all 46 cameos once the cause was clear.

Frozen arms. Our little brick people exported in a half-raised pose, so the arm ball sat turned out of its socket and looked bolted on. The fix was to export all of them at rest and let the game pose the arms.

Ore as bricks. We had yellow pyramids for ore. The owner asked for something better, such as gold-tinted brick piles. Five variants built from real parts replaced them that evening, and that small change did more for the look of the map than any shader.

A three-quarter-view review board of a brick aircraft carrier shown from three angles on a grey background — A review board: three views of a build, judged on its bricks and not on the lighting.

Reviewing a model

A model is not done when the script runs. It is done when a human says so. We built a review sheet: the reference on one side, three views of our build on the other. Claude looks at the crops itself first, and the owner sees only the ones that pass.

blender -b -P scripts/blender_ldraw.py -- --no-export --only Id --review Docs/review_renders/after
python scripts/model_review.py Id

What we would do differently

Render icons and renders from the same data path as the game. We had two paths, and they disagreed.
Put every model's size in studs in the log, so a scale error shows up as a number and not only to the eye.
Ask for the verdict earlier. A model that looks fine to the script can still look wrong to a person in one second.

Try it yourself

Treat your 3D assets as code. A model that is a script can be rebuilt, reviewed in a diff, and fixed in one place. The first hour is slower. The second week is much faster.

Next: Making the ground real - why only the bricks are stylised (19 September 2026)

Start at Step 1 All 27 steps