Character pipeline struggles — from sheet to rigid parts

Preface

The first idea was simple enough: the sheets already fix the shape, the colours and the weapon; the model is just their solid version; so throw the sheet at a strong enough generative model, have it produce a character that can walk into the game, shortest path. That path was taken and it crashed quickly. Not because the output was ugly — it was often quite nice — but the front and top views were not two projections of the same object, nobody could say where the grip was, and how many teeth the axe had or how wide the sword was all became "roughly that". Worst of all, there was no way to point at a semantically vague mesh and say "this part is wrong", because "this part" could not be named, and what cannot be named cannot be fixed.

So it stopped. Not because the tool was weak, but because the question was wrong: "give me a character that can go in the game" is not a question with a checkable answer. This entry records the pipeline that did work, and a few of the bigger crashes along the way.

The pipeline

What followed was splitting the big task into a chain of narrow steps, each judged pass or fail on its own.

The sheet is no longer a "reference"; it is a structural contract: front, side, back and top views on one page, the same body, the same clothes, the weapon in the same hand, the same number of attachment points. Before any paid call, a round of zero-cost checks — one subject, the same person in every view, all limbs present, sizes right, the top view a true orthographic top. If the top view disagrees, fix the sheet first; a generator does not carry the blame for a bad input.

Only one step costs money: asking Meshy for base geometry from those views — no texture, no remesh, one geometric hypothesis per candidate. Everything after that is local and deterministic: repair structure, correct proportions, split into parts, bind colours, assemble the rigid parts, import into Godot, verify in-engine, and finally look at it. The machine contract can pass in full and the result can still be sent back; those two gates are separate.

One thing worth mentioning because it sounds odd: the characters have no skeleton. Each logical part is a merged mesh on a shared voxel pitch, and motion is the movement and rotation of rigid parts. Voxel characters are blocky by nature, so rigid parts lose nothing visually; more importantly they are verifiable — a part is either in the right place or it is not, and "the skin weights feel a bit off" cannot be written into a validator.

The height ratios of the four characters were locked on day two: goblin 0.68, swordsman 1.00, minotaur 1.72, warlord 2.45. Those numbers outrank any picture — proportions in a generated image are compressed, pretty but not binding — and every later "isn't it too big" is measured against that ruler.

IN-ENGINE CAPTURE · IN-DEVELOPMENT BUILD

Goblin and minotaur

2026-07-19·Stop

The fidelity recovery for the goblin and the ordinary minotaur went on phase after phase, and the most embarrassing moment was orientation: a whole candidate chain had been derived to the end before anyone noticed the model faced the wrong way — the goblin's ear probes read zero, meaning it was not facing forward at all. Whole chain void. Since then the rule is the cheapest failure has to happen first: orientation, limb count and silhouette are checked before any colour or weapon work.

On 19 July that line was called off; the note says, in Chinese, that far too much time had gone into those two models. The versions were not perfect, but further iteration was returning less than it cost. Calling it off was followed by something more useful than more iteration: a table of every pitfall — what went wrong, what it wasted, what rule it becomes. Several are now mandatory: one candidate answers one hypothesis, never colour, topology, pose and weapon at once; sunk cost does not change the gate — "we already paid for it" is the most expensive sentence in the process; weapons never go through paid geometry, and are always built locally when a separate weapon sheet exists.

Vampire

The vampire is the second traveller, added later, and his look went back and forth the most: the cape was done in several versions — three plates, detached, fused, one held halfway and shelved, and finally a clean restart from source. When the cape finally settled, the last commit of the day read "restore readable vampire hands" — putting the hands back into a shape that reads as hands; the next day the lower half of the face was rebuilt.

As of today his play is complete and his interface exists in all three languages, but the formal look is still under review; a placeholder stands in the game. On the roster his status reads "visual under review", not "confirmed". That is not careful wording; it is the fact.

Evil Minotaur

2026-07-30·Four versions in a day

The Evil Minotaur's rework was compressed into a single day, 30 July. The third version was rejected: large patches of white voxels, did not read as an Evil Minotaur. The fourth was rejected on the roar frame: the anatomical left wrist read as disconnected, and the crescent of the weapon did not read enough like an axe. The fifth was rejected again: the wrist had to be rebuilt as a continuous wide-to-narrow taper, the axe bigger, sharper, more visibly serrated, recognisably tribal. The sixth was rederived from the frozen fourth — not stacked on the fifth, rejected things do not serve as a base — and finally passed.

One small aside before that review: an independent audit caught a seam between blade and haft; the fix was a forged socket so that blade and handle read as one piece from any angle. All three rejected versions remain in the repository, byte for byte.

The roster

The characters page shows five: Swordsman, Vampire, Goblin, Minotaur, Evil Minotaur. No silhouettes, no "coming soon". Not because there is nothing else in the repository, but because the rest has not been through the process, and until a look is properly settled there is no appetite for a dark shape hinting at what it might be. Going by thirty-odd days of this project, the first version is almost never the last.

Afterword

The most practical takeaway from this pipeline: generative models are very strong at finishing a well-defined problem and very weak at defining it for you. The first crash was not the tool's fault; it was handed a task nobody had thought through. Replace "give me a character that can go in the game" with "from these consistent orthographic views, produce base geometry that satisfies these constraints" and the success rate changes immediately. The other takeaway may matter more: leave room for failure — the rejected fourth version is still there, the misoriented chain is still in the record. A process that only lets successes remain does not record the real work; it records a story tidied up afterwards.