Procedural Mesh — Blender Python & AI-Assisted Geometry

Using Python scripts inside Blender to generate, manipulate, and export geometry — rather than modelling by hand. The config block is the model. Changing a dimension means editing a constant and re-running, not touching a mesh.

Two related but distinct approaches:

  • Parametric generation — the script builds geometry from scratch. Holes, plates, text engravings, export to STL, automated renders. The shape lives entirely in code.
  • Mesh manipulation — an existing STL is imported and cut up. Different problem: no parametric handle, working with whatever the downloaded mesh gives you.

Both involve AI in the loop — either iterating on the Python with Claude, or using AI to determine cut planes on existing geometry.


Stages

StepStatus
0Manual Blender modelling — Packat & Klart badge and scout emblem casting master; learning the tool before scriptingDone
1Approach documented — Python scripted geometry, config-block iteration patternDone
2Rack Support Brace — first implementation; flat plate, boolean hole grid, engraved text, automated rendersDone
3Headless render — Blender 5.1.2 + Dagger pipeline; STL → multi-angle PNGs without opening Blender; smoke-tested and running in CIDone
4Scout Buckle — complex geometry; compound curves, functional tongue mechanism, tolerances that matterIn progress
5CI/CD pipeline — STL or script change → GitHub Actions → Dagger → PNG artifacts; procedural-mesh-pipelineDone
6AI feedback loop — describe correction → updated script → re-run, without opening BlenderPlanned
7Dragon Split — mesh manipulation; cut an existing articulated dragon STL into printable segments with connectorsNot started

Notes

The rack brace (step 2) was easier than expected — straightforward geometry, minimal iteration. That is why the pipeline steps did not get built yet: the manual workflow was fast enough that the overhead of automating it was not justified for one part.

The scout buckle (step 4) is the harder test. Compound curves and functional constraints mean the script has needed partial rebuilds rather than config-block edits. That is the case that justified building the render pipeline properly.

Steps 3 and 5 ended up built together rather than sequentially. The pipeline lives in a separate repo — procedural-mesh-pipeline — Dagger + GitHub Actions, Blender 5.1.2 headless, Cycles CPU. Renders run natively on the CI runner (amd64); locally the pipeline is used for smoke-testing the image only. Blender has no official ARM64 Linux binary so local renders under emulation are impractical.

The dragon split (step 7) is a different class of problem — remixing rather than generating. Worth keeping in the same project because the tooling overlaps (Blender Python, STL export) even if the approach does not.

Built with Hugo
Theme Stack designed by Jimmy