---

• Biped never used 3ds Max's general-purpose IK solvers (HD, HI, IK Limb, Spline IK). It used its own proprietary, quaternion-based per-limb solution controlled by three per-key parameters — IK Blend (0.0 FK ↔ 1.0 IK), a Body/Object coordinate-space flag, and Join To Previous IK Key — whose algorithmic ancestry traces to Michael Girard and Anthony Maciejewski's 1985 PODA pseudoinverse locomotion system.
• The "Set Planted / Sliding / Free Key" buttons are just presets that stamp those three parameters (Planted = IKBlend 1.0 + Object + Join-to-Prev; Sliding = IKBlend 1.0 + Object + Join-off; Free = IKBlend 0.0 + Body); footsteps are merely coordinate-space gizmos, and footstep and freeform animation use identical IK-constraint machinery under the hood.
• Character Studio evolved from a separately purchased plug-in (CS 1–4.2, spanning 3D Studio MAX 1 through 3ds max 6) to being bundled at no extra cost into the core product with 3ds Max 7 in 2004 (CS 4.3); the IK-relevant milestones were animatable foot/hand pivots and Layers (CS 3), and quaternion-vs-Euler function curves plus the Motion Mixer (CS 4).

3ds Max ships four general IK solvers — History Dependent (HD), History Independent (HI), IK Limb, and Spline IK — applied to arbitrary bone hierarchies through the Animation menu. Biped uses none of these. Biped is a self-contained procedural character system with its own controller, its own key-storage scheme, and its own kinematics engine. When you move a biped's foot, you are invoking Biped's internal solver — not an HI or IK Limb solver. This is why the Hierarchy-panel IK rollouts that configure HD/HI solvers are irrelevant to a biped, and why biped legs/arms don't expose swivel angles, goals, or end-effector objects the way an HI/IK-Limb chain does.

Biped's inverse-kinematics solution is defined by three values stored at each key of every arm and leg track:

• IK Blend (0.0–1.0): the FK↔IK interpolation weight.
• Body vs Object: the reference coordinate space of the IK path.
• Join To Prev IK Key: whether the key inherits the previous IK key's reference position (i.e., pins vs releases).

Footsteps are "simply gizmos that define a foot's coordinate system." Auto-generated footstep keys obey exactly the same planted/sliding/free constraint rules as hand-authored freeform keys, which is why Convert can round-trip between the two modes.

Architectural lineage. Biped and Physique were built for Kinetix by Unreal Pictures, Inc. Kinetix's own launch press release ("Kinetix Delivers Breakthrough Character Studio Plug-in for 3D Studio MAX") states: "Character Studio was developed for Kinetix by Unreal Pictures, Inc. Based in Palo Alto, Calif., Unreal Pictures is led by award-winning animation researchers Michael Girard, Susan Amkraut and John Chadwick. Girard and Amkraut headed development of the BIPED software component, while Chadwick directed the development of Physique." Character Studio was released in August 1996 (its Autumn-1996 sample scene, sk_baby.max, became the viral "Dancing Baby"). The same release describes BIPED as "a footstep-driven 3D character and animation system" and lists "Footstep-Driven Keyframe Animation" as a "feature [that] allows animators to use footsteps to create broad, global brush strokes for character movement."

The footstep-driven, IK-based locomotion model descends directly from Girard & Maciejewski's SIGGRAPH 1985 paper "Computational modeling for the computer animation of legged figures" (Computer Graphics 19(3):263–270; ACM DOI 10.1145/325334.325244; reprinted in Seminal Graphics, ACM Press, pp. 255–262, 1998), which introduced the PODA system. Per its abstract: "Modeling techniques for animating legged figures are described which are used in the PODA animation system. PODA utilizes pseudoinverse control in order to solve the problems associated with manipulating kinematically redundant limbs… [and] insures that the accelerations of a figure's body are synchronized with the timing of the forces applied by its legs." That is conceptually the same "center of mass driven by leg support periods plus IK on the feet" model Biped uses. Autodesk (via Discreet) acquired Unreal Pictures in 2004, coinciding with CS's folding into the Max 7 core.

How the solve works per key. The documentation describes the mechanism concretely:

• IK Blend = 0.0 (full FK): "The arm (or leg) is moved by interpolating the rotations of the joints at the keys. The hand (or foot) tends to move along sweeping circular arcs… the motion appears to be motivated by the apparent swinging at the joints." Joint rotations are interpolated (via the biped's TCB/quaternion controllers) and the extremity's position is whatever those rotations produce.
• IK Blend = 1.0 (full IK): "A spline path is computed through the keys of the hand, and the hand moves along that spline. Joint angles for the rest of the arm are computed to allow the hand to follow the spline." So at IK=1 the end-effector position is authoritative and the limb's joint angles are derived to reach it — a genuine inverse solve driven by a spline through the extremity keys.
• Intermediate values: a weighted blend of the two solutions, weighting FK more heavily as IK Blend → 0 and IK more heavily as → 1.

A crucial subtlety: IK Blend does not switch IK on/off the way a general rig's IK/FK switch does. Because you can always move a hand or foot and have the arm follow even at IK Blend = 0 (as a confused CGTalk poster observed), the parameter governs how the interpolation between keys is computed, not whether you can position the extremity. At IK=0 the between-key path is the FK arc; at IK=1 it's the straight/spline IK path in the chosen reference space.

Quaternion foundation. Biped was originally built on quaternion rotations with a TCB (Tension/Continuity/Bias) interpolation model rather than Bezier tangent handles, edited in Biped's own curve editor, the Animation Workbench. As one experienced user put it, "Quaternion handles IK blending much more efficiently and avoids gimbal." This is why biped limbs "won't ever gimbal on you," at the cost of requiring a key on every track and forbidding you from sliding one key past another in time (a limitation "as old as the biped itself"). CS 4 later added the option to switch a biped part to an Euler XYZ controller (with selectable axis order, default YXZ) to expose conventional Bezier tangent handles in the Curve Editor.

By default Biped solves IK in the Body coordinate system — the space of the biped's center of mass (COM). "This means that the IK path of the hand (or foot) translates and rotates with your character as it moves." A boxer's punch authored in Body space keeps its trajectory relative to the weaving, bobbing body.

The Object option changes the reference frame of the IK solve:

• IK Blend 1.0 + Body: inverse kinematics in COM space; produces "more straight-line motion between biped keys" relative to the body.
• IK Blend 1.0 + Object, no object specified: puts the limb fully into world space. This is the setting that pins a foot/hand in the world, and is explicitly "use[d] to control foot sliding in a freeform animation."
• IK Blend 1.0 + Object, with an IK object specified: puts the limb into that object's coordinate space, so the hand/foot follows the object (the "object-space object," or OSO — e.g., a hand linked to a sponge or a subway handle).

So "Body space" = follows the character's COM; "Object space" = follows the world or a named scene object. The distinction is precisely which frame the pinned reference position lives in.

This flag determines whether a key "should be part of the previous key (and have the same reference position as the previous key)." Behaviorally:

• On: the foot/hand maintains the reference position of the previous IK key — it stays planted/locked.
• Off: the extremity is free to move to a new position, producing a slide.

Two important consequences documented and reported by users:

1. Planted keys "respect" sliding keys. Because a planted key joins to the previous IK key, if you set a planted key after a sliding key and then move the sliding key, the planted key updates to follow the sliding key's new position (keeping the foot coincident). This is the mechanism behind the common "I set a planted key and it snapped back / to the wrong place" complaint.
2. Pivot rotation requires two consecutive keys on the same pivot. "When Join To Prev is turned on, as it is with all planted footstep keys, the foot pivots at the previous key's pivot point." So to rotate a foot about, say, the ball of the foot, you must set two consecutive planted keys both using the ball pivot; otherwise the foot rotates around the previous key's pivot instead of the one you see. The documentation's own troubleshooting tip: if a hand/foot pops back to a previous keyed position, "check to make sure that the Join To Prev IK Key is off, especially when you're using pivot points."

These three buttons on the Key Info rollout are convenience macros that stamp specific combinations of the three parameters:

Preset	IK Blend	Space	Join To Prev	Meaning
Set Planted Key	1.0	Object	On	Locks foot/hand in world (or to object); knee/elbow bends to accommodate COM moves
Set Sliding Key	1.0	Object	Off	IK-constrained but free to move — a slide; shown with a line through the footstep
Set Free Key	0.0	Body	Off	FK swing in body space; no IK constraint

Right-clicking each button opens a Defaults dialog to set the TCB (Tension/Continuity/Bias, each default 25) values used for subsequent keys of that type. The presets exist purely to speed up the alternating IK-constraint pattern a walk cycle requires.

Walk-cycle constraint pattern (freeform). For a leg: planted while the foot is on the ground (IK 1.0 / Object / Join-on), free while airborne (IK 0.0 / Body / Join-off), sliding if the foot slides on the ground (IK 1.0 / Object / Join-off). A single footstep's roll is authored as a sequence of planted keys with the pivot migrated heel → ball → toe: the docs walk through frames where the pivot is planted at the heel, then two consecutive ball-of-foot planted keys (needed to rotate about the ball), then a toe pivot, then a free key as the foot lifts. Because the constraint rules are identical in footstep and freeform modes, Convert (on the Biped rollout) can extract footsteps from freeform IK-blend values or bake footsteps to freeform.

IK constraints are "implemented with a pivot-based system." Each planted key carries a selected pivot (chosen via Select Pivot, which shows a diagram of candidate points on the hand/foot — toe tip, ball, heel, etc.). The pinned point in world/object space is the pivot, and the foot rotates about it. Animating the pivot from heel to ball to toe over successive planted keys is how Biped reproduces the foot's rolling contact through a step without the contact point sliding. Because Join-to-Prev makes a key use the previous key's pivot, pivot changes only take effect when two consecutive keys share the new pivot.

Footsteps are biped sub-objects (gizmos) whose position/orientation define where and in what coordinate frame a foot plants. Creating keys for footsteps "automatically sets IK and FK keys for the legs, as well as FK keys for the rest of the body," and adds arm-swing (and tail-swing) automatically. Within a footstep animation there are four foot states — move, touch, plant, lift — corresponding to the leg keys' IK constraints. A sliding footstep (displayed with a line through it) is simply a footstep interval whose keys have Join-to-Prev off, so "the foot can be placed anywhere, even though there is a footstep icon." Vertical/ballistic behavior during airborne intervals is computed by Biped Dynamics (gravity via the GravAccel value, controlled per-key by Dynamics Blend on the vertical COM track; Dynamics Blend = 1 uses GravAccel, 0 removes gravity and flattens the arc); character studio auto-inserts vertical keys at lift-off and touchdown to compute ballistic motion. Editing footstep timing/position causes Biped to adapt leg keys (retiming touch/plant/lift) while preserving upper-body keys, unless you set Adapt Locks.

Two mechanisms pin extremities:

• Anchors (Anchor Left/Right Arm/Foot on the Keyframing Tools rollout) are "legacy functions from the earliest versions" that temporarily fix a hand/foot's location and orientation while you set up object-space IK sequences — they ensure the limb keeps alignment until the second key establishing the object-space sequence is set. The docs note Set Planted Key is the modern alternative.
• Object-space attachment (IK 1.0 / Object / specify object) makes a hand/foot follow a scene object — the method for grabbing balls, handles, doors, etc.

When a biped has IK attachment (any keys with IK Blend > 0), you cannot reposition it with Move All Mode alone; you must link both the COM and the planted limb to a dummy (all links made at the same frame) and move the dummy. The docs warn that at some attached-object keys you may need to reset IK Blend to 0.0 or "the limb can get 'stuck' in a posture."

3ds Max	Year	Character Studio	IK-relevant notes
Max 3 / R3.1	1999	CS 2.2, then CS 3.0 (3.01–3.03)	CS 3 (Oct 2000) added animation Layers and a much-improved IK system with animatable pivot points on hands/feet — the feature that made per-step heel/ball/toe pivoting practical and greatly eased quadruped work.
Max 4	2000/01	CS 3.2 (3.4 update)	Extensible character-animation architecture folded closer to core; Max 4 widely reported as unstable, and Max 4-era CS biped animation was noted for glitches.
Max 5 / 5.1	2002	CS 4.0 (4.1 update)	Quaternion function curves (view/edit quaternion rotations as f-curves — marketed as "first of its kind"), the Motion Mixer (constraint-based NLA), new rounded skeleton, biped props, Head Target, forearm segmentation, two pelvis configs. CS 4 was still a separately-licensed product.
Max 6	2003	CS 4.2	Maintenance/refinement of the CS 4 feature set; still separately licensed.
Max 7	2004	CS 4.3 — bundled into base package	Character studio included at no extra cost for the first time. Per HandWiki, CS "is now included in fully functional form at no extra cost with more recent versions starting with 3DS Max 7 and including all versions numbered by year." This is the integration milestone.
Max 8	2005	Integrated (unversioned)	CAT introduced alongside as a separate advanced rigging toolset; biped itself stable/mature. Also the era of layer-collapse quirks with planted/sliding keys (see gotchas).
Max 9	2006	Integrated; 64-bit	First 64-bit build; biped IK behavior essentially unchanged from the mature CS 4.x engine.

On pricing: Computer Graphics World's CS 4 review listed a price of $995, and the Game Developer review of CS 4 similarly framed it as roughly $995 on top of a 3ds max seat; however, Mental Floss's 2018 Dancing Baby retrospective states Character Studio "sold for roughly $1500." Treat the exact figure as uncertain — the point that matters technically is that it was a paid, separately-licensed add-on until Max 7.

On the "since version 4" claim: Wikipedia's summary that CS was "integrated since version 4" is imprecise. The CS 4.x architecture entered Max's core around Max 4, but CS remained a separately purchased product through CS 4.2 / Max 6, and only became bundled at no cost with Max 7 (CS 4.3) in 2004. The underlying IK Blend / Body-Object / Join-to-Prev mechanism was already present in the CS 2/3 era and did not fundamentally change through Max 9; what changed around it were the curve-editing tools (quaternion f-curves, Euler option, Workbench), Layers, Motion Mixer/Motion Flow, pivot animation, and skeleton structure.

• Foot popping to the last key's IK. A recurring CGTalk complaint: after building a run with planted keys, going back to tweak earlier keys causes feet/joints to "pop to the IK that belongs to the last made key," with the red pivot marker appearing on keys that shouldn't have it. Root cause is the Join-to-Prev chaining and the "planted keys respect the previous IK key" behavior; the fix is disciplined management of which keys are planted/sliding/free and, per the docs, turning off Join-to-Prev where a pop is unwanted.
• Planted key snaps to wrong position. Because a planted key inherits the previous IK key's reference position, moving/re-planting after a sliding key can relocate the plant unexpectedly. Understanding that "planted keys stick to the last sliding key" is the resolution.
• Foot slipping when COM is moved too far. If the COM is moved farther than the leg's length, the foot slips off its planted point (still pointing at it) because "biped doesn't stretch/scale by default." Sometimes exploited deliberately.
• Layer-collapse corruption with planted/sliding keys. In Max 7-era workflows, collapsing layers when the base layer has planted/sliding keys "makes the animation go crazy"; the manual workaround was converting all sliding/planted keys to free keys first (users requested MAXScript to batch this).
• Planted → Free conversion creates wild interpolation. Converting planted keys to free keys via biped.setFreeKey produces "freaky interpolation curves" between the now-free keys even when start/end positions match — a known scripting-era gotcha.
• Keys can't cross in time. A biped key cannot be dragged past another in time (quaternion-controller limitation); switching the part to Euler control, or using a Layer, relaxes this for tangent-type preservation.
• On-the-spot cycles slide by design. Foot sliding in an in-place ("treadmill") walk cycle is expected; In Place Mode display and world-space planting are the tools to reason about it.
• Riding/attaching a biped to a moving object (e.g., a bike): rendering an animation can leave the biped "sitting in the air" unless the COM object is linked to the vehicle first, before animating the rest — a widely shared CGTalk fix.

1. Model Biped IK as three orthogonal per-key values, not an IK/FK switch. When debugging any pinning/sliding/popping issue, inspect IK Blend, Body/Object, and Join-to-Prev on the current and previous keys of that limb track. Most "mystery" behavior is the previous key's reference position propagating forward.
2. For clean planted contacts, always author two consecutive same-pivot planted keys at each pivot transition (heel→ball→toe), and verify Join-to-Prev is on across the stance and off at lift-off. Benchmark: if the foot rotates around a point other than the visible pivot, you're missing the second same-pivot key.
3. Use IK Blend = 1.0 / Object with no object for world pinning; specify an object only when the extremity must follow scene geometry. Reserve IK = 0 / Body for free swings. If a limb gets "stuck," reset IK Blend to 0 at the release key.
4. Prefer quaternion (default) for smooth, gimbal-free IK blending; switch a part to Euler only when you specifically need Bezier tangent control in the Curve Editor, and expect interpolation to change on conversion.
5. Before collapsing Layers or scripting key-type changes, convert planted/sliding to free (or snapshot the file). This avoids the documented layer-collapse and setFreeKey interpolation corruption.
6. When repositioning an IK-attached biped, link the COM (and the attached limb) to a dummy at a single frame and move the dummy — do not rely on Move All Mode. Threshold to change approach: if any key on the limb has IK Blend > 0, the dummy method is required.
7. Do not reach for Max's HD/HI/IK-Limb/Spline solvers to "fix" a biped — they don't apply. If you need general-rig IK/FK behavior a biped can't give, that's the historical argument for CAT (Max 8+) or a custom bones+HI rig, not for grafting a solver onto biped.

• Much of the precise internal math (exact blend function, spline construction through end-effector keys, pseudoinverse formulation) is not published by Autodesk; the FK-arc-vs-IK-spline description above is quoted verbatim from Autodesk documentation, and the pseudoinverse lineage is inferred from Girard & Maciejewski's PODA paper and Kinetix's "footstep-driven" language, rather than from confirmation that shipping Biped uses an identical solver.
• The Autodesk help text quoted is from modern (2015–2023) documentation, which is textually near-identical to the CS 3/4-era User Reference for these features; where a behavior is version-specific it is called out, but the help pages themselves do not always date the introduction of each line.
• The "3-DOF pelvis" sometimes cited for later bipeds could not be reconciled with current Autodesk SDK docs, which state the biped pelvis has two degrees of freedom and the clavicle two; this claim is flagged as unverified for the 1999–2006 window.
• Community reports (CGTalk/CGSociety, Polycount, kirupa) are practitioner accounts, not engineering documentation; they reliably describe behavior and workarounds but not the underlying code.
• The Max 4 ↔ CS 3.2 pairing, CS release dates, and the Max 7 bundling point are corroborated across BetaArchive preservation threads, InspirationTuts, Computer Graphics World, Game Developer and HandWiki, but exact point-release pairings (e.g., 3.4 vs 4.0 install options on the Max 5.1 media) come primarily from enthusiast preservation forums, and the exact retail price is disputed (see Section H).