3D Design With AI in 2026: Agents, Blender and the Open-Source Wave

The shift: from generating pictures to operating software

For three years "AI and 3D" meant a model that outputs a mesh. You prompt, you wait, you get an object, and you either use it or you don't. The process is opaque, the result is unedited and uneditable in any structured sense, and your only lever is to prompt again.

The interesting development is the opposite arrangement. Instead of the model producing the artwork, the model produces the actions — it uses the same software you use, through the same commands you would type, and everything it does lands in a file you own and can inspect. Ask for a cyclorama backdrop and three-point lighting and you don't get a picture of a studio; you get a studio, in your scene, with a key light you can grab and move.

The plumbing behind that is the Model Context Protocol (MCP), an open standard for letting an assistant call real tools. It is not specific to 3D — it is how assistants read repositories, query databases and drive design software. 3D just happens to be a domain where the payoff is unusually visible, because you can watch it happen.

Why cheap code means more open-source 3D tools

Here is the part I am genuinely optimistic about, and it has nothing to do with any particular model.

Almost every 3D tool that should exist doesn't, and the reason has always been the same: the idea was worth an afternoon and the implementation was worth three months. A geometry-nodes utility that solves one annoying problem in one studio's pipeline. An exporter for a machine only forty people own. A viewer for a file format that matters to a single research group. Every one of those is a real need attached to an audience too small to justify a quarter of somebody's year.

That arithmetic just changed. When a competent assistant can turn a clear specification into a working add-on in an afternoon, the threshold for "worth building" drops by an order of magnitude — and the tools that appear below that threshold are overwhelmingly small, specific and free, because nobody builds a business around a utility that took a day. They get published, because publishing costs nothing and the author wants the bug reports.

There is a catch, and it is worth naming early: volume is not quality. A flood of one-afternoon add-ons also means a flood of unmaintained, undocumented, subtly-wrong add-ons. The ecosystem gets better on average and much noisier at the same time. Curation becomes the scarce thing.

Why Blender is the tool agents work best with

Blender is a free, open-source 3D suite that does modelling, sculpting, texturing, simulation, animation, video editing and production rendering — the whole pipeline, at professional quality, at no cost. It is the obvious recommendation for anyone starting out in 2026 regardless of AI. But it is also, for reasons that are mostly accidental, the 3D application that AI agents drive best.

1. It is scriptable end to end

Nearly every operation in Blender's interface has a Python equivalent, and the interface is itself written against that API. That is the surface an agent actually operates. There is no automation subset, no scripting-lite tier, no set of features reachable only by mouse. If you can do it, the agent can do it — which means the ceiling on what it can build for you is Blender's ceiling, not an API designer's guess about what should be automatable.

2. It is open, so the model has read it

The source is public. The manual is public. Twenty years of forum answers, Stack Exchange threads and add-on repositories are public. Every model worth using has read all of it. Ask about a closed package and you get a plausible answer assembled from marketing pages and outdated tutorials; ask about Blender and you get an answer grounded in the actual implementation. Openness is a training-data advantage, and it compounds.

3. Anyone can extend it, without asking

When the agent needs a capability that doesn't exist, it can write an add-on and install it. No developer programme, no signed plugin, no vendor approval. This is the difference between a tool that can grow to fit your problem and one that can't, and it is why the gap between open and closed software is going to widen rather than narrow over the next few years.

Blender MCP: prompting real geometry

The concrete implementation of all this is Blender MCP. A small add-on runs inside Blender and listens on a local port; your assistant connects to it. From there it can read your scene — object names, types, transforms, materials, mesh statistics — execute Blender's Python in the file you have open, and in some builds capture your viewport so it can look at its own work and correct it.

In practice you type something like "build a small still life: a wooden table with three ceramic bowls, lit from a window on the left", and it appears. Then you refine it the way you would talk to an assistant standing next to you: warmer light, camera lower, rougher glaze on the middle bowl.

The two open-source routes, honestly compared

There are two, both free, and it is worth knowing which you are looking at because the search results conflate them constantly.

The official server arriving is good news and worth saying plainly: it means this is not a passing bolt-on but a direction the Blender Foundation is investing in itself. Its emphasis is telling, too — documentation search and API access, rather than "make me a scene." The Foundation's bet is that the assistant's real value is knowing Blender better than you do, and that is closer to the truth than the demos suggest.

The setup is the part that stops people

Both routes are free and both are, at time of writing, fiddlier than they should be. The community route wants a Python package manager on your PATH and a hand-edited JSON config file with a port number that has to match in two applications. The official route installs through Blender's extension system, which is cleaner — when the repository index syncs, which for a lot of people it doesn't, because antivirus software and corporate networks block it and the resulting error message names nothing useful.

Neither of these is hard for a developer. Both of them are a wall for the 3D artist who has never opened a terminal, which is most of the audience that would benefit most.

What agent-driven 3D is actually good at — and what it isn't

This is the section I most wanted to write, because the demo videos are misleading in both directions. Here is where the value actually sits after months of daily use.

Genuinely excellent

• Lighting and camera. The single highest-value use. Three-point setups scaled to your subject, a real focal-length decision instead of the default 50mm, thirds composition instead of dead centre. Lighting is where beginners lose most of their quality, and it is almost entirely knowledge rather than craft — which is exactly the shape of problem an assistant is good at.
• Procedural and mathematical geometry. Anything definable by a rule. Arrays, tilings, parametric surfaces, geometry driven by an equation. The assistant writes the script, you adjust the parameters, and the geometry is exact rather than approximated — this is most of my own work.
• Scene hygiene. Unapplied scale, flipped normals, loose vertices, orphaned data, absurd polygon counts on objects nobody sees. Tedious, mechanical, easy to get wrong by hand, and it happily audits before it touches anything.
• Batch and repetitive operations. Rename two hundred objects by a rule, re-export a directory of files, apply a material variant across a collection, render a turntable at four angles. This is where the hours actually go, and it is pure win.
• Teaching you Blender. Under-appreciated. Ask why your render is noisy and you get a specific answer about your scene rather than a generic tutorial. The official Foundation server leans into exactly this.

Unreliable, and worth knowing before you rely on it

• Organic and character modelling. Describing a face in words is a bad interface for making a face, and no amount of model improvement fixes that. Sculpt it.
• Aesthetic judgement. It will produce a competent, average, entirely forgettable result unless you bring the specificity. It has no taste and no opinions worth borrowing — a point I have made at length about algorithmic art and which applies identically here.
• Long unsupervised chains. Twenty operations deep without checking, small errors compound into a scene that is subtly wrong everywhere. Work in short cycles, look at the viewport, and save first.
• Anything with real-world tolerances. It does not know your material thickness, your kerf, or your machine's minimum feature size. For work heading to a laser or a CNC, treat everything it produces as a proposal to be checked — I go through this in detail in the CNC fractal wall art case study.

Text-to-3D and image-to-3D in 2026

The other half of "3D design with AI" is the generators — models that output a mesh directly. They have improved sharply and they solve a real problem, as long as you are honest about which problem.

The current field splits into open-weight models you can run on your own GPU and hosted services you pay per generation. Trellis 2 (Microsoft) takes a single image and returns a textured GLB using a sparse structured latent representation; Hunyuan3D (Tencent) handles text, image and multi-view input, with recent versions generating in well under a minute with high-resolution PBR textures; TripoSR remains the light, fast option. Meshy, Tripo and Rodin are the main hosted services, trading control for convenience and adding conveniences like auto-rigging.

What they are good for

Volume and space-filling. Background props. Set dressing. Blockouts you will replace. Concept iteration where you want forty options and will keep one. Rough physical scans of an object you photographed. For all of that they are transformative, and a background shelf of clutter nobody will look at closely is now a two-minute job instead of a two-day one.

What they are still not good for

Anything a viewer will look at closely, anything that has to deform, and anything that has to be made.

My own position, for the record: no AI-generated imagery or geometry appears anywhere in my work. The forms come from mathematics, and AI builds the machinery that executes them. That is a choice about authorship rather than a claim that generators are useless — I am describing the landscape here, not endorsing every part of it.

The interesting move: generators as input, agents as editor

The combination is better than either alone. Generate a rough form, bring it into Blender, and have the agent do the unglamorous repair — decimate sensibly, fix normals, set real-world scale, generate a UV layout, build a proper material, clean the mesh so it exports. The generator supplies the shape; the agent supplies the craft that makes it usable. That is the pipeline most production work will settle into, and almost nobody is demoing it because it is not visually exciting.

Putting 3D on the web: three.js, WebGPU and splats

Making the model is half the job. The other half is that most people will meet your work on a phone, and a 3D file they have to download is a 3D file they will not open. Real-time 3D in the browser is the answer, and it is in an unusually good state right now.

three.js is still the answer

three.js is a free, open-source JavaScript library that renders 3D in the browser. It is the default for a reason: enormous ecosystem, exhaustive documentation, and — relevant here — a decade of public examples that every model has thoroughly absorbed. Asking an assistant for a three.js scene is one of the higher-success-rate requests you can make of one.

The practical loop is short. Export from Blender as glTF/GLB, the web's standard 3D format. Load it with three.js. It runs on a phone with no plugin and no install.

WebGPU is the current shift

WebGL is being succeeded by WebGPU, a modern graphics API with access to compute shaders. three.js supports both, and WebGPU-capable browsers now cover roughly 95% of users with automatic WebGL 2 fallback for the rest — so adopting it is no longer a bet. It pays off specifically on high draw-call counts, compute-heavy work like particle systems and physics, and complex post-processing; for a single spinning product model it changes nothing.

Alongside it, TSL (Three Shading Language) lets you author shaders in JavaScript and compiles to WGSL for WebGPU or GLSL for WebGL, so one shader runs on both paths. If you use React, React Three Fiber wraps three.js in components, and v9 added the async canvas initialisation WebGPU requires.

Gaussian splatting, for captured reality

For photorealistic captures of real places and objects, 3D Gaussian splatting has become the practical route — reconstructions from photographs that render in real time and look genuinely photographic in a way meshes struggle to. The delivery format has consolidated on .spz, originally from Niantic, which is up to 10× smaller than PLY while preserving spherical harmonics and is on a formal standards track as the Khronos KHR_gaussian_splatting glTF extension. On the web, Spark renders splats inside three.js and reads most of the common formats.

A working pipeline, end to end

Concretely, here is how the pieces connect on real work. This is the shape of my own practice, generalised.

1. Decide the rule or the form. Entirely yours. A piece of mathematics, a constraint, a reference, a question. Nothing downstream fixes a weak decision here.
2. Build the geometry. Agent-driven Blender for anything procedural or mathematical; sculpt or model by hand for anything organic; a generator for props and clutter you will not be looking at.
3. Light, frame and render. The strongest use of an assistant. Ask for a lighting setup and a camera with a stated intent, then adjust by eye.
4. Check it against reality. Wall thickness, scale, tolerances, minimum feature size, whether the machine can actually cut it. Never delegated — this is where confident wrong answers cost money.
5. Export twice. glTF/GLB for the web; STL, DXF or SVG in millimetres for fabrication.
6. Publish it as something people can turn. three.js viewer on the page, not a static render. My 4D polytope viewer and 3D fractal explorer are both this step, both free, and both built with exactly the workflow described above.

Notice which steps moved. Steps 2, 3 and 6 used to be most of the calendar time and are now a fraction of it. Steps 1 and 4 — deciding what should exist, and confirming it can be made — did not move at all, and now constitute nearly all of the work that matters.

Four things nobody tells you

The optimism above is real. These four are the things I would want said to me at the start.

1. It will confidently produce geometry that cannot be made. Zero-thickness walls, floating parts, features below your machine's resolution, interlocking pieces with no assembly order. It has no physical intuition because it has never held anything. Every fabrication-bound file gets checked by a human, every time.

2. Save before long sessions. An agent with Blender's Python API can run any command, including destructive ones. Blender's undo usually catches mistakes and File → Revert always will, but neither helps if you have not saved. Treat it exactly like handing your file to a fast, capable, occasionally careless assistant.

3. It will make you generic if you let it. Ask for "a cool 3D scene" and you get the average of everything, which is precisely what everyone else asking that question also gets. The interesting work comes from bringing something specific — a body of mathematics, a material constraint, a question nobody else is asking. When execution is cheap, specificity is the entire remaining differentiator.

4. Understanding still pays, and increasingly so. You can now produce work you do not understand, and it shows in the second iteration, when you need a deliberate change rather than a random one. You do not need to write Python. You do need to know what a modifier stack is, why your normals matter, and what your renderer is actually doing — because that is what turns "make it better" into an instruction the assistant can execute.

How to start this week

Nothing here needs a budget. The entire stack below is free.

1. Install Blender and drive it by conversation

Download Blender, install Claude Desktop, and connect one of the two open-source MCP servers. Then ask for something concrete and small — a still life, a product shot of an object you own, a lighting setup for a model you already have. An evening tells you whether the workflow suits you, and costs nothing to find out.

2. Ask it to explain rather than to build

The fastest way to get good at this is to use the assistant as a Blender tutor for a week before using it as a Blender operator. Ask why the render is noisy. Ask what the modifier order is doing. You will give much better instructions afterwards, and you will be able to tell when the answer is wrong.

3. Put one thing in a browser

Export a model as GLB and ask for a minimal three.js page that loads it with orbit controls. It is about thirty lines, it works on a phone, and it converts a file nobody opens into a thing people play with. This is the step most people skip and the one with the clearest payoff.

4. Build the small tool you have always wanted

The one that would save you twenty minutes a week and was never worth three months. Specify it precisely, have it built, use it, publish it. That is the open-source wave this article opened with — it is made of individual people doing exactly this, and it is more fun than it sounds.

More from this practice

• Algorithmic art with AI — the same division of labour applied to generative art, and why implementation stopped being the barrier
• Fractal wall art on a CNC — taking a digital design through to carved aspen, tolerances and all
• What is 4D art? — the four-dimensional geometry this pipeline was originally built to render