01 The project

An AI-driven Procedural Forest Tool for Unity.

Brief → Houdini via MCP → Unity / URP · co-authored with Claude Code

A node-based generative tool that builds forests automatically, with the workflow itself composed end-to-end through an AI build interface. An artist moves a few sliders (density, slope, altitude, species), and a forest appears on terrain. Authored in Houdini, it loads straight into Unity so the look can be tuned live, without ever opening the 3D package underneath.

Project
AI-driven forest generator
Art-to-engine pipeline with custom wind shader
Context
Production-pattern build
Same architecture I shipped for DNEG VFX pipeline tools
Stack
Houdini 21 · Unity 6 · URP
Built via Claude Code over an MCP server
Walkthrough

The tool, running.

This maps directly onto node-based generative creative-production workflows.

02 My role

Sole builder, brief to shipped tool.

I designed and shipped every layer: the procedural node graph, the art-to-engine pipeline, the custom GPU-instanced wind shader, and the performance pass, composed through an AI build interface, with the judgment to know when its output was wrong.

03 The problem

The hard part isn't one good asset. It's the system that makes many correct ones.

A creative team needs many on-brand variations, fast, and they need to produce them without a specialist driving the tool every time. Hand-placing assets doesn't scale, and a workflow only a technical artist can run isn't really a workflow the team owns.

04 What I did

Built a node-based generative workflow, driven by controls, not code.

Expose

A few sliders, not a tool

Density, slope, altitude, species, and scale live as simple controls. The artist never opens Houdini.

Generate

Many elements from one graph

The graph scatters, masks, varies, and transforms, emitting per-tree data the shader reads downstream.

Drive

Data-driven wind, not constants

Each tree sways slightly differently from data baked in by the tool, through one GPU-instanced shader.

Reproduce

Same seed, same forest

Deterministic output, so a look can be tuned, saved as a preset, and rebuilt exactly later.

05 How it was deployed

An AI-driven pipeline, from build interface to live engine.

The workflow was composed through Claude Code talking to Houdini over an MCP server, then promoted to a reusable asset and loaded live into the engine the creative team actually works in.

The AI-driven process
01 · AI
Claude Code
Build interface that authors and edits the graph by intent.
02 · Bridge
MCP server
Translates instructions into live Houdini operations.
03 · Author
Houdini graph
Scatter, mask, vary, bake per-tree shader data.
04 · Package
.hda asset
Promoted to one reusable, parameter-driven node.
05 · Engine
Unity (URP)
Loads via Houdini Engine; controls in the Inspector, re-cooks live.
06 · Render
Wind shader
Reads per-tree data; one material, GPU-instanced.

Artists drive the sliders and never open Houdini. The specialist composes the workflow once, then rotates off and the team self-serves.

The Houdini network behind the forest tool
The actual Houdini network — a terrain heightfield, then scatter → mask → variety → per-tree shader attributes, packaged into one reusable .hda.
06 The result

One workflow, three forests, zero specialists needed.

< 2s
Re-cook when a control changes
3
Distinct presets from controls alone: pine, hillside, treeline
0
Houdini knowledge required to drive it
1
Shared material; shader cost measured with vs without

These are the mechanism behind a speedup, not a speedup claim.

The same pattern I shipped 20+ times at DNEG, where real artists, editors, and compositors drove it in production.

Shipped with CI/CD, QA, and docs across art, engineering, and TD · qualitative adoption, not a headline figure

Carlos M. Cruz
Creative Technologist · Technical Artist