What is Kinematics

Kinematics is the math field. It's the study of how things move without worrying about forces (which would be dynamics). FK and IK are the two branches: forward kinematics and inverse kinematics. The names literally describe direction of computation.

FK: Forward Kinematics

You rotate joints from the top down. The end of the chain (a hand, a foot) ends up wherever those rotations put it.

For an arm:

1. Rotate the shoulder.

2. Rotate the elbow.

3. Rotate the wrist.

4. The hand is now in some position. You didn't pick where. It's the result.

You're controlling each joint directly. The endpoint is whatever you get.

Think of a robotic arm where you press buttons to spin each motor. You don't tell it "put the gripper at this point." You tell each motor how to turn. The gripper ends up wherever those motor turns put it.

IK: Inverse Kinematics

The opposite. You say where the endpoint should go. The system figures out what every joint needs to do to get it there. This one is pretty cool once it clicks!

For the same arm:

1. You set a target point in space (a doorknob, the ground, an enemy's chest).

2. You tell the system "put the hand here."

3. The system calculates: what shoulder rotation, elbow rotation, and wrist rotation make the hand land at that point?

4. The joints bend automatically.

You only control the endpoint. The joints are the result.

---

Why both exist and when to use each

The mental model is simple: FK plays the artist's vision, IK adapts to the world.

FK is how authored animations work. An animator hand-crafted a walk, a punch, a spell cast. That motion has personality, hip sway, shoulder counter-rotation, the way the head bobs slightly. Dozens of subtle joint motions that make the character feel alive. All of this is stored as bone rotations and played back as FK at runtime. Cheap, expressive, but locked to whatever the animator made.

IK is what you reach for when the world has something to say about the pose. The ground is bumpy. The doorknob is at a different height than expected. The enemy keeps moving. You can't pre-bake any of this because you don't know it ahead of time. IK runs at runtime, takes a target point, and bends the chain to reach it.

If you tried to use only IK, three things break:

1. You lose the authored personality. IK only knows where the endpoint should be. It has no idea how the hips should sway or how the shoulders should counter-rotate. You'd get correct foot positions and a lifeless body. A robotic shuffle.

2. IK has too many valid answers. The hand can reach the doorknob with the elbow up, down, or sideways. All technically solve the math. Without an FK pose to guide it, the IK picks weird answers. Elbows pointing the wrong way, knees bending sideways.

3. It's expensive. FK is one matrix multiply per joint. IK is a math problem to solve. Doing IK on every joint every frame for every character would melt the CPU. You can afford a few IK solves (feet, hands, head). You can't afford full-body IK.

If you tried to use only FK, you lose all world adaptation. The character's foot floats above the rock or clips through it. The hand misses the doorknob. The head looks straight ahead instead of tracking the player. The character feels disconnected from the scene.

So the rule:

• FK carries the authored motion. It's the base layer, always playing whatever animation is active.

• IK adjusts specific bones at runtime to match the world. Foot placement, hand attachment, head look-at, aim.

Most game characters use both, layered together. The walk animation plays as FK. Foot IK adjusts each foot to the ground beneath it. Head IK rotates the neck toward whatever the character is looking at. Hand IK keeps the gun in the right grip position. All on top of the same animation, all running at the same time.

A useful way to think about it: pure FK is a movie. The motion is fixed, the artist controls everything, the world is whatever was filmed. Pure IK is a puppet with strings. You pull the strings and the body follows mechanically. Real games are both at once: a movie playing, with strings on top to make the puppet react to a world that keeps changing.

The vocabulary you'll hear

These all show up around IK and FK. Quick definitions:

Skeleton (or rig). The hierarchy of joints that controls the character. Like a stick figure underneath the visible mesh.

Bone (or joint). One element of the skeleton. Each bone has a parent and rotates relative to it.

Skinning. Attaching the visible 3D mesh to the skeleton. Each vertex of the mesh is "weighted" to one or more bones. Move a bone, the attached vertices follow.

IK chain. The run of bones IK is solving. "Shoulder to hand" is a chain of 3 joints (shoulder, elbow, wrist). "Hip to foot" is a chain of 3 joints (hip, knee, ankle).

IK target. The point in space the chain's endpoint should reach. Usually a small invisible object you move around in code.

Pole target (or pole vector). A second control that tells the IK which way to bend. For an arm, the elbow could point in any direction while still putting the hand at the target. The pole target says "elbow should aim at this point." Without it, the elbow might point in weird directions.

Constraint. A rule that limits joint movement. "The knee can only bend forward, not backward." Constraints keep IK from producing impossible poses.

Two-bone IK. The simplest IK setup. Three joints, two bones. An arm. A leg. Has a clean math formula. Fast.

FABRIK / CCD. Iterative IK solvers for longer chains, like a tail with 10 bones. They loop and refine the solution. Slower but flexible.

Look-at constraint. A tiny IK that rotates one bone to point at a target. Used for head tracking and eye following.

Retargeting. Taking an animation made for one skeleton and applying it to a different one. Works well when both skeletons follow the humanoid pattern.

Procedural animation. Animation generated by code at runtime instead of pre-recorded. Heavy use of IK. Foot placement on terrain, head look-at, reaching for things.

---

Practical: what does this look like in code

Imagine you have a humanoid rigged character in three.js or Babylon.js or Godot. The character has a skeleton with named bones (Hips, Spine, LeftShoulder, LeftElbow, LeftWrist, etc).

FK example: play a pre-made walk animation.

const walkAnimation = loadAnimation("walk.glb")
character.play(walkAnimation)

The animation file contains rotations per bone per frame. The engine applies them in order down the skeleton. The character walks. Pure FK.

IK example: make the character look at the player.

const headBone = character.getBone("Head")
const target = player.position
headBone.lookAt(target)  // simple one-bone IK

Or stick the character's hand on a doorknob:

const handIK = createIKChain(character, "LeftShoulder", "LeftWrist")
handIK.target = doorknob.position
handIK.solve()  // calculates the new joint rotations

After this runs, the arm has bent to put the hand on the doorknob.

Layered example: play a walk animation AND keep feet on uneven ground.

character.play(walkAnimation)        // FK base motion
adjustFeetWithIK(character, terrain) // IK pass on top

The walk animation gives the legs their stepping motion. The IK pass overrides the foot positions to match the actual ground. The character's legs look natural even when the ground is bumpy.

This is the pattern most game characters use. FK animation as the base, IK as the layer that adapts to the world.

What you can build with this

• Realistic foot placement on stairs, slopes, and rocks.

• Hand attachment to objects, weapons, ladders.

• Procedural look-at so characters react to the world (turning their head when something moves).

• Aim offset for shooting in any direction without baking 360 directional animations.

• Ragdoll physics combined with animation. The body falls like a doll, but specific limbs can still be controlled.

• Climbing systems where each grip is an IK target.

• Driving and riding where hands grip a wheel and feet hit pedals.