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.