Modifying primary and secondary targets

To pass new position/orientation targets, use


To pass new animation targets (retargeting) to segments, use


(x,y,z,w) are in local space! There is no need to reconfirm targets passed previously.

Example code for setting the primary targets:

mLeftHandTask->setTarget(positionLH.x,positionLH.y, positionLH.z); 
mRightHandTask->setTarget(positionRH.x, positionRH.y, positionRH.z);
mLeftFootTask->setTarget(positionLF.x, positionLF.y,positionLF.z);
mRightFootTask->setTarget(positionRF.x, positionRF.y, positionRF.z);
mHeadTask->setTarget(headOrientation.x, headOrientation.y, headOrientation.z, headOrientation.w);

Example code for orientation retargeting:

static void feedMocap()
  Quaternion quat;
    for(unsigned int i=0;igetSegmentByHandle(i)->setTargetOrientation(quat.x, quat.y, quat.z, quat.w);

All segments that are not set inactive with

 IKSegment::setActive(bool), or 
 setActiveDofs(bool x, bool y, bool z, bool rotation=true);

or frozen with passing zero weight to

 IKSegment::setWeight(int dof_id, Real weight) 

will potentially have an updated transform each time after calling


even if their animation target does not change. If the animation targets are the same and none of the primary targets have changed, the solver output should not change either.

If the primary position/orientation targets are likely to conflict with the underlying animation/motion capture motion, motion retargeting can be disabled for a number of segments on the limb concerned. This is done by traversing the chain segments and calling


For example, if a position task is set on the hand bone and is expected to conflict with underlying animation, retargeting might have to be disabled on the lower arm, upper arm and possibly shoulder. This will ensure that all position targets are satisfied accurately. The orientations of the respective segments will be decided by position targets, joint limits and other tasks solved over the full body. Vice versa, if the animation is always to be followed as close as possible, retargeting should be left enabled even if there could be a conflict with position targets.

Alternatively one can adjust the retargeting gain per segment or globally for the solver to determine the importance of the animation on the solve. By default all are set to 1.0. Lower value will allow higher influence of the tasks in respect to the retargeted animation.

To minimise the influence of the primary task on the rest of the skeleton, the active chain length (depth) can also be limited by calling

 IKTask::setLength(unsigned int number_of_links). 

Other tasks will still influence the solution for this task if their chains have common segments with this task, as will joint limits/retargeting targets, which are solved over the full body. This will ensure that the result still produces a smooth motion.

If animation targets are passed to all segments,

 IKTask::solveAnimation(bool value, int depth) 

can be called on any task to derive targets (global position or global orientation) from the animation pose and hence preserve some of its aspects. The second argument will enable/disable retargeting on the chain segments to the depth given.

The solution is initiated with

 IKSolver::solve(int max_iterations =30). 

Depending on the rig, you can vary the number of iterations. The default number of iterations will be sufficient to reach an optimum solution in retargeting. Other rigs might require higher number with typically 70-80 being sufficient for most cases. For marker solving you might need more iterations.