# Inverse Kinematics

In addition to the "forward kinematics" system described in the animation section, Trial also offers inverse kinematics solvers that can be blended into the existing animation sets.

An inverse kinematics system is composed of an "ik chain": a linked chain of joints that we want to make reach for a certain goal, while subject to a number of constraints. This chain as well as the strategy by which the kinematics are solved are handled by an `ik-solver`

, of which Trial currently the following:

`ccd-solver`

A simple solver that attempts to rotate joints to reach for the goal.`fabrik-solver`

A solver that attempts to move joints to reach for the goal. Usually leads to more believable-looking results for animals and should be preferred.

Every solver keeps a vector of the joint indices that are involved in the `ik-chain`

, and a reference to the `pose`

that contains the actual joint transforms. It also holds a vector of `ik-constraint`

instances in its `constraints`

, which are used to determine the limits to which the solver is allowed to push the transforms.

An `ik-constraint`

is a simple object which only needs to implement the `apply-constraint`

function, responsible for correcting the indicated joint to the acceptable range of motion. Currently the following constraint types are implemented:

`ball-socket-constraint`

Implements a constraint similar to a hip joint, where the joint can rotate around an`axis`

, but limited in its bending motion around that axis up to`limit`

.`hinge-constraint`

Implements a swivelling joint, where motion is constricted to follow around the`axis`

, optionally also constraining the allowed angles to be within`min-angle`

and`max-angle`

(both in radians).

An `ik-solver`

itself must only implement the `solve-for`

function, which should update the transforms in the `pose`

to aim for the `goal`

passed to the function. It is expected that each solver implements its strategy in an iterative manner, and returns true if the goal was reached, `NIL`

if not. The iteration can be controlled via the `iterations`

and `threshold`

fields.

To construct a solver instance in a convenient manner the `ik-from-skeleton`

function exists, which takes the name of a target `leaf-joint`

(the joint that will try to reach for the target), and either a `length`

or a `root-joint`

that defines the length of the chain. This function will construct the correct joint sequence from the skeleton's pose and create the requested solver.

In order to actually manage the `solver`

and the current `target`

we have a controlling `ik-system`

, which keeps track of the current blend `strength`

, its `active-p`

status, and a local `tf`

transform.

The system must only implement the `update`

function, which will update its internal `target`

vector, transform it into local space, and then use `solve-for`

to update the pose. Some handy subclasses exist as well:

`global-ik-system`

Simply aims the solver towards a`global-target`

vector at all times.`clip-ik-system`

Uses a`clip`

to animate the target (and possibly other properties) over time.`entity-target-ik-system`

Aims towards the location of another`entity`

with an`offset`

.

Each system still only controls *one* solver and thus one IK chain.

To bring this all together and to allow multiple chains to be used at once, the `ik-controller`

mixin class exists. It keeps a number of named `ik-systems`

, updates them all together, and blends their results into the final `pose`

. It also presents an easier interface to manage the systems with `add-ik-system`

, `remove-ik-system`

, and the `ik-system`

accessor.

The basic `animated-entity`

and `armature`

include an `ik-controller`

, meaning you can directly add IK chains onto those and control them that way.