Animating a character with AnimateHumanoid

AnimateHumanoid is the component that makes a humanoid character walk, run and idle without any animation clips. There is no Animator Controller, no recorded motion and nothing to bake — every movement is calculated fresh, every frame, from a set of settings you adjust in one Inspector. Add this single component to a character and it starts moving.

What it actually does

Those settings are stored as proportions of the character’s own body, rather than as fixed distances — a fraction of leg length, a fraction of hip width, and so on. Because of that, one saved set of settings produces a matching look on characters of very different sizes and proportions.

Under the hood, AnimateHumanoid is a thin wrapper around two other components it adds and hides automatically. One writes each frame’s pose onto the character’s bones, after Unity’s own Animator and any Animation Rigging setup have already run.

AnimateHumanoid is the only part of this system meant to be visible in the Inspector or referenced from your own scripts.

Requirements

Before adding the component, the character needs:

  • A model imported with its Rig set to Humanoid (not Generic), so it has a Humanoid Avatar. That Avatar is what lets the system find the character’s hips, spine, arms and legs by their standard humanoid roles, regardless of what the bones are actually named in that particular model. You do not need to add an Animator component: assigning the Avatar is enough, and there is no Animator Controller and no animation clip anywhere in this asset.
  • A uniform scale on the character (the same scale value on X, Y and Z). A character scaled differently on different axes cannot be measured correctly, and the system will refuse to animate it rather than produce a distorted result.

A skinned mesh is not required, but it is preferred: with one, the system reads the character’s true rest pose from the mesh itself. Without one it falls back to the Avatar’s T-pose and says so in the Inspector.

If the character already has an Animator component, it is used and left exactly as you set it. An enabled Animator with no Animator Controller assigned costs nothing measurable: at 60 characters on a 2026-08-24 measurement it was inside the frame-to-frame noise of the same scene with every Animator switched off.

An Animator Controller assigned to that Animator is a different matter, and the Inspector shows a warning at the top while the Animator is enabled and has a Controller assigned. AnimateHumanoid writes the character’s bones in LateUpdate, after the Animator has written them, so the pose the Controller produces is replaced on every bone this asset drives: the hips, spine, chest, upper chest, neck and head, both shoulder, upper arm, lower arm and hand chains, and both upper leg, lower leg, foot and toes chains. The bones this asset does not drive keep what the Controller gives them, so the fingers, the jaw and the eyes still follow the clip and the character shows two animation sources at the same time.

The frame time is real too: a 2026-08-24 measurement put a Controller playing a clip at 32.5 microseconds per character per frame, which roughly doubled the frame time of a 60-character scene.

Clear the Controller field, or switch the Animator off, unless something else in your project needs it. Switching the Animator off also stops any Unity Animation Rigging constraint on the character from having an effect, so clearing the Controller field is the better of the two if you use that package.

Adding it to a character

  1. Select the character’s root GameObject — the one carrying the Animator, or the one you assigned the Humanoid Avatar to.
  2. Add Component ▸ AnyMotion ▸ Animate Humanoid.
  3. Check the Avatar field at the top of the Inspector. It is filled in automatically from the model when the component is added; assign the character’s Humanoid Avatar there yourself if it is empty.
  4. The character is measured for you as the component is added, so there is no button to press. The character should immediately start animating in the Scene view if edit-mode preview is on (see Preview and Debug below), or in Play mode regardless.

RigMetrics stays visible in the Inspector, since it is shared by other tools in this asset, and carries a Measure button. You only need it to measure again after changing the character itself — a different Avatar, a different scale, a changed bone hierarchy.

If the automatic measurement fails, AnimateHumanoid shows a warning at the top of its Inspector and one message in the Console, both naming what went wrong — almost always that no Avatar was found, that the Avatar is not Humanoid, that the assigned Avatar belongs to a different model, or that the character’s scale is not uniform. Fix that and press Measure.

Where to put it

Put it on the character itself, on the same object as your movement script.

AnimateHumanoid writes the character’s bones, and the bones are children of that object, so it never writes the transform your movement script moves. Measured on 2026-08-23: with a movement script and AnimateHumanoid on one object, 120 frames of animation changed that object’s position by 0.0000 mm, its rotation by 0.0000 degrees and its scale by 0.0000, while the character’s hips moved.

Earlier versions of this page required a separate “visual root” object under the moving object. A character already built that way keeps working — the extra object changes nothing — so there is no need to rebuild one.

The menu command Window ▸ AnyMotion ▸ Setup Third Person Character Controller adds a CharacterController, a movement script, a camera rig and AnimateHumanoid to the selected character, which is the fastest way to get a working example if you are setting one up from scratch.

One hierarchy is refused: a character whose own root object is one of its bones, meaning the Avatar maps a humanoid bone to it. Rebuild the character so its root object holds no bone and the skeleton starts one object below it.

The Inspector, section by section

Each group of settings has its own Reset button. It returns that group to the Blank values, which are the least amount of motion those settings can produce — a starting point to raise values from, not the ordinary walk the Neutral preset gives you. Where a group shows a setting that belongs to another part of the character, such as the per-leg differences under Legs, that setting is reset with the group you see it in. A Reset also covers the settings its group holds that a different section shows: pressing Reset under Arms returns Hand Target Weight and the three reach limits, which you see under IK Targeting, along with the arm settings in front of you.

If hovering shows no tooltip, check whether the Editor is in Play mode. Unity hides tooltips throughout the Editor while the game is running unless Enable PlayMode Tooltips is turned on, on the General page of the Preferences window. This is a Unity preference and it is off by default; it applies to every component, not only to AnimateHumanoid. While it is off and the game is running, the Inspector shows a note with a button that opens that preferences page.

Presets

Neutral is an ordinary upright walk — the starting point the others change. Cartoon is exaggerated and bouncy, with long high steps. Horror is slow and hunched, with joints that snap rather than ease, and an uneven gait. Limp gives one leg a shorter, lower swing than the other.

Below the presets, Load JSON… and Save JSON… read and write a settings file. Reset All returns every setting to the Blank values — the least amount of motion the settings can produce, which is what each group’s own Reset button writes for that one group, described under The Inspector, section by section. It leaves scene references such as look-at or hand targets alone.

Style

A style set is a project asset that holds one named style per look you want to mix — tired, alert, wounded, whatever you name them. Each style is stored as a difference from this character’s own settings, which is why styles that change different parts of the body combine rather than overwriting each other, and why the preset buttons above still decide what the character is while these sliders mix named styles on top of it. This is not the same thing as the Body and Style section further down: that section holds the individual pelvis, torso, arm and head settings a style is a difference from, while this section mixes complete named styles across the whole character.

Assign a set in the Style Set field. If none is assigned yet, a Create Style Set… button creates the asset and assigns it in one step.

Each style gets its own weight slider, 0 to 1. The weight is stored on the character rather than on the style set, so two characters sharing one set can carry different mixes.

Beside each slider is a response graph showing how much of that style the character takes on against the weight you give it, from none at the left to all of it at the right. The dashed diagonal is what a response in exact proportion to the weight would look like. The dot shows where this character is right now, and is only drawn while the Scene view preview is running or the game is playing, since nothing moves a style’s position otherwise.

The Shape dropdown and the Onset and Snap sliders below the graph shape that response. They’re worth reading rather than guessing at: with Snap high, the response stays flat near the bottom, so a style at a low weight contributes almost nothing — at the slider’s maximum, nothing at all below a weight of about 0.19.

The Per-body-part response foldout lets one body part follow its own response instead of the one above — for example, letting the hips arrive fully at a style while the arms are still close to the character’s own settings.

Variation and Variation Seed, at the bottom of this section, control how much a character’s own body parts may randomly differ from the weights you set, so a crowd sharing one style set doesn’t move identically. Two characters with the same seed vary identically, and the variation survives a recompile or a scene reload.

A warning can appear below the sliders when two assigned styles move the same setting in opposite directions — mixing them then returns that setting towards the character’s own value rather than arriving at either style, and the warning names which settings that’s happening to.

Movement

Animation Weight controls how much of this system’s output reaches the character. 0 keeps the character in its unanimated rest pose, and 1 is full animation — useful for fading the system in or out.

The core timing settings control cadence: steps per second, or a move speed that the system converts into steps per second for you.

Simulated Speed (Edit Mode) is the speed the Scene view preview walks at, in metres per second. It applies outside Play mode only, and only while Derive Speed From Delta Position (under timing) is on: the character does not actually move in the Scene view, so there is no movement to measure and nothing writes Move Speed there. In Play mode, and whenever that checkbox is off, Move Speed is used instead and this field is grayed out. It is also grayed out together with Move Speed while Derive Cadence From Speed is off, because the step rate then comes from Cadence and neither speed changes the animation.

The line of text directly below it names the field the rate is currently coming from — one of the two speed fields, or Cadence while Derive Cadence From Speed is off. When the character is standing still, it also names the setting and the threshold that decided that — Min Walk Speed under idle, or Steps Per Second Threshold when Derive Cadence From Speed is off. Below that threshold the feet stay planted, exactly as they do in Play mode, so the walking settings have nothing to act on: editing Step Length or Step Height changes nothing on screen until the speed is raised past it.

The run blend settings describe what changes as speed rises into a run — duty factor, step length, lean, and an overall “how energetic” multiplier.

The idle settings describe how the character settles when it stops moving: how long the transition to standing still takes, and the small breathing and weight-shifting motion that keeps a standing character looking alive instead of frozen.

Steps and Ground

The Legs settings shape a single step: how far it reaches, how high it lifts, how far apart the feet are placed, and the angle the foot lands and leaves at. Left Leg and Right Leg, at the bottom of that group, are where one leg is made to move differently from the other — a shorter stride or a lower lift on one side. That is the general mechanism behind the Limp preset, and it is how you would build a lopsided or injured walk of your own.

The ground settings describe how a foot should react to uneven terrain. The Ground Probe fields tell it where to physically look for that terrain in your scene — which layers count as “ground,” and how far up and down to search.

Three of the ground settings — Sole Grounding, Sole Pelvis Share and Sole Solver Iterations — are not drawn in the Inspector as it ships. Sole Grounding is off by default, so a character moves the same whether the three controls are on screen or not. All three values are still stored on the character, a preset still carries them, and a script can still read and write them through Parameters.Ground.

Sole Grounding, off by default, puts the visible sole of each standing foot on the surface rather than near it. The foot target aims the ankle bone, and how far the sole sits below the ankle changes as the knee bends, so the sole ends up slightly inside the ground or above it even when the ankle is exactly where it was asked to be. Turning Sole Grounding on takes the average sole error, measured on three characters walking over flat ground, from 14.3 mm to 0.53 mm. It is off by default for two reasons: posing that character each frame costs 193 to 526 microseconds with it on against 51 to 74 microseconds with it off, which is roughly 3 to 9 times depending on the character, comparing each character against its own cost with the setting off; and it bends the standing knee further to hold the sole down.

Sole Solver Iterations, beside it, is how many poses the correction may try per foot each pass. The default never cuts the search short, so lowering it is what buys frame time: measured over three characters on flat ground, the default leaves an average sole error of 0.53 mm and costs 193 to 526 microseconds per character per frame, and the lowest setting leaves 2.96 mm and costs 161 to 188 microseconds. Most of that saving comes from the character whose feet need the most work; a character the correction already solves in two or three tries barely gets cheaper.

For Sole Grounding, the character must have been measured in the Editor while the game is not running, because that is when the foot shape is read and saved with the character; pressing Measure while the game runs measures everything else and leaves the foot shape as it was. The RigMetrics results then carry a Sole Geometry row that states whether the foot shape it needs was captured. The Kyle character included with Animate Yourself was measured before it shipped, so it already carries that foot shape. Sole Grounding also reaches those numbers only at Soft Reach Start 0.95 with Bone Stretch on: at Soft Reach Start 0.90 with Bone Stretch off, the leg runs out of reach before the foot arrives and about a third of the improvement is left. The shipped default is 0.94, which sits between those two measured values, 0.04 above 0.90 and 0.01 below 0.95. Sole Grounding was not measured at 0.94.

Sole Pelvis Share decides how much of each foot’s correction the hips take instead of the knee. Raising the hips lifts both of them, which stretches the other leg until its own foot leaves the ground, so a high value places the feet less accurately than the default does. The default 0.125 is the value the measurements above were taken at.

Further down, slope settings control how far the hips tilt to lean into a slope, and how much a step shortens — rather than lowering the hips — when the ground is steep.

Knees holds Pole Outward, which decides which way the knees point: positive gives a bow-legged walk, negative a knock-kneed one. There is no control for how far a knee bends, because the knee angle follows from where the foot is placed — raising Step Height under Legs is how you change how high the leg lifts, and shortening Step Length is how you straighten the leg.

Three settings that ask for a knee angle directly — Swing Knee Bend, Stance Knee Bend and each leg’s Knee Bend Multiplier — are not drawn in the Inspector as it ships, because nothing reads them: the knee angle comes from the foot position instead. The values are still stored on the character, a preset still carries them, and a script can still read and write them through Parameters.Knees and Parameters.Asymmetry.

The limb reach settings apply to all four limbs: the same two-bone solver drives the elbows and the knees, so a change here is visible in the arms as well as the legs.

Soft Reach Start is how close to straight a limb gets before it starts easing off, so the joint doesn’t snap straight the moment a target moves out of reach; in exchange, the hand or foot stops a little short of a distant target. The shipped default is 0.94.

The figures below were measured at Soft Reach Start 0.90 and have not been re-measured at the current default of 0.94; they still describe how the setting behaves and how far it can be pushed. At 0.90 and the default arm settings, the arms sit inside the softening band for the whole walk cycle, so the elbow bend you see is the softened one rather than the one you author: an authored Elbow Bend running 18 to 26 degrees across the cycle renders as 38.6 to 39.2 degrees, with an authored 18 degrees rendering as 38.6 degrees and an authored 26 degrees rendering as 39.2 degrees. The 8 degrees of authored Elbow Swing renders as 0.61 degrees, which is the difference between those two rendered figures. The hand settles at about 0.94 of full arm span instead of the 0.98 it is aimed at, roughly 20 mm on a 0.55 m arm. Because the arm stays inside the band on every frame, the rendered elbow bend stays within 38.6 to 39.2 degrees for the whole cycle, so the elbow reads as nearly rigid rather than swinging: almost none of the change is over time, even though the rendered angle differs from the authored one at every instant.

Raising Soft Reach Start brings the arms closer to the posture you authored, at the cost of a narrower softening band, so a knee or an elbow snaps straighter as a target passes out of reach — the joint pop this setting exists to remove — and it lowers the largest usable Max Bone Stretch. Lowering it softens the knees and elbows further and moves them further from the posture you authored.

Bone Stretch and Max Bone Stretch are not drawn in the Inspector as it ships either, on the same terms as the three sole controls above: Bone Stretch is off by default, both values are still stored on the character and carried by a preset, a script can still read and write them through Parameters.LimbReach.

Bone Stretch, off by default, lets the two segments grow slightly inside that same band so the target is reached after all, and Max Bone Stretch sets how much longer a segment may become at full extension, as a fraction of its own length — the default 0.042105 adds 4.2105 percent to the thigh and 4.2105 percent to the shin, and the same 4.2105 percent to the upper arm and the forearm. On the arms at Soft Reach Start 0.90 with Max Bone Stretch 0.05, that moves the hand from 0.944 to 0.969 of full span, 13.7 mm on a 0.55 m arm, and bends the elbow about 5 degrees further — from 38.6 degrees with Bone Stretch off to 44.0 degrees with it on — because the softening then works against the longer arm. Turning Bone Stretch on changes the character’s visible limb length, which suits stylised characters more than realistic ones. A high Soft Reach Start leaves a narrow band for the stretch to work in and lowers the largest stretch that is usable; if your Max Bone Stretch is above that, the Inspector states the smaller value that is actually in force under the slider, whenever the slider is on screen.

Body and Style

Pelvis settings cover how the hips rise and fall, sway side to side, surge forward and back, and turn and tip through the cycle. This is the single biggest contributor to a character’s overall silhouette while moving.

Torso covers lean, sideways bend and the three twists along the spine: Spine Twist turns the spine against the hips, Chest Twist turns the chest against the spine, and Shoulder Twist turns the shoulders against the chest. The hips’ own turn is Hips Twist, under Pelvis.

Arms covers how far the arms swing, how they’re held, elbow bend, and which way the elbows point. Left Arm and Right Arm, at the bottom of the group, are where one arm is made to swing or bend differently from the other — an arm carrying something, or an injured shoulder.

Head covers the head’s own bob, turn and tilt as the character walks, and how much it counter-turns to keep facing forward rather than swinging with the body. Counter Twist Weight answers all three of the turns underneath the head — Hips Twist, Spine Twist and Chest Twist — so 1 holds the head facing where the character is going however those three are set, and 0 lets the head turn with the body.

IK Targeting is where the character aims at objects you assign, for both the head and the hands. The look-at half turns the head, neck and chest towards the object in the Look At Target field below it: assign a Transform there — for example, whatever the character should be watching — and adjust how much of the turn each of the three body parts contributes, and how far and how fast they’re allowed to turn. The hand half decides how far a hand reaches towards the object in the Left Hand Target or Right Hand Target field instead of following the ordinary arm swing, with three limits on how far up, across and behind the body a hand may reach before the system gives up and lets the arm swing normally.

Variation

Irregularity mixes in a small amount of slow random drift and fast jitter on top of every movement, plus a seed value so a crowd of otherwise-identical characters doesn’t move in perfect unison.

Making one limb move differently from its opposite number is not here: those settings sit with the limb they change, as Left Leg and Right Leg under Steps and Ground, and Left Arm and Right Arm under Body and Style.

Preview and Debug

None of these affect a built game.

Preview In Edit Mode runs the animation continuously in the Scene view without pressing Play. The speed it runs at is Simulated Speed (Edit Mode), under Movement.

While preview is off, a Scrub Cycle slider lets you step through exactly one gait cycle by hand, to inspect a specific pose. It’s hidden while preview is running, because the preview would immediately overwrite anything the slider set.

Two buttons below that: Restart Cycle puts both feet back at the start of the cycle, and Reset Pose re-reads the character’s rest pose from its mesh and reattaches to its bones from scratch. Press it if a script recompile left the character looking wrong, and after you change the Avatar or replace the mesh.

Live Stats

Expand Live Stats to see what the animation is doing right now: current cadence and step length, whether each foot currently reads as on the ground or in the air, hip offset and rotation, and knee/thigh angles.

This is the fastest way to confirm a character controller is actually feeding in the speed you expect. It will also warn you if a foot is being asked to reach further than the character’s leg is physically long — that is a setting to change, not a bug. The warning names what to change, and it names it in the order that helps most: a Forward Bias that has been moved off 0 is the single biggest cause, then Step Length under Legs, then Duty Factor under Timing. Step Width is not worth reaching for — measured on the Kyle character, taking it from 2.5 all the way down to 1.0 takes 0.0235 off the reach ratio, against 0.3126 for returning Forward Bias to 0, which is about one thirteenth as much.

When a style set is assigned under Style, Live Stats also gains a Style Mix block: each style’s requested weight against the weight it has actually reached, and one bar per body part showing how much of that part comes from each style, with the remainder coming from the character’s own settings.

Controlling it from your own scripts

AnimateHumanoid exposes a small public surface for game code, all of it safe to read and write at runtime:

  • Weight — fade the animation in or out (0 to 1).
  • MoveSpeed / MoveDirection — write these from your movement code each frame if you have turned off automatic speed measurement, or if facing and travel direction can differ (for example, strafing). MoveDirection is in degrees relative to the way the character is facing: 0 is straight ahead, 90 is sideways to the right, 180 is walking backwards. These two say where the character is actually going, so a style never changes them: raising a style weight moves neither value away from the one in force, whether you wrote it yourself or automatic speed measurement supplied it.
  • LookAtTarget — assign or clear a Transform for the head/neck/chest to turn towards; safe to reassign every frame.
  • LeftHandTarget / RightHandTarget — assign a Transform for a hand to reach towards, for example a point on an object being carried.
  • Parameters, Pose, Phase — read or edit the full settings, the current computed pose, and the current position in the gait cycle (0 to 1, one cycle is two steps).
  • IsReady / IsBound — check whether the character has been measured and attached to its bones before relying on it.
  • FootMissedGround — an event raised when a foot’s downward ground probe finds nothing to stand on, for example when it swings out over a ledge. The animation already handles this on its own, by keeping the foot within a normal stride. This event exists for game code that wants to react to it separately, such as triggering a stumble or a ragdoll handoff. Its payload may still change before this ships.