How a prompt becomes an animated character

The four stages

Stage	What it produces	What it cannot see
1. Reference	A clean full-body image of the character	Whether a limb is hidden behind a cloak
2. Mesh	A textured, game-ready surface	That the surface is a person
3. Rig	A skeleton inside the mesh, and skin weights	Which bone is a thigh and which is an arm
4. Motion	Named clips driving that skeleton	That the body it came from was shaped differently

Why the rig is the hard part

A skeleton is a tree of joints placed inside the mesh, plus a weight for every vertex saying which joints move it. Get the weights wrong and an elbow tears. Get a joint's position wrong and the limb bends in the wrong place.

The subtle failure is naming. A rig predictor returns anonymous joints. Something has to decide which one is the pelvis, which pair are the legs, and which way is up. That decision is geometric, and it is easy to get backwards: arms hanging at rest point downward exactly like legs do.

Why motion transfer is harder still

Motion is recorded or generated on one body and has to play on another. The performer and your character have different limb lengths, different proportions, and different resting poses. You cannot copy joint positions, or a tall character's feet sink into the floor. You have to copy rotations, corrected for how each skeleton rests.

There is a trap inside that. A natural approach is to point each bone where the source pointed it. That reproduces direction perfectly, and silently discards rotation about the bone's own axis, because spinning a bone does not change where it points.

That lost component is not a detail. It is:

Turning. A turn in place is rotation about the body's vertical axis. The hips keep pointing at the spine the whole time.
Counter-rotation. The shoulders swinging against the hips in a walk is spine twist. Without it the upper body goes rigid and the walk reads as a sway.
Wrists. A hand has no next joint to point at, so a direction-only transfer has nothing to aim and leaves the hand frozen.

We found all three in our own output, and fixed the transfer to carry twist as well as direction. The service now measures every clip before it ships.

What gets checked

Two automatic checks run on a character, and neither needs a renderer:

Bone placement. Every named bone must sit where its name says on the mesh. A head at the waist stops the job before motion runs.
Clip shape. A standing humanoid stays far taller than it is wide. A clip that folds the character, or loses a third of its height, is reported rather than shipped.

You can run the same checks on any GLB you have, ours or not:

python tools/check_rigged_character.py YOUR_MODEL.glb

One command

All four stages run from a single request. The animation pack decides which clips you get.

assetyard generate model \
  --prompt "A marsh ranger in a neutral A-pose, full body head to feet, \
arms away from the torso, forearms and open hands visible, \
legs apart, both feet flat and fully visible" \
  --geometry-profile character \
  --animation-pack humanoid_standard \
  --out assets/ranger.glb

The prompt names every limb on purpose. The rig stage can only place a joint it can see, so a pose that hides a forearm produces a skeleton missing that bone. This is the single biggest thing you control.

The packs

Pack	Clips	What it covers
`humanoid_core`	5	The smallest set that makes a humanoid usable in a game: standing, walking and running.
`humanoid_standard`	15	The default set for a generated humanoid. It adds jumping, gestures and reactions to the core locomotion clips.
`humanoid_combat`	7	Melee reactions for an action game. Pair it with a locomotion pack.
`humanoid_traversal`	8	Moving through a world rather than across a flat floor: crouching, climbing, swimming and landing.
`humanoid_sword`	10	Armed melee for an action game: swings, a shield, and the reactions that sell a hit landing.

The result is one GLB with a named humanoid skeleton, skin weights, and named clips inside it. It loads in Three.js, Godot, Unity, or anything else that reads glTF, and your players never talk to us.

Combine packs

A combat, sword or traversal pack is a set of reactions, not a character: none of them carries a walk cycle. Repeat --animation-pack to pair one with locomotion, and the clips arrive in one file.

assetyard generate model   --prompt "A shieldmaiden in a neutral A-pose, full body head to feet"   --geometry-profile character   --animation-pack humanoid_core   --animation-pack humanoid_sword   --out assets/vale.glb

Packs overlap, and a glTF file cannot carry two clips with the same name. Where they overlap, the pack you name first keeps the clip. Name at most three packs in one request: every clip is generated, so the request grows with the count.

The player character in the 3D demo is built this way, and the page prints the clip names it finds in the file.

What this does not do yet

We would rather say so than have you find out after a generation.

Any body rigs. Only bipeds animate. The rig stage places and skins a skeleton on a dragon, a wolf or a biped with a tail, and you get that file. The animation packs are indexed by humanoid bone name, so a body that is not a biped arrives rigged and unanimated, and says so, rather than receiving a walk cycle bent onto the wrong joints. A humanoid monster animates normally.
A biped with a tail is not yet recognised as a biped. The bone namer looks for a pelvis carrying exactly two legs. A pelvis carrying two legs and a tail fails that test, so the character rigs and does not animate.
Extra limbs are not driven. Wings and tails are modelled and skinned, but the humanoid packs have no clips for them, so they follow the body rather than moving on their own.
Motion is generated per request. Two characters given the same pack get independently generated clips, so their walks differ slightly.

Inspect a rigged character ↗ Read the CLI guide