One window,
twelve hundred
barrels

Two briefs in the studio archive need three dimensions. Both start from a photograph, not from an idea about software.

The Infinite Chai. A barrel room shot on the BMPCC with the IRIX 15, then rebuilt in Blender: the envelope, one barrique modelled properly, the rest instanced. Then the room is extended past its own architecture (a hundred columns deep instead of the thirty the building has) with the light held realistic across the whole distance. Gursky for the extension, Kubrick for the one-point perspective, Sugimoto for the framing.

Vine Geometry. One post, four sagging wires, one vine stock. Geometry Nodes arrays it into a vineyard and a single leaf-density parameter runs the twelve-month cycle: bare wire, budbreak, full canopy, véraison, stripped. Rendered from the same elevated position the 907X shot from, so the frames can be compared directly. Agnes Martin for the grid, the Bechers for the typology.

Both are built for the same wall. Renders hang beside real 907X frames, same size, same frames: 80 × 80 or 100 × 80 in Caisse Américaine, panoramas at 120 × 67 on Alu Dibond brossé, and nothing on the wall says which is which. If a visitor can sort them, the piece has failed at the only thing it is trying to do.

That constraint is the whole reason the technical detail below matters. A render that is merely beautiful fails. It has to be indistinguishable, and indistinguishable is a measurement.

The demos that circulate are missing the middle. You see the prompt and the finished render, never the broken geometry, the missing texture, the camera pointed at a wall, the fifteen attempts. That work still happens. What changes is who does it.

Kimi K3 does not hand back a mesh you cannot edit. Through Kimi Code it connects to an MCP server and uses the tools that server exposes. For Blender, the server most people run is ahujasid/blender-mcp: an add-on opens a socket inside a running Blender, the server talks JSON over TCP to it, and the model drives the session already on screen.

It is worth being precise about how thin that server is, because the write-ups usually are not. There is no dedicated tool for cameras, or lights, or materials. There are four tools.

Blender is an awkward room for a language model. It has to hold three-dimensional space, keep twelve hundred object names straight, judge a composition, read a picture of its own work, and remember a decision it made forty steps ago.

K3 is built for that shape of job. It landed in July 2026 as an open-weight model: 2.8 trillion parameters with 104 billion active per token, native vision over text, images and video, and a million-token context window. Moonshot's own name for the workflow is “vision in the loop”: alternating between writing code and looking at live screenshots.

That is the part worth paying for. A model that builds a scene and forgets every decision is an asset generator with extra steps. A model that keeps the scene, looks at the render, names what is wrong and changes only that can be given a note. The practice already runs on notes.

This is where most previs is wasted. If the virtual camera does not see what the real camera sees, the render is a picture of a room and not a shot list. Sensor dimensions and focal length are not approximations; Blender computes perspective and bokeh from them, and both have to be entered by hand.

Here is roughly what the first script does. It is not good, and it is not supposed to be. It is a starting point specific enough to criticise, which is the one thing a blank scene never gives you.

Predictably, and that is the useful part. The failures are known in advance because they are the same failures the light recipe was written to avoid.

The window at 50 watts reads as an invitation; the room has to be mostly dark, so it comes down to 30. Scatter density above 0.03 turns the air to milk and the shaft disappears into it. Barrels on a perfect grid read as a warehouse rather than a cellar, so each instance needs a little rotation and height jitter. And the perspective is wrong by construction: the window sits 4.6 m up the far wall while the camera looks dead level from 1.55 m, so the vanishing point lands three metres under the light. Kubrick's whole trick is that those two are the same point.

Every one of those is a single parameter. That is the argument for the loop: the model takes a viewport screenshot, compares it against the brief, and edits the object that caused the problem. Not a new image: the same scene, one value changed. Then it looks again.

K3 can build the scene. It cannot tell you the shot is good. Ask for “more cathedral” and you get more fog, because fog is the parameter nearest to the word. The instruction is understood and the reason behind it is missed.

So the division of labour is the ordinary one. Direction is human: the shaft lands on the fourth column and not the first, the blacks stay black, the barrels have to look stacked by a cellar hand and not placed by a script, the aisle has to read as longer than a building can be without reading as fake. The model executes and re-renders, as often as that takes.

That is a smaller sentence than one prompt making a film. It is the version that survives contact with a print deadline.

Give a model a socket into Blender and it makes unwanted changes at the speed it makes useful ones. “Tidy up the project” is an instruction that can rename twelve hundred objects, purge materials it judged unused, reorganise collections, and overwrite a script.

The vendors say as much. Kimi Code's MCP documentation asks for manual approval on high-risk tools (file writes, command execution) and warns against blanket mcp__* wildcards that approve a server's whole surface at once. blender-mcp's own guidance is that execute_blender_code runs unsandboxed Python at the same trust level as a terminal, and that a big scene should be built in several small calls, not one long one.

So these are the rules the project runs under. They are ours, and they are the boring part that matters.

Out of Blender as 16-bit EXR, linear, with AgX applied at the view transform only and never baked. Into Capture One, where it takes the same Chai Cathedral recipe the BMPCC low-light frames take: cool tint, saturation down, shadow detail lifted, a light vignette. Then to WhiteWall.

The moving version goes the other way. EXR sequence with cryptomatte into Resolve, cut against BRAW from the real chai, and graded once so the photographed and the rendered material pass through the same node. The drone from the Ableton chai piece sits under it.

The grade is where the seam closes. If the render takes the recipe and the photograph takes the recipe, they match in Capture One, not in Blender, and not by being rendered harder.

Not automatic 3D art. A model with a socket into Blender does not replace knowing how to light a room, and it will not turn a sentence into a finished sequence.

What it shortens is the distance between a brief and an editable first version. Envelope, instancing, initial lights, a matched camera, a look at the preview, one obvious problem corrected, inside a file that stays a file, with the geometry, the materials and the script all still open.

Image generators hand back finished outputs that are hard to control. This hands back an unfinished production that keeps taking notes. Less magic, and closer to the way the rest of the practice already works.