Field note 02

A Codex, Blender, and Three.js Asset Loop

A small web game shows a useful way to move from code-shaped placeholder art to editable Blender assets without stopping development.

By Codex Rules EditorialJuly 13, 20266 minute read

Placeholder art has an awkward reputation. It is essential for proving scale, movement, collisions, and camera behavior, but it also has a habit of surviving much longer than anyone intended.

A Three.js game shared this week suggests a useful middle path. Build the first objects directly in code, then use Blender as the bridge to editable, exportable assets once the mechanics have settled.

What the builder reported

In a July 13 post, the developer of Dragon Sushi Hunter described using Codex to create primitive assets in Three.js. Once those shapes worked in the game, the developer connected Codex to Blender through Blender MCP and generated low-poly GLB replacements.

The game itself is available on itch.io as a playable HTML5 prototype. Its page identifies it as a 3D action shooter published on July 10. That makes it a useful finished example to inspect, even if the developer's exact production process is self-reported.

The open Blender MCP repository explains the capability behind the workflow. Its Blender add-on and MCP server can inspect and modify scenes, create objects and materials, capture viewport screenshots, integrate with asset services, and execute Python inside Blender.

That last ability is powerful. It is also the reason this kind of connection needs a tight trust boundary.

A repeatable asset loop

The workflow can be made systematic:

Block out the object with Three.js primitives.
Test its real gameplay scale, silhouette, pivot, and collision shape.
Write a short asset brief from what the prototype taught you.
Generate or assemble the Blender version.
Export to GLB or glTF with a known naming and compression policy.
Replace the placeholder behind a feature flag.
Compare silhouette, scale, draw calls, texture memory, and collision behavior.
Keep the primitive fallback until the new asset passes.

The asset brief should name the coordinate system, units, origin, forward direction, expected materials, texture limits, animation names, and collision strategy. A prompt like “make a low-poly dragon” may produce an attractive mesh and still create hours of integration work.

Security and provenance

Blender MCP can execute arbitrary Python in Blender. Only connect a server and repository you trust. Review the command that starts it, limit network and filesystem access where possible, and do not approve a script you cannot explain.

Asset provenance matters too. If an integration can pull models or textures from external services, record where each asset came from and what license applies. Generated does not automatically mean unencumbered, and downloaded does not automatically mean redistributable.

For a public game, keep a small manifest beside each shipped asset with source, license, author, generation method, and modification notes.

My take

The clever part of this loop is not asking an agent to become an art director. It is preserving momentum. Primitive art lets mechanics move quickly. Blender creates an editable checkpoint. GLB provides a portable handoff back to the game.

Each stage produces something a person can inspect. The code has dimensions. The Blender file has editable geometry. The exported model can be measured. The running game supplies the final truth.

That is a much stronger pipeline than trying to jump from a prose prompt directly to a production-ready asset.

A rule worth copying

Prototype assets in the fastest medium, but require an editable source file, a reproducible export, a license record, and an in-engine validation pass before shipping.