An AI studio that makes films and 3D prints in Blender

I do not know how to use Blender. Despite that, over a few days in October 2026 my AI agents produced a watertight, 3D-printable phone stand, a 199-gram printable mug, and a 300-frame film of a person leaping across a city gap while the letters “LSN” gather from sparks. The agents drive Blender over a tool protocol; I watch, and occasionally take over, through Blender’s own window in a browser tab.

This post is how that studio is built, and the specific ways a text-only language model fails at 3D work, because those failures are the interesting part.

Contents · 10 sections

TL;DR #

• You can let an AI agent build 3D models and short films through Blender’s scripting, exposed as a set of tools over a protocol, with a human able to watch and take over.
• Run Blender in a sandbox: no network, dropped privileges, and access only to its own project folder.
• A text-only model cannot see the result, so it will call a broken model “watertight”. Catch structural failures with geometry checks, or describe the render with a vision model.
• Give small models high-level build tools (a part in millimetres, fused into one solid), not raw scripting. The gap between “15 minutes and wrong” and “4 calls and correct” is enormous.
• Shared creative state is dangerous. An agent that deletes the open project pulls the rug out from under the next session.
• A long render is a GPU scheduling problem: know who else is holding the card.

The studio #

Blender runs in a container with no network access, reduced privileges, a normal unprivileged user, and only its working folder plus the graphics driver mounted read-only. Inside it runs Blender itself and an MCP server (MCP is the open protocol agents use to call tools) that exposes Blender’s Python scripting. On top of that sits a set of my own higher-level tools. There are two ways in: agents connect to the tool endpoint, and I open the same live Blender window, and a gallery of results, in a browser.

Why a sandbox, strictly: the natural way to drive Blender from code is to execute arbitrary Python inside it, and the official tooling marks that capability as destructive. A model that can run arbitrary Python is a model that can do anything the process can. Putting the process in a network-less, low-privilege container means the worst case is a damaged scratch project, not a damaged machine. (My agent’s own permission system still gates those calls; the sandbox is the second layer.)

High-level tools beat raw scripting #

The first version only offered “execute this Blender Python”. A capable model can use that; my local models could not. The smaller one got positions, units and rotations wrong or decided the task would take fifteen minutes; the mid-size one flailed through unrelated tools. Raw scripting asks the model to be a Blender programmer, which it is not.

So I built tools that speak the language of the object, not the software. To add a part you give its size in millimetres and where it sits (bottom-centred, or on top of another part with an alignment and offset), with optional tilt, bevel, text, and a cut-or-pocket flag. The tool fuses the parts into one solid mesh. A build that was fifteen confused minutes of scripting became 4 tool calls producing one watertight object, rendered in about 13 seconds.

The same lift applies to whole jobs: there are templates for common objects (a phone stand, a wall hook, a box with a lid, a coaster, a keychain tag, a shelf bracket), each tested to export as one watertight piece. The model picks a template and adjusts dimensions, instead of designing geometry from nothing.

Around the geometry are tools for the rest of a shot: an automatic camera and three-point lighting, lighting presets, backgrounds (solid, gradient, studio sweep, sky, image-based, transparent), materials with physically-based textures, a product-shot mode with a shadow-catching ground, physics drops, turntable video, and film tools for rigged characters, a jump animation, a lit night city, and a title effect.

Output: prints and CNC need honesty #

A render that looks right can still be unprintable. The 3D-print export produces STL and 3MF in millimetres and, crucially, a printability report: holes, non-manifold edges, inverted normals, overlapping bodies, thin walls, overhangs, and how much of the model actually touches the build plate. There is a repair pass and a voxel re-solidify for models that cannot be fixed cleanly. CNC and laser export produce outlines and cross-sections with holes, and a 16-bit height map.

Writing those checks exposed real geometry bugs in my own tools: a fan triangulation of concave shapes that lost boolean holes in the exported mesh, an even-odd rule that marked overlapping bodies as holes, and a stale pivot that offset the turntable camera. Export is where a modelling mistake becomes a wasted spool of filament, so it is the one place that must not be optimistic.

How a text-only model fails at 3D #

This is the heart of it. A language model with no eyes cannot judge a 3D scene, and it does not know that it cannot.

The clearest case: an agent built a phone stand that was actually five loose pieces with a floating lip, and its print report said “watertight, no problems”. The text-only model could not see the preview, so it reported success from the fact that the tools had returned without error. It then went looking on the host filesystem for studio files that exist only inside the sandbox.

Two fixes, because neither alone is enough:

• Structural geometry checks that do not need sight: separate or floating pieces, tiny or zero contact with the build plate, non-manifold geometry. These catch the “five loose pieces” failure deterministically, before any render.
• A vision model describes the render. When the agent produces an image, a vision-capable model turns it into text the driving model can reason about. On the broken stand it reported the floating bar in about 13 seconds. I run the describer on a model that shares the GPU without evicting the main agent model.

A related failure: the model would “verify” a drop animation by rendering a frame where the object was still in mid-air, see it floating, and loop. The fix was to end a physics drop on the rest frame and to render the current frame, so the still shows the object where it settled. Small models also tended to repeat an identical tool call and then “wait”, so the tools now reject identical repeats and expose an explicit job-status poll instead of a sleep.

Shared creative state is a hazard #

The studio’s Blender is shared: agents drive it and I watch the same live session. That makes one operation dangerous in a way it would not be for a private file. An agent deleted its own scratch project’s folder while that project was still the open one in the shared Blender. The next session, continuing my work, found saves failing and files landing in the deleted project.

The rule now: every studio answer names the open project and refuses when its folder is missing; a test routine must re-open the real project before deleting anything it created. Shared mutable state needs an explicit “which project am I in?” check on every operation, not a convention that everyone is trusted to follow.

A long render is a scheduling problem #

The films are rendered with the path tracer on a single GPU that also serves language-model inference, embeddings and other work. The lesson from the first film is that frame time is dominated by contention, not by the scene:

• about 60 seconds per frame with background model workers, an image-OCR service and media transcoding all touching the GPU;
• about 51 seconds after stopping the model workers and pausing OCR;
• about 16 seconds per frame once a six-hourly embedding job finished.

A 300-frame film is five hours or ninety minutes depending entirely on what else is running. Two non-obvious traps: “pausing” the OCR service only stopped it queueing new work while it kept a model loaded in GPU memory, so it had to be scaled to zero to really free the card; and a periodic indexing job quietly re-embedded tens of thousands of documents for over two hours, visible only as short-lived connections to the inference server. Before a long render I now stop the known GPU users and avoid the indexer’s window. And I never redeploy the studio during a render, because that restarts the container.

Checklist #

• Run the creative engine in a network-less, low-privilege sandbox; treat “execute arbitrary script” as destructive.
• Give models object-level tools (size, placement, fuse to one solid), not raw scripting.
• Ship templates for common objects, each verified to export cleanly.
• Make export report printability honestly: manifoldness, bed contact, thin walls, overhangs.
• A blind model needs geometry checks and a vision describer; use both.
• End physics on the rest frame; reject repeated identical tool calls; poll job status, never sleep.
• For shared state, name the open project and refuse on mismatch every call.
• Treat a long render as a GPU scheduling task; know and stop the other users.

Frequently asked questions #

Can an AI agent really make a 3D-printable model if I cannot use Blender? #

Yes, if it drives Blender through high-level tools and the export checks printability. My agents produced a watertight phone stand and a printable mug this way; I never touched the Blender interface except to watch.

Why does a language model call a broken model “watertight”? #

Because a text-only model cannot see the result and infers success from tools returning without error. The fix is to add deterministic geometry checks (floating pieces, bed contact, manifoldness) and to describe the render with a vision model, so the driving model has real feedback.

Why run Blender in a sandbox? #

Because driving it from code means executing scripts inside it, which can do anything the process can. A container with no network and reduced privileges limits the worst case to a damaged scratch project.

What makes AI-driven renders slow? #

Usually not the scene. On a shared GPU, frame time is dominated by whatever else is using the card. The same frame took 60 seconds under contention and 16 seconds alone.

The lesson #

Giving an AI agent a creative tool is less about the tool and more about closing the loop the model cannot close by itself. A text-only model will confidently ship a broken object because it never sees the object, so you supply sight: deterministic checks for structure, a vision model for appearance, honest export reports for printability. Wrap the engine in a sandbox, hand the model object-level tools instead of a programming language, guard the shared session, and schedule the GPU. Then someone who cannot use Blender can still direct it to make a film.