Naveen Gopalakrishna

Posted on Jul 10 • Originally published at naveenneog.github.io

Carving a Glowing 3D Army from Single Images: Hugging Face + Blender, driven by Copilot CLI Autopilot

#huggingface #blender #ai #3d

TL;DR — One gpt-image-2 concept image per piece → a free Hugging Face Space (tencent/Hunyuan3D-2) turns it into a raw 3D mesh → headless Blender projects the concept back on as texture → a web-ready GLB that glows in Three.js. No local GPU. All of it — the research, the scripts, the Hugging Face calls, the Blender runs, and this very post and its auto-publish to DEV — was orchestrated by GitHub Copilot CLI in autopilot mode.

I've been building Chaturanga — the ancient Indian "game of the four divisions," played with modern chess moves but authentic piece identities (Raja, Mantri, Gaja, Ashva, Ratha, Padati). The board above is the payoff. The hard part was the pieces: carved-ivory war figures with real silhouettes, in four themed armies, that spin in a WebGL inspector — built for free, on a laptop with no GPU, in a fully scriptable way.

Here's how that pipeline came together, including the parts that didn't work.

The pipeline at a glance

Four stages, each free and headless:

Concept — Azure gpt-image-2 renders a carved-ivory concept per piece (front 3/4, plain background).
Image → 3D — the concept goes to a Hugging Face Space that runs image-to-3D on donated GPU and returns a mesh.
Texture — Blender 5.1, headless on CPU, projects the concept image onto the mesh.
Ship — export a decimated, textured GLB and load it in Three.js with a little emissive glow.

Step 2 is the heart: image → 3D on a free Hugging Face Space

Instead of buying GPU time, I call tencent/Hunyuan3D-2 through its Gradio API. The Space runs the heavy diffusion-to-mesh step on free ZeroGPU; I just pull back a .glb:

from gradio_client import Client, handle_file

client = Client("tencent/Hunyuan3D-2", hf_token=HF_TOKEN)   # token optional; helps rate limits
result = client.predict(
    image=handle_file("refs/raja.jpg"),
    steps=30, guidance_scale=5.0, seed=1234,
    octree_resolution=256, check_box_rembg=True,
    num_chunks=8000, randomize_seed=False,
    api_name="/shape_generation",     # geometry only — fast; texture done later in Blender
)
# result -> a raw .glb mesh, generated on someone else's GPU, for free

No-signup fallback: for a path that needs zero accounts, I keep stabilityai/TripoSR (MIT) running locally on CPU — the only open image-to-3D model I found that's genuinely CPU-feasible on Windows.

Discovering Spaces from the terminal

Copilot CLI has the Hugging Face MCP server wired in, so I search the Hub without leaving my shell. Asking for image-to-3D Spaces returns the exact shortlist this project lives on: microsoft/TRELLIS.2 (⭐1.7k), tencent/Hunyuan3D-2 (⭐3.3k, what I use), TencentARC/InstantMesh (⭐1.6k).

From flat concept to spinning figure

The gpt-image-2 concept on the left, the Hugging Face + Blender result on the right:

And on the turntable (Raja · Ashva · Gaja):

Step 3 — Where Blender earns its keep (and where it fights back)

The Hugging Face mesh has a correct silhouette but a soft surface. The crisp carving detail lives in the concept image. So Blender's job is concept-texture projection: orient the mesh, frame an orthographic camera on its front, and set each vertex's UV to that camera's projection — so the concept becomes the surface.

blender -b --python tooling/blender/texture_project.py -- \
    raw/raja_hunyuan.glb refs/raja.jpg web/raja.glb preview.png
# headless CPU: orient -> project concept as texture -> decimate to ~28k faces -> export GLB

The honest limitations I hit:

Back faces get a mirrored projection. Single-camera projection is perfect head-on; the reverse is a mirror. For board pieces seen from above, an acceptable trade — but a trade.
Blender 4 → 5 broke my material scripts. Principled BSDF sockets were renamed: Subsurface Weight not Subsurface, Specular IOR Level not Specular. KeyError until I re-bound each one.
Eevee Next won't render headless on Windows. blender -b with new Eevee crashes with an access violation — it wants a GPU context a background process lacks. Cycles on CPU renders fine; every image here is Cycles-CPU.
No native build allowed. Marching cubes runs via PyMCubes, not a compiled extension, to stay laptop-reproducible.

The detour: I first tried Blender-only procedural modeling (skin modifier, geometry nodes, baked PBR). Fully scriptable, GPU-free… and it produced primitive blobs after hours. Great for finishing, wrong tool for creating organic figures. That failure is why the Hugging Face step exists.

The tools I tried — and where they hit a wall

Constraints on purpose: free, Windows, no GPU, scriptable.

Tool	Route	Verdict under my constraints
Hunyuan3D-2 (HF Space)	image→mesh, free ZeroGPU	✅ Winner — GPU-quality geometry, no local GPU
TripoSR (local)	image→mesh, CPU	✅ Fallback — only CPU-feasible local model
Meshy AI	REST API, 200 credits/mo	⚠️ Great, but ~6 textured pieces/mo, CC-BY
Tripo AI	REST API, 300 credits/mo	⚠️ Good, but 15 downloads/mo
Rodin (Hyper3D)	REST API, pay-on-export	⚠️ Best detail, but credits burn on download
InstantMesh / TRELLIS / Wonder3D	local	❌ Not CPU-feasible — CUDA-only

The pattern: hosted APIs are excellent but metered; the best local models need a GPU I don't have. The escape hatch is a community-hosted Hugging Face Space — the model runs on donated GPU and I pay nothing but a queue wait.

The meta-story: built in Copilot CLI autopilot mode

I didn't hand-write most of this. I drove GitHub Copilot CLI in autopilot mode — where the agent runs shell commands, scripts, and tools autonomously, multi-step, without stopping for approval each move:

a research sub-agent fanned out across 13 image-to-3D tools and returned a sourced comparison;
the agent wrote and ran the batch driver, called the Hunyuan3D-2 Space, and retried on ZeroGPU hiccups;
headless Blender runs for texture and the turntables above — it caught the Eevee-headless crash and switched to Cycles itself;
and this post — rendered GIFs, diagram, prose — plus the GitHub Actions workflow that auto-published it to DEV on push.

Results & what's next

A full four-world army — Kurukshetra, Ramayana, Kalinga, Devasura — each piece a real 3D figure with a themed material and emissive bloom.

Try it: the game is live at naveenneog.github.io/Chaturanga.

naveenneog / Chaturanga

Chaturanga — the ancient Indian four-army game in real 3D: a teaching chess AI with levels, an openings trainer, a piece inspector, a Warrior's Eye camera, and two themed worlds. Web + Android.

Chaturanga — the four-army game of dharma

Chaturanga is the ancient Indian ancestor of chess — the game of the four army divisions. This is a real-3D, mobile-first take on it: authentic Chaturanga piece identities (Raja, Mantri, Ratha, Gaja, Ashva, Padati) that move by modern chess rules, where every world teaches a moral through its pieces, and a teaching AI explains the game as you play.

▶ Play: https://naveenneog.github.io/Chaturanga/ · ⬇ Android APK: see Releases

Features

Play the Guru — an alpha-beta chess AI with 5 difficulty levels (Padati → Mantri) running in a Web Worker so it stays smooth on phones.
A coach — a Hint that names the best move and why, and a blunder review that gently flags mistakes and shows the stronger move.
Openings trainer — six classic openings (Italian, Ruy López, Sicilian, French Queen's Gambit, King's Indian) walked move-by-move with a narrated…

View on GitHub

Steal the pipeline: gpt-image-2 → tencent/Hunyuan3D-2 Space → Blender projection → GLB. Free, no GPU, every step a script. For game assets, product mockups, or avatars, a free Hugging Face Space is the cheat code — and Copilot CLI autopilot stitches it all together.

Built one day at a time. — @naveenneog

DEV Community