Claude Code for 3D Artists: A Real Houdini Pipeline Setup

A developer writing as Alicia describes a terminal-only workflow for using Anthropic's Claude Code as a technical-director assistant in Houdini pipelines, running hython to generate and fix VEX and Python scripts while relying on a CLAUDE.md file to pin conventions like up-axis, units and naming. The account stresses that the agent cannot click nodes or deliver finished shots, that it still hallucinates node and parameter names, and that artists should get the no-MCP setup working before considering live session control.

AI-assisted disclosure: Codex assisted with research, code and writing. Measurements, failure cases and limitations are retained from the original article. Originally published by Alicia on 2026-10-14: Digital Garden by Alicia https://digitalgarden.si/blog/claude-code-for-3d/ . When I'm building digitalgarden.si https://digitalgarden.si/ , an interactive 3D garden https://digitalgarden.si/virtual-garden/ , the slow part is rarely sculpting one more flower. Claude Code is what I use on the Houdini side, with hython in the terminal: exports come out with the wrong up-axis, USD layer names don't match, and a batch of assets all need the same attribute changed. That's where Claude Code for 3D work earns its place. It reads and writes the scripts in your shot folder, runs hython in the terminal, reads the error, fixes the script, and runs it again. People in the English-speaking Claude Code crowd already make this point: if you treat it like a normal coding chatbot, you're wasting it. The difference comes from the system you build around it: persistent conventions, commands it can run, and output you can check.<sup 1</sup <sup 2</sup It won't click nodes in your viewport for you, and it won't deliver finished shots on its own. You still decide whether the shot looks good. The agent writes the repetitive glue code, gets it running, and fixes it until it passes a minimum check list.<sup 1</sup <sup 3</sup Compared with asking a question in a browser chat and pasting the answer into a Wrangle, there are three main differences. CLAUDE.md pins your conventions to every session. hou calls. Houdini users on Reddit are fairly practical about this. With docs for the right version, Claude often writes usable VEX and Python. It still hallucinates, so you need to be able to check node and parameter names. One user tried a Houdini MCP over a weekend and found that most of the time it was faster to ask, then do the work themselves. Their studio's security policy wouldn't allow it anyway.<sup 5</sup For most artists, I'd suggest this order: get the no-MCP, terminal-only setup working first. Then decide whether you want live session control at all. The agent can't move your mouse. What you can reliably hand off is text: VEX drafts, hou scripts, hython / hbatch / husk commands, and written node recipes you wire up yourself.<sup 3</sup In one line: you're the director and the reviewer. Claude Code is a TD assistant that edits scripts, runs commands, and reads logs. It is not an auto-clicker. Anthropic's docs describe CLAUDE.md as persistent project instructions the agent reads at the start of every session. Specific and short works better than vague lines like "write high-quality code." It's context, not a sandbox. If a path really must be off-limits, you still need permissions, hooks, or similar mechanisms.<sup 4</sup The Retrodeck guide makes a related point. Put your Blender or Houdini version, coordinate system Y-up or Z-up , units, asset naming, and entry points in the repo root. That's what stops basic failures like Maya-flavored code or assuming centimeters by default.<sup 1</sup Here's a TEMPLATE . Change the versions and paths for your own machine. It is not a log from a real run. CLAUDE.md — Houdini shot / asset pipeline TEMPLATE Stack pin versions; don't let the model guess - Houdini: 20.5.x or your actual version - Python: the hython that ships with that version - USD / Solaris: does this project require a layer naming prefix? - Downstream: Unreal / real-time preview if any Axis and units prevents wrong-axis exports - Scene up-axis: Y-up or Z-up — pick one and write it down - Units: meters or centimeters — pick one and write it down - Export to Unreal: state whether an extra rotation / scale convention applies - Never: assume Maya-style transforms by default; if unsure, ask first Naming - Shots: shots/SH / - Caches: cache/<asset /<version / - Suggested USD asset prim: /World/Assets/<Name - Never ship meaningless names like geo1 / null2 What the agent may / may not do - May: edit scripts under pipeline/ and shots/ /scripts/ ; run hython smoke tests on a single asset - May not: delete caches, touch secrets, submit to the farm without confirmation, edit a .hip that has no backup How to run - Smoke test: hython path/to/script.py - One asset first, then the batch - After every change: print axis check / bbox / whether all material slot names are present Minimum human checks - Do axis and scale look right at a glance? - Are any materials or attributes missing? - Was an error swallowed and reported as a fake success? Make each line something you can verify. "Print the world transform before export" beats "be careful with coordinates." The docs also suggest moving multi-step procedures into skills or path-specific rules, so CLAUDE.md doesn't grow into an encyclopedia.<sup 4</sup Without MCP, the terminal already covers most of the pipeline glue: hython script.py , or hython scene.hip , to get an environment with hbatch for HScript. When you need them, hrender , or husk on exported USD. Check the flags against the docs for your installed version. The loop looks like this. Treat it as an EXAMPLE workflow pattern , not a measured timing or a hardware spec from any machine. pipeline/ , reusing your existing naming functions where it can. hython export one.py , on one asset first. The Terminal Skills page has a useful reminder. Node type names and internal parameter names change between versions. Read them from the current session or the docs for your version. Don't let the model recite them from memory. Python is good for managing scenes and files; big per-point loops belong in VEX.<sup 3</sup This is a reusable workflow story pattern. It's made up but common. It is not a claim that this ran on a specific machine yesterday. print the rotation, scale, and bbox. One artist on X said they aren't very familiar with Houdini but used Claude Code to help run a sim and export Alembic caches for an ML Deformer workflow on the Unreal side.<sup 6</sup Same direction: scripts and exports. The agent isn't doing the art direction. Opening that export in Unreal is a different check. The Houdini to Unreal USD test https://digitalgarden.si/blog/houdini-unreal-usd/ measures a composed stage and a baked HDA, including units, materials and instance counts. The simulation cook is separate again. A Houdini ML volume upres https://digitalgarden.si/blog/houdini-ml-volume-upres-pyro/ log starts from a small Pyro cache, compares pretrained 2× and 3× density, and only then runs a short training pass. In Claude Code, MCP is a channel for external tools. Once a server is connected, the agent can call whatever that server exposes. Configuration has scopes such as local, project, and user, and you can check status with /mcp .<sup 7</sup There are already several open-source projects that connect Houdini to MCP, covering things like creating nodes, changing parameters, running Python or HScript, and even grabbing viewport screenshots. Creators on X have shown Claude Code + MCP + Houdini experiments such as camera-path work.<sup 8</sup <sup 9</sup I am not vouching for the security or production readiness of any third-party MCP server. Their architectures differ local sockets, RPyC, a built-in web server, and so on , and the permission surface is usually large. If it can execute code, it can change your scene. The Reddit thread also has first-hand reports of "slow" and "my company won't allow it."<sup 5</sup Before you connect one, use this table to check the impulse: | Can go to the agent still confirm verbally | You watch it in the UI / by hand | |---|---| | Read-only queries of nodes, warnings, error messages | Long sims, large cooks, overnight caches | | Editing the script repo and hython smoke tests | Overwriting a production .hip with no backup | | VEX drafts that you paste into the Wrangle yourself | Render farm submissions, anything that creates a bill | | A skill that explains how to write hou / command-line calls | Any secrets, credentials, cloud storage, or farm accounts | The skill route packages Houdini command-line and VEX conventions as instructions the agent can read. That's more controllable than remote-controlling the whole desktop, because it mainly changes how the agent writes text. It doesn't hand over full-scene RPC by default. Which skill to install, and whether to trust it, is still on you: check where the files come from. This article doesn't rank vendors.<sup 3</sup Pick work that is tedious, repetitive, clearly specified, and easy to catch when it goes wrong. The Retrodeck guide calls this pipeline plumbing, as opposed to "modeling for you."<sup 1</sup High return: hython smoke-test scripts, instead of sending the whole shot to the farm on day one Low return or high risk: Rule of thumb: VEX handles per-element work. Python and hou build networks and manage files. You look at the result.<sup 3</sup scripts/ , and clearly marked temp output. Production caches and publish folders need a human to confirm. import hou take a license. For long-running services, release it the way the docs allow. .hip / .hda files: Short version: generation belongs to generation tools; glue belongs to the scripting agent. The garden itself for example, this interactive 3D garden https://digitalgarden.si/virtual-garden/ makes a good practice ground. Take one plant or prop all the way through script, hython , and opening the result to look at it. The OpenUSD in Three.js https://digitalgarden.si/blog/openusd-threejs-usd-web-viewer/ note is that kind of check: a headless hython Solaris export, then the browser load. The OpenUSD beginner stage https://digitalgarden.si/blog/openusd-pipeline-beginners/ is the smaller file exercise underneath it: references, a payload and a season variant. Then think about batching a full set of seasonal assets. For work in progress, follow @EmberAtelier on X https://x.com/EmberAtelier . A browser chat gives you a snippet. Claude Code edits, runs, and reads errors against your actual folder, and CLAUDE.md remembers your team's axis and naming. The more real context it has, the more useful it gets.<sup 1</sup <sup 4</sup Anything you can write as Python or hou and run with hython , hbatch , or husk : exports, checks, batch renames, smoke-test render scripts, reading cook errors and fixing them. Clicking in the viewport, tuning parameters by feel, and final artistic judgment are still yours. That's the honest scope of a Claude Code Houdini setup.<sup 3</sup Pin the up-axis and units in CLAUDE.md . Print transforms at the end of export scripts. Compare a single asset downstream first. Explicitly forbid "assume Maya." Read node and parameter names from the session for your version.<sup 1</sup <sup 3</sup Axis and scale. Whether materials and key attributes survived. Whether a file reports a successful exit code but is empty. And open the result and look at it. Assembling a scene without looking at it is a common way agents fail.<sup 12</sup Read the original article, supporting data and updates https://digitalgarden.si/blog/claude-code-for-3d/ . Retrodeck, Claude Code for 3D Artists: A Real Pipeline Setup — https://retrodeck.ai/guides/every-3d-artist-should-be-using-claude-code-my-setup https://retrodeck.ai/guides/every-3d-artist-should-be-using-claude-code-my-setup ↩ X @Origin AI 01 CLAUDE.md as a system workflow — https://x.com/Origin AI 01/status/2101541975392657563 https://x.com/Origin AI 01/status/2101541975392657563 ↩ Terminal Skills, SideFX Houdini Skill for Claude Code & AI Agents — https://terminalskills.io/skills/houdini https://terminalskills.io/skills/houdini ↩ Anthropic, How Claude remembers your project CLAUDE.md — https://code.claude.com/docs/en/claude-md https://code.claude.com/docs/en/claude-md ↩ Reddit r/Houdini, Do you use LLMs for Houdini problems? — https://www.reddit.com/r/Houdini/comments/1l7kkss/do you use llms for houdini problems/ https://www.reddit.com/r/Houdini/comments/1l7kkss/do you use llms for houdini problems/ ↩ X @melnukoff — https://x.com/melnukoff/status/2102733870219366851 https://x.com/melnukoff/status/2102733870219366851 ↩ Anthropic, Connect to MCP servers — https://code.claude.com/docs/en/mcp-quickstart https://code.claude.com/docs/en/mcp-quickstart ↩ X @JADM823 — https://x.com/JADM823/status/2108594805039079637 https://x.com/JADM823/status/2108594805039079637 ↩ Community Houdini MCP projects listed only to show they exist; not a security endorsement : https://github.com/atayilgun/Houdini-claudecode-mcp https://github.com/atayilgun/Houdini-claudecode-mcp , https://github.com/OtakuSquirrel/houdini-mcp https://github.com/OtakuSquirrel/houdini-mcp , https://github.com/healkeiser/fxhoudinimcp https://github.com/healkeiser/fxhoudinimcp ↩ YouTube, Claude Code + Blender MCP — https://www.youtube.com/watch?v=Bdelqytx9oI https://www.youtube.com/watch?v=Bdelqytx9oI ↩ YouTube, Claude + 3D Model MCP — https://www.youtube.com/watch?v=g XF5l1ighc https://www.youtube.com/watch?v=g XF5l1ighc ↩ X @iamrexei — https://x.com/iamrexei/status/2100496481899712802 https://x.com/iamrexei/status/2100496481899712802 ↩