Genuinely impressed — one line, one usable GLB

#1
by kamjin - opened

TL;DR — It is genuinely good at what it claims: with your documented system prompt and sampling settings, a one-line request produced a valid GLB on the first headless export. My improvised "engineering-style" prompt produced a truncated page with my constraints silently ignored. Budget tokens generously, scale and repair the mesh yourself, and it slots neatly into an automated pipeline.

Context: what I'm building

A small multi-legged crawler — chassis and leg links 3D-printed at home, hobby servos, layout and hinge travel already fixed on drawings, target behaviour a slow reptile-style crawl gait. I'm building its MuJoCo model in parallel with the hardware, and everything in the pipeline has to be accepted by a script rather than by my eyes, because a physics simulator rarely errors — it returns a plausible wrong answer.

Why this interface is the right one

"An LLM that emits a self-contained Three.js page with a working GLB export" is a better interface than raw mesh output: the asset is reviewable in a browser before it ever reaches a DCC tool, and the failure mode is visible instead of silent.

How I use it — the part worth copying

It doesn't run as a chat box for me. It runs as a small specialist sub-agent inside a larger agent: a bigger model converts my engineering intent into the short English asset request this model was trained on, leaves your system prompt and sampling settings completely untouched, and then feeds whatever comes back through checks — export the GLB headlessly, measure the bounding box, list node names, test the mesh.

That is noticeably better than driving it directly. The model performs best when the caller adds nothing to its input format and instead validates the output; my single attempt at "improving" the prompt with an engineering-style spec cost me a whole failed run.

Two runs, same part

Attempt Prompt Result
Mine Long engineering spec (exact dimensions, hole axes, node name, "no decorative features"), max_tokens=20000 finish_reason=length: HTML truncated mid-function, never closed; constraints silently overridden, decorations added anyway
Documented Your system prompt verbatim + Create a low-poly robot leg link with hinge holes at both ends. finish_reason=stop, 290 s, valid GLB on the first export (75 kB, 26 named nodes, 1,398 faces)

The documented run is good-looking and has well-named nodes. It is not dimensionally faithful, and roughly half the nodes are bolts, washers and orange stripes — which is precisely the claimed domain.

page_model3

The page the documented prompt produced: 26 named nodes, working Export GLB, and yes, bolts.

Field notes for other users

  1. Use the documented system prompt and sampling, and keep requests short and in English. Don't improvise — the game-art prior wins every time.
  2. Budget generously and read the right field. It thinks a lot: ~10k tokens of thinking for a one-line request. The answer arrives in message.content; the thinking sits in message.reasoning_content. A client that reads only content concludes the model returned nothing.
  3. There are no units in the file. Measure the bounding box after loading — a ~60 mm part arrived as a ~3.6 m box and needed a ~0.016 scale factor to be believable.

model3_raw_az30

The exported mesh loaded at face value in MuJoCo, before rescaling.

  1. Physics meshes need repair. ExtrudeGeometry output arrives non-watertight with duplicated vertices. At MuJoCo's default density the part came out at 14.84 g raw, 11.97 g after merge_vertices() and 11.90 g as a convex hull, against 10.7 g theoretical. Use the hull or primitives for collision, and the original mesh as a visual-only geom.

model3_raw_az-45

Raw extrude output as loaded — the decorative bolts and washers are part of the collision mass.

  1. Headless export needs no clicking. Patch URL.createObjectURL before page scripts run, click the button, read the captured Blob — every page this model generated worked unchanged, including ones with no stable button IDs.

Three things that would make it easier to embed

For the planned agent-harness version:

  • Fail loudly — one fenced block, no prose, so truncation is obvious rather than silent.
  • Honour explicit constraints — units, node names and "no decoration" when a caller supplies them.
  • Expose window.exportGLB() plus a watertight-by-construction mode, so a pipeline can assert on the asset instead of guessing at it.

Thanks for releasing this openly — and the checkpoint improvements for detailed prompts over the first few days are already visible from my side.

first of all, thank you so much for taking the time to test the model so thoroughly and share such detailed feedback! i really appreciate it.

i've actually noticed many of the same limitations you pointed out, and i completely agree that these are important areas to improve. i genuinely believe we can address them with better training data and more targeted validation.

these models have been part of a series of experiments to understand how far we can push small models through carefully designed supervised training.

i started with the original 3d-coder, focused on general scene generation. then, based on feedback from the community, i developed glb-coder to generate reusable assets with glb export.

each experiment has helped me understand more about what these models can learn, where they struggle, and how to improve the training process.

and honestly, the results have made me increasingly confident that small models can achieve performance comparable to much larger models in certain specialized tasks, like operating cad software, 3d modeling tools or coding within specialized agentic harnesses.

that's actually the direction i'm exploring next.

the next 3d model won't be limited to one-shot generation. i'm planning to train it to operate as an agent, interact with tools, inspect its results and make iterative corrections.

your feedback about dimensions, mesh validation, object naming, export interfaces and engineering constraints is particularly valuable, and i'll definitely incorporate these points into the v2 training datasets.

thanks again for such a thoughtful evaluation! i really appreciate this kind of feedback, especially when it highlights limitations that can guide the next improvements.

i'm excited to see how far we can take these small models (:

Sign up or log in to comment