From a static mesh to a Unity-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 Unity.

archetypes starter skeletons animation clips Export to Unity

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/.webp). 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.

Give it a skeleton

Three ways in, 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.
Auto Rig — the fitter places the whole skeleton for you 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.
Guided Rig — you click a handful of landmarks first (muzzle, hips, a paw, an ear tip) and the fitter pins to them. Markers are placed on a side and front view at once, because a single side view hides every depth error.

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
`<mon>.unity.json`	clip metadata — loop flags and animation events
`<mon>.report.json`	the bake's own verification report
`unity/`	drop-in Editor scripts (see step 6)
`README.txt`	the short version of this page

Import into 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.

Core clips

loading…

Optional extras

loading…

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.

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. Read once per mon
`get_clip`	a clip's current authored state — only the overrides, because authoring replaces tracks and moves wholesale
`author`	write dials, keyframe tracks, the moves stack or a signature phrase onto a clip. `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
`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`	fit a starter skeleton headless — the editor's own Auto Rig, with the same confidence rating. Takes a minute or three
`guided_rig`	the same fit with your landmarks pinned, for when Auto Rig came back yellow or red

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.
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 the plan changes is where you may use them: the free tier is for private and non-commercial work, Indie covers commercial use under a revenue threshold, and Studio is unrestricted. 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.

Rig your first creature →