anyCreature: compiling a game-ready 3D creature from one text order

The order-to-GLB problem anyCreature is aimed at

Most pipelines that turn text into a 3D asset assume you have a mesh library, a downloaded art pack, or photogrammetry to fall back on. anyCreature assumes none of that. The README states that every creature is compiled from one JSON spec, with no mesh files and no downloaded art packs. The worked example shipped with the repository, example/wolf.json, is described as 2,211 vertices and 31 joints written out by the engine from plain text.

The intended user is not a 3D artist. It is someone with an agent that can run shell commands (the README names Claude Code, Cursor and a VM agent as examples) who wants a game-ready asset from a sentence like "make me a menacing mountain giant". The output is a skinned, animated, vertex-coloured, AO-baked GLB plus an offline showroom viewer. That last part matters: the deliverable is a file you can drop into an engine, not a render or a concept image.

The scope is deliberately narrow. There is no material authoring, no texture painting and no environment work. Colour arrives as per-vertex shading with a vertical gradient and grain, controlled by the shading key. If your project needs UV-mapped PBR textures, this is not the tool.

Five cards, two gates, and a blind reader

The pipeline is a set of stage cards in cards/ that the executing session reads in order. The flow diagram in the README runs: order, interview of at most two questions, silhouette brief, LOW design with free rein, Gate 1, Gate 2, MID with all parts, HIGH with colour and animations, then SHIP.

The design decision that distinguishes this from other generative asset tools is that neither gate is self-graded. The README is blunt about why: the session that designed the creature already knows what it drew, so it is the worst possible judge of whether the shape reads. Instead the four silhouette views go to a context-free reader agent that has never seen the order, and the only question it answers is "what is this?" Gate 1 is RECOGNISED, requiring all four views to land. Gate 2 is PUNCHIER: a new round may only make the silhouette bolder, and a round that tames the shape is reverted even if it is more correct.

Measurement is concrete. Each round renders four views, reduces them to masks, and computes width over height, mass thirds, torso depth contrast, leg fraction, silhouette turn count, zigzag alignment, and IoU against the previous round as a regression guard. The blind reader sees a 24px thumbnail, on the reasoning that if it does not read at 24px it does not read at all.

The doctrine behind this is stated in one paragraph: head-to-head experiments showed the model designs boldly when left free, and attempts to teach design upfront made output tamer. So the creation side gets only the order, the engine syntax and a short pit-map, while the inspection side is strict. Whether that split generalises beyond the creature domain is not something the README addresses.

Installing anyCreature and compiling the wolf example

The README gives a two-command quick start. The first runs setup.sh, which installs dependencies and performs a red/green ruler calibration. The README states that setup.sh must print calibrate OK before you trust anything else, because it builds one spec that has to pass and two that have to be blocked. That is a check that the measurement rulers separate good from bad on your machine, not just on the author's.

bash setup.sh

Expect the line calibrate OK. If the calibration builds all three specs the same way, the gates downstream are meaningless.

The second command compiles the shipped example spec into a GLB. The README calls this the whole interface of the engine, which has zero runtime dependencies.

node engine/cli.js example/wolf.json out/wolf.glb

The repository also ships setup.ps1, so Windows users are not left with only the bash path. The tooling badge states Node 18+ and Python 3.9+.

For the full text-to-creature session, you do not invoke a command yourself. You give your agent the prompt from the README, which tells it to read MANUAL.md, follow it exactly, use the cards in cards/ as the pipeline, run setup.sh first, and ask exactly one question, card 01's, and nothing else. The README explicitly warns against pre-bundling node_modules into a zip, because dependencies are per-machine. Image references are handled by asking the agent to extract a one-paragraph brief first, then proceed with the cards.

BLOCK, warn and info: what the engine refuses to build

The compiler emits three message registers, and they are not stylistic. BLOCK means the build stops because a hard floor was crossed. The README lists the examples: a faceted body, a part floating off its host, a mirrored twin distorted past 30%, an attack that never reaches. warn means it built but something is probably wrong. info is a number you asked for or an assumption the compiler made, such as which way an anchored fin ended up facing.

The reasoning given for treating floors as floors is that these are the failures that survive review and ship broken: a body rendering in hard facets, a horn hovering a centimetre off the skull, a right thigh collapsed to 40% depth by mirrored skinning. That is a real failure taxonomy rather than a style guide, and it is the part of the project most worth reading even if you never adopt the rest.

The practical consequence is that some designs are simply not expressible. If you want a fully faceted body, the README points to build: "rigid" as the only way to get one past the checker, and states it is for robots and crystals, not animals. If your creature concept depends on a shape the floors reject, you will be fighting the compiler rather than using it.

Tuning smooth_angle, shading and the triangle budget

The README lists the knobs that change output. smooth_angle is the crease threshold in degrees, default 50, settable at the spec root or per volume and part. Higher gives a smoother body, lower gives more facets. shading at the spec root controls the whole-body vertical colour ramp and grain through a gradient with top and bottom values, plus noise with size and amount. ao at the spec root turns the per-vertex ambient occlusion bake on or off.

The claims sheet at harness/claims.json is where quality is judged. The README describes it as the one claims sheet covering signature presence, 6:3:1 hierarchy, focal contrast, saturated area, rig and animations, and triangle budget, and notes that everything is judged at boss standard with tri_budget adjustable for cheap creatures. That last clause is the honest admission in the README: the defaults are tuned for hero assets, and a background creature will need the budget lowered or it will keep failing a check that was never meant for it.

embed_spec is the knob with the longest reach. When on, every GLB embeds its own authored spec at asset.extras.source_spec plus a parts manifest, so any agent can extract, edit, recompile, or graft parts between creatures using harness/graft.py. Setting it to false opts out. This is what makes the output editable rather than a dead binary, and it is the reason the JSON spec format is the real interface.

Where the text-first pipeline breaks down

The clearest limitation is stated by the README itself: do not invent your own workflow prompt. A prompt like "use this workspace to generate a character" skips every quality gate, and the README claims twenty iterations of that will not equal one pass through the cards. In other words, the engine will happily compile a spec for you, but the gates that make the result readable only run if the agent follows MANUAL.md and the cards. The quality is in the process, not in the CLI.

That makes anyCreature a poor fit for anyone who wants a single deterministic function call. There is no documented non-agent interface for the full session, and the README does not document rollback of a rejected round beyond the statement that a taming round is reverted. It also does not document what happens if the reader agent disagrees with itself across runs, or how many rounds a session is expected to take before shipping.

The image path is a workaround rather than a feature. The pipeline is text-first; an image has to be converted by the agent into a one-paragraph brief covering masses, signature parts, proportions and real-world size, and then the cards take over. If your reference is a detailed concept sheet with specific markings, that information is compressed into prose before it reaches the engine.

Finally, the repository has no retrieved releases and the README points to a CHANGELOG.md with version 1.3.1. The last push was on 2026-09-08, so the project is not archived and has been touched recently. That is all the repository metadata supports saying about its cadence.

anyCreature against a conventional generative 3D pipeline

The obvious alternative is a text-to-3D model that outputs a mesh directly, or a conventional asset pipeline where an artist models, rigs and animates in a DCC tool. The difference in approach is not the output format, since both can produce glTF 2.0. It is where the quality judgement lives.

A direct text-to-3D model hands you a mesh and leaves recognition to your eyes. anyCreature refuses to let the designing session grade itself, routes the silhouettes to a reader that has never seen the order, and rejects rounds that soften the shape. It also constrains the space hard through the BLOCK floors, which a general mesh model does not do. The trade is expressiveness for a narrower band of results that are known to read at thumbnail size.

Against a DCC pipeline, anyCreature trades control for throughput. An artist can author exactly the horn placement they want; anyCreature will block a horn that floats off the skull, and will revert an edit that makes the silhouette less bold even if it is anatomically better. The README makes that trade explicit by calling LOW's deliverable an exaggerated silhouette rather than an accurate one. If accuracy is the goal, this is the wrong tool.

Editorial conclusion

Adopt anyCreature if you already drive an agent that runs shell commands and you want a rigged, vertex-coloured GLB from a text brief, with the spec embedded so parts can be re-edited or grafted later. Do not adopt it if you need a web UI, a hosted service or a stable non-agent interface: the interface is MANUAL.md plus the cards, and the README warns that a generic workflow prompt skips every quality gate. Before trusting a build, run bash setup.sh and confirm it prints calibrate OK; then run node engine/cli.js example/wolf.json out/wolf.glb and check that the GLB carries asset.extras.source_spec. The licence is MIT, but the repository ships a THIRD-PARTY-NOTICES.md you should read before redistributing a compiled creature.

Frequently asked questions

Official sources

1. Ariescar/anyCreature on GitHub
2. Issues
3. License: MIT
4. Project website
5. README