From a static mesh to a game-ready creature
MonRig gives a creature mesh a skeleton and then generates a moveset for it — walk cycles, attacks, hits, deaths — from the anatomy you placed, not from a library of retargeted clips. This page is the whole loop, end to end, finishing inside your engine — a standard FBX for Unity, Unreal, Godot or three.js, with a drop-in importer for Unity. An AI coding agent can drive the same loop through MCP.
The loop
Six steps. Only steps 1–3 need you; 4–6 are the machine and your engine.
Bring a mesh
Drop an .fbx, .glb or .obj onto the Studio page,
optionally with a diffuse texture (.png/.jpg).
Pick the archetype that matches the creature's body plan — that choice decides how it
walks, not how it looks.
The mesh should be in a neutral, near-rest pose — arms out or relaxed, legs straight-ish, not mid-action. A mesh frozen mid-stride will be rigged in that stride.
Then tell MonRig which way the creature faces: the editor's Setup tab shows the model from six sides — click the picture where it looks at you, then the one where it stands upright. The model is rotated to match (every skeleton and every clip assumes that heading), and the bake uses the same orientation.
Give it a skeleton
Two ways in today, a third on the way, and they end at the same place — a skeleton you can still edit:
- Build skeleton — start from a ready-made layout for your archetype and drag the joints onto your creature.
- Guided Rig — you click a handful of landmarks first (muzzle, hips, a paw, an ear tip), the fitter pins to them and returns a green / yellow / red confidence rating. Yellow and red are a review signal, not a failure: open the rig and correct the joints it was unsure about. Markers are placed on a side and front view at once, because a single side view hides every depth error.
- Auto Rig — the model proposes the landmarks. A GPU worker draws two skeletons for your mesh with an AI model, keeps the better one and loads it into the guided markers: you drag what is off, place what it missed, and fit from it. 1 credit per creature, two free retries. Available while a GPU worker is online — the button says so when none is — and Guided Rig always works. Best on upright bipeds, apes and birds; four-legged chibis land a few centimetres off, and ears and tails stay yours to place. This is the only AI in MonRig: the model estimates marker positions, nothing else — the fit, the skinning and every animation are procedural. If you use it, a store that asks about AI use may want it disclosed (see the FAQ).
Everything downstream is driven by bone roles, never bone names. A bone tagged as a hind foot behaves like a hind foot whatever you call it, which is why the same engine animates a centipede and a giraffe.
Shape the moveset
You do not keyframe anything. Each clip is generated from the rig and steered by dials — stride length, foot lift, body lean, tail carriage, ear floppiness, wing beat, and so on. Anatomy filters the list, so a mon without wings is never shown wing dials.
Beyond the dials there are three optional layers, each compiling down into the one below it: tracks (raw keyframes on a dial or on root motion), moves (a friendly gesture stack — "rear up over frames 4–18, ease out"), and signature phrases (named beats like coil → burst → flourish → settle that expand into moves).
The browser preview and the final bake run the same math in two languages, and a test suite proves they agree across the whole example roster to within a fraction of a degree. What you scrub in the editor is what lands in the file.
Bake
Baking skins the mesh to the skeleton and renders every selected clip into real keyframes. It runs on our machines and takes a few minutes.
The bake also checks its own work and reports per clip: feet through the floor, a mon left hovering, mesh tearing at a seam, vertices left unweighted. Those verdicts come back into the gallery with the offending bone named, so a bad result tells you where to look instead of just looking wrong.
Download
One zip per mon:
| File | What it is |
|---|---|
<mon>.fbx | the skinned mesh plus every baked animation take — Unity, Unreal, Blender |
<mon>.glb | the same mesh and takes as a GLB — three.js (GLTFLoader), Godot, Blender; every take a named animation starting at t=0, the diffuse map embedded in the material |
<mon>.unity.json | Unity extras — clip metadata: loop flags and animation events (plain JSON, readable from any engine) |
<mon>.report.json | the bake's own verification report |
unity/ | Unity extras — drop-in Editor scripts (see step 6) |
README.txt | the short version of this page |
Import into your engine
Two standard files, one delivery. Unreal and Blender import the FBX;
three.js (GLTFLoader + AnimationMixer) and Godot load
the GLB — every take arrives as a named animation clip starting at t=0. The loop flags and
event frames sit in the .unity.json, which is plain JSON you can read from any
of them. Unity gets more than that — the extras below.
In Unity, this is the step most pipelines leave to you. Copy the unity/ folder
anywhere inside your project's Assets/ once, then drop in the FBX and its
.unity.json side by side.
Assets/
MonRig/unity/ ← the Editor scripts, once per project
Mons/
Fynix.fbx ← the bake
Fynix.unity.json ← must sit next to the FBX, same name
On import — and on every reimport — the included importer reads that JSON and:
- sets each take's loop flag from the bake (walk loops, an attack does not);
- writes the AnimationEvents onto each clip — impact frames, hitbox windows, VFX and charge cues — straight from the bake's own timing, so nothing is hand-typed;
- generates <mon>.controller, an AnimatorController next to the FBX: a Speed-driven locomotion blend tree whose thresholds are the bake's implied ground speeds, a trigger per one-shot clip, and a bool per non-locomotion loop.
Set the FBX's Rig type to Generic. These are creature skeletons,
not humanoid avatars — Unity's Humanoid retargeting expects a human bone map and will
mangle a six-legged rig.
The JSON is the source of truth: re-importing reapplies everything and overwrites the
generated controller, so a re-bake never needs manual re-wiring. To react to a hit in your
own code, add the included MonAnimEventRelay component and listen for the
event names it forwards.
Already working inside Unity? The same folder contains a bridge window (Window ▸ MonRig) that lists your mons and pulls a fresh bake into the project without a browser round-trip.
What you get
Every mon bakes the core set. Which of the extras appear depends on the parts you gave it — a creature with no wings gets no wing attack. A humanoid starts from its own set instead: the creature attacks (the second run, the two melee attacks, the magic and beam attacks) are switched off and the humanoid moves — guard, sword swing and stab, punch, kick, spin kick, roar, buff, the casts, talk, pick-up — are added as clips. Any clip's ◉ dot switches it in or out of the bake, and ⧉ on a clip tab duplicates it with every setting, so a second Walk or a harder Punch is one click and a name.
Core clips
Optional extras
Clip names are stable across re-bakes on purpose — an Animator state that
points at Walk keeps working after you re-rig.
Agent access (MCP)
MonRig ships an MCP server, so an AI coding agent — Claude Code, or any client that speaks the Model Context Protocol — can drive this loop itself: upload a mesh, fit a skeleton, author a clip, check numerically where a bone actually went, and then look at a rendered filmstrip of the result.
It is not a chat wrapper around the editor. The agent gets the same anatomy-filtered dial vocabulary the Dials tab shows you, and the same validator, which teaches instead of clamping — an out-of-range value comes back refused with its range, an unknown dial with the nearest real names, a root track that would break a loop with the reason. Renders come from the real editor, so what the agent verifies is what bakes.
Agent and browser are two doors into one room: what the agent authors is written to the same mon the editor reads, so reloading the editor shows its work, and you can carry on by hand from there. Baking and downloading stay where they are — the agent shapes the animation, you decide what gets baked.
The agent tools come with the Indie and Studio plans.
Set it up
Nothing to install and nothing to copy: point your agent at the studio and sign in with your browser, the way you would connect any other app.
claude mcp add --transport http monrig https://monrig.com/mcp
Then run /mcp in Claude Code and pick Authenticate. Your browser opens
on MonRig, you sign in if you are not already, and a page asks whether to let that app work
on your creatures. Allow it once and the agent is connected. Any MCP client that supports
remote servers does the same thing from its own connector screen.
A connected app acts as you: it sees your creatures only, and a fit or a render it starts is charged and rate-limited exactly as if you had clicked it. It never sees your password, and it cannot read files from your computer. Disconnect it any time under ⚙ Account settings → Connected apps, which cuts its access immediately.
Prefer a key? For a script, a build server, or a client with no
browser, create one under ⚙ Account settings → API keys and send it as a header —
claude mcp add --transport http monrig https://monrig.com/mcp --header
"Authorization: Bearer mrk_…". It is shown once, never expires, and is revoked from
the same page. A signed-in connection is the better default: its tokens are short-lived
and refresh themselves.
The tools
| Tool | What it does |
|---|---|
list_mons | your gallery plus the read-only example rigs — where the agent finds a mon id |
catalog | one mon's complete authoring vocabulary, anatomy-filtered: every dial with range, default and whether it can be keyframed, plus the presets — death style, gait style, posture, element, weapon, and the per-clip style dropdowns. Read once per mon |
clip_info | what one clip is on this mon, from the engine that plays it: its frame count, loop or one-shot, impact frames and emitter bone, every bone name grouped by part, and which feet lift when |
get_clip | a clip's current authored state — only the overrides, because authoring replaces tracks and moves wholesale |
author | write dials and presets, keyframe tracks, the moves stack, a signature phrase or the hold list (parts frozen at the stance) onto a clip. Every path is validated, mon-wide ones included; keys past the clip's end are flagged. dry validates without saving |
verify_motion | where a bone actually goes: per-frame travel decomposed into the mon's forward / lateral / vertical axes, plus a dominant-axis verdict (summary: just the extremes, their frames and the verdict) |
clips | rename or duplicate a clip, like the editor's ✎ and ⧉ — a standard clip keeps its name, its settings move to the new custom clip and the standard one is switched off |
orient | tell MonRig which way an uploaded model faces, before rigging — the Setup tab's Orientation step; check it with a shot of the bind pose |
listing | how the creature shows in the gallery: which clips visitors see and in what order, and up to three "Used in" links (a new link goes back to review) |
skin_cuts | the skinning lever: where each part's skin ends. Reports every cut part with the positions that isolate it, resolved on the mesh; a cut the mesh refuses is never saved. shot with cuts shows the regions and rings |
vertex_info | where the bake's vertices are: a vertex a bake names (a TEAR or floor line's v1380) — or the ones nearest a point — with its rest position on the shot grid and the bones that own it, plus the shot markers and the skin_fix point to aim at it |
skin_fix | the Skin tab's brush, headless: paint weight onto the bake's real skin (add / subtract / smooth strokes on the rest mesh, mirrored). What is stored is a sparse fix layer the preview and every later bake apply as the last word; without strokes it reports how many vertices each bone owns. shot with weights shows a bone's heat map or every bone's territory |
bake | rig + skin + every included clip through the real pipeline — the gallery's own Bake job (same price, same queue). Returns the job id; wait polls it; done = a digest of the verify verdicts and the skin's worst tear, and the preview turns mesh · exact |
shot | a real render of the preview — a filmstrip under one camera, or an onion-skin ghost. clip="bind" renders the unposed mesh |
upload_model | bring a new model in: tell the agent where the file is and it hands you one command that sends it straight to your gallery. Requires an explicit rights confirmation, which the agent must ask you for rather than assume |
auto_rig | the fully automatic fit, no markers — experimental: it does not land reliably, so prefer guided_rig. The editor's Auto Rig (marker proposals from a GPU worker) is not exposed through MCP yet. Takes a minute or three |
guided_rig | fit a starter skeleton headless with the agent's landmarks pinned — the rigging path today, with the same green / yellow / red confidence rating the editor shows. Takes a minute or three |
An agent never reads your files by itself. When you point it at a model,
upload_model answers with a single command that streams that one file to your
gallery — the model does not travel through the conversation, and nothing else on your disk
is reachable. Uploading in the studio by hand works exactly as before.
How it should work
Cheapest check first, so a wrong direction is caught before anything is rendered or baked:
- catalog once, then author — the validator costs nothing and refuses most mistakes outright;
- verify_motion for direction. Smooth and plausible is not the same as correct, and this is the project's own house speciality: a celebration that waves the arms backwards looks fine until you decompose the travel;
- shot for looks — clipping, mushiness, wrongness that no number names;
- you, for taste.
Two limits worth telling your agent about. verify_motion is
bone-relative and the mesh has volume, so “the fist reaches the chest bone” can
still mean the fist is buried in the chest — a contact claim needs a shot. And a shot's
corner badge says which weights drew it: mesh · exact is the truth,
mesh · approx can show deformation the real weights never had.
For rigging, the same honesty applies as in the browser: a yellow or red rating is a review
signal, not a failure, and guided markers must be placed on the bind render —
never on a posed clip, whose crouch can sit far from the mesh the fitter actually reads.
Requirements & limits
Stated plainly, because finding them out after a bake is worse:
- One creature per mesh. A scene containing a creature and its scenery will be rigged as one object.
- Near-rest pose. See step 1. A crouched or mid-action mesh rigs in that pose.
- Watertight-ish geometry helps. Fur cards, floating eyes and separate shells are fine; a mesh made of many disconnected islands will skin less predictably.
- Multiple heads are not supported yet. A two-headed creature gets one animated head.
- A re-exported delivery is not a valid input. If you feed a previously baked FBX back in, its armature carries a pose that is not its bind pose, and fitting will be wrong. Always upload the original mesh.
- The editor's preview skin is an approximation. While you set the animation dials the mesh deforms with a fast, browser-made skin so you can judge the motion instantly — it is worse than the real one. The bake computes the real weights on the server, and only that skin ships in the FBX. After a bake (or Rig only) the editor loads the real weights (the mesh button reads mesh · exact) and the Skin tab unlocks: pick a bone, paint on the mesh to give it more or less of the flesh under the brush (falloff, mirror L/R, smooth), and every later bake applies your fixes on top of its automatic skin — a rig tweak re-skins and puts them back.
- Skin weights are recomputed on every bake — unless you opt in to your own.
The editor's Bake tab offers a Skinning file download: the mesh and armature in
bind pose with the current weights and no animation, as a
.blend. Edit only the vertex-group weights in Blender (Weight Paint), upload it back with Use my weights, and every later bake honours them. Groups are matched to bones by name (unmatched groups are reported and ignored); Unity's 4-influence cap and weight normalisation still apply; an unpainted vertex follows its nearest bone. Editing the geometry breaks the per-vertex mapping, so a changed vertex count is refused — and the delivery FBX can never be the round-trip file (FBX splits vertices at UV seams). - Rig type Generic in Unity, as above.
Using the result
Your mesh stays yours, and so do the rig and animations generated from it. What you pay for changes is where you may use them: the free tier is for private and non-commercial work, and any purchase, a credit pack or a plan, covers commercial use with no revenue threshold. The one thing no plan permits is reselling the generated rigs as a rigging service or as an asset library that is essentially MonRig output.
The binding wording is in § 9 of the Terms; this paragraph is a summary, not the contract.
Frequently asked questions
What file formats does MonRig accept?
A single creature mesh as .fbx, .glb or .obj, optionally with a diffuse texture as .png or .jpg. MonRig rebuilds every upload from its geometry (vertices, faces, UVs, normals, material colours); skeletons, animations and anything else in the file are left out. The mesh should be in a neutral, near-rest pose; a mesh frozen mid-stride is rigged in that stride.
Do I need rigging or animation experience?
No. Every body plan has a one-click starter skeleton, and Guided Rig fits it to your mesh from a few landmarks you click, with a green / yellow / red confidence rating. Auto Rig proposes those landmarks for you — a GPU worker samples skeletons with an AI model and you check, nudge and fit — whenever a GPU worker is online; Guided Rig always works. You never keyframe: each clip is generated from the skeleton and steered by dials such as stride length, foot lift, body lean or tail carriage.
Is MonRig AI-generated? Do I have to disclose AI use in my game?
No generative AI makes your rig or your animations. The skeleton fit, the skinning and every clip are computed procedurally from the anatomy you place: the same creature and the same dials always produce the same motion. The one exception is Auto Rig, which uses an AI model to estimate where the guided markers go, and nothing else; you then check and move those markers, and the fit from them is procedural again. If you rig with Build skeleton or Guided Rig, no AI was involved in your creature. If you use Auto Rig, a store that asks about AI use (Steam, for example) may require you to disclose it as AI-assisted marker placement; the store's own rules decide. The editor says this before every Auto Rig run. An AI agent you connect through the MCP tools is your own tool: it sets the dials, and the motion is still computed procedurally.
Which game engines does it work with?
Any engine that reads FBX or glTF. Every bake delivers the same skinned mesh and every baked take twice: as a standard .fbx (Unity, Unreal, Blender) and as a .glb (three.js via GLTFLoader, Godot, Blender), every take a named animation. Unity additionally gets extras in the zip: a .unity.json with loop flags and animation events plus drop-in Editor scripts that generate the AnimatorController on import (set the FBX Rig type to Generic). The same loop flags and event frames sit in the .unity.json, which is plain JSON any engine can read.
What animations are generated?
A core set every creature gets — idle, walk, run, jump, hurt, defeated, two melee attacks, a magic and a beam attack, a second idle, victory, spawn, sleep and dodge — plus optional clips the anatomy allows: bites, claw and tail attacks, wing attacks, kicks, rolls, sword swings, casts, talking, picking something up, and more. A creature without wings is never offered a wing attack. A humanoid starts from its own set instead — guard, sword swing and stab, punch, kick, spin kick, roar, buff, casts, talk and pick-up — with the creature attacks switched off.
Does MonRig work with AI coding agents such as Claude Code?
Yes, MonRig is built for agents as much as for the browser. It ships an MCP server: one command connects it (claude mcp add --transport http monrig https://monrig.com/mcp), you sign in with your browser, and an agent such as Claude Code or any MCP client can upload a mesh, fit a skeleton, author a clip, check numerically where a bone went, render a filmstrip of the result and bake. It acts as you, sees only your creatures, and can be disconnected from your account settings at any time. The agent tools come with the Indie and Studio plans. The site also publishes llms.txt and llms-full.txt for AI assistants.
How much does it cost?
Rigging up to three creatures by hand and previewing their animations live in the editor is free. Baking (the finished, skinned FBX and GLB) and downloading come with any purchase, a credit pack or a plan, charged per creature: once a creature is unlocked, every re-bake and re-download of it is free. The current prices and packs are in the Pricing section on the home page. Every account also gets three free Auto Rig runs (one per model); after that a run costs 1 credit.
Who owns the result?
You. Your mesh stays yours, and so do the rig and the animations generated from it. What you pay for sets the commercial scope: the free tier is for private and non-commercial work, and any purchase, a credit pack or a plan, covers commercial use. The one thing no plan permits is reselling generated rigs as a rigging service or as an asset library that is essentially MonRig output.
Is my model visible to other people?
Not unless you publish it. A creature is reachable only by its owner until you switch it to public and it passes the operator's review; only then does it appear in the gallery and get a public page. You can unpublish or delete it at any time.
Where is MonRig hosted and what happens to my data?
On our own server in Germany. Uploaded models and bakes are stored to serve your account and are deleted on request or when a creature is deleted; the privacy policy (Datenschutz) lists the details and retention periods.