Automation is not new here. Long before AI was a conference topic I was writing MAXScript to solve production problems: CAD import cleanup, batch render submission, scene organisation. One number that has held up: CAD import preparation used to take 30–45 minutes per project; a MAXScript tool cut it to under five. Over dozens of projects a year, that is real time.
What changed, twice now, is the tooling around that work. First AI assistants made scripts far faster to write and debug. Then, this year, the assistant stopped needing me to write the script at all for many jobs. It drives 3ds Max itself, through a tool server I built for it.
Code generation. Describe a workflow in plain language, get a working first draft. It still needs review and a test on a real scene, but the hour that went into scaffolding is gone.
Error diagnosis. Pasting a failing script into an assistant surfaces the problem faster than reading it line by line: off-by-one errors, missing property checks, a loop that never ends.
Optimisation. One production script went from a ten-minute run to under three after an AI-suggested refactor.
The real shift: tools that were never worth writing are now worth writing. A script that took two days to build and debug takes hours. That moves the threshold. A step that happens on every project and that a person gets wrong on the sixtieth repetition is now worth automating even if it saves only minutes each time.
A few years of this produced the toolkit I use every day: a procedural building generator, a batch camera renderer, sun and camera utilities, a garden planner. About 20,000 lines of MAXScript and 16,000 of Python.
One scene, many cameras — Sasad Liget 6. The batch renderer keeps resolution, output path and render elements on each camera, so the sixtieth view renders like the first.
Writing a script and running it is still a loop with a person in the middle: describe, generate, paste, run, read the error, repeat. The next step was to remove the paste.
I built an MCP server for 3ds Max, a tool server that exposes the application to an AI assistant as a set of typed operations, currently about 115. Scene inspection and selection, object and modifier properties, material networks and texture maps, RailClone and Forest Pack styles, tyFlow events and operators, OSL shaders, state sets, viewport captures, batch renames, layer management, merges from other files. The assistant calls those tools the way it would call any API, and sees the result, including a screenshot of the viewport, before deciding what to do next.
The tool is deterministic; the assistant is not. Every operation the server exposes is plain MAXScript or Python underneath, doing one named thing. The assistant decides which operations to call and in what order, and I watch it, the way I would watch a new colleague on their first day. Nothing it does is invisible. The scene is right there.
Rendering is only half of a picture now. The working render that leaves 3ds Max goes into the AI finishing pipeline, and that system, too, is driven by tools rather than by hand: scripted ingest of render passes, structured prompts assembled from per-camera metadata, automated review. Deterministic tools, an assistant choosing among them, a person at the end, from the first CAD import to the delivered image.
Compare:
I am also, deliberately, building a second home. A Geometry Nodes add-on for Blender that behaves like RailClone and Forest Pack, and the same MCP approach for Blender, exist as working slices. Insurance against one vendor’s roadmap. 3ds Max with V-Ray is still the production seat today.
Understanding what problem you are actually solving. An assistant produces plausible scripts that do not always do what you intended. Testing against real project files, handling edge cases, knowing when a tool causes more problems than it solves: that is thirty years, not a prompt.
Production scripting is tied to specific workflows. The assistant does not know that my render manager needs output paths in one particular form, or that a client’s files always arrive with a naming convention that needs cleanup, until I tell it. Then it needs telling again next session. That knowledge lives in the tool definitions I write, which is one reason the MCP server exists.
And a script, or an agent, is the wrong answer more often than script authors admit. If a task will happen twice, do it twice.
MaxScript is still the right tool. It reaches virtually everything in the application, and that depth is what makes a tool server useful: every one of those 115 operations is a few lines of MAXScript with a typed contract on top. What changed is who writes the lines and who runs them.
The assistant gets things wrong. It has renamed the wrong objects, clobbered a live variable with a two-letter name, and cheerfully replaced a template placeholder with literal text. That is why every tool it can call is narrow, why the scene stays visible, and why nothing it does replaces the lint gate and smoke tests that guard the scripts real work depends on.
If your studio keeps losing the same hour to the same manual step in 3ds Max, that is work I do for others. Tell me where it hurts and I will say whether a script, an agent, or neither is the answer.