[Soc-2005-dev] Inverse Kinematics

[Brecht Van Lommel]

Hi Ton,

Ton Roosendaal wrote:
> Hi Brecht,
> 
> Thanks for the cool doc!
> http://wiki.blender.org/bin/view.pl/Blenderdev/SoCInverseKinematics
> 
> I might not have time for the IK data redesign in PoseChannel 'bones'  
> until I am back from Siggraph (august 6). But some rough ideas on it I  
> can share already;

Ok, no problem, I will also be away july 30 - august 6.

> - IK trees
> 
> Within the UI it should be simple to select and visualize... with  
> overlapping IK's being the main concern still. It's also unknown yet  
> how easy it is get a full automated tree (like an arm including the  
> fingers) in good control. What if you pull one finger, does the rest  
> move? Using weights?

Better to make the hand on IK target, and add a separate IK tree
under that, with the targets of the finges parented to the hand.
Otherwise you would have to move all fingers targets each time
you want to move the arm.

> My current idea is to stick to indicating single Chains in the UI, with  
> selecting the 'Root' and the 'Effector' bones. This Chain information  
> then is stored in the Root bPoseChannel. For each Chain, we then  
> introduce a Priority number, which will define the order of execution.  
> When the Pose is being "solved", I then can make sure that all Chains  
> in a Root Bone with same Priority are delivered together (without  
> duplicates) to the IK Solver, thus allowing to solve an entire Tree as  
> well.

Sounds like nice & simple solution.

> By setting different Priority values, an artist then can still use  
> multiple levels of IK on a single 'chain', this for the much used trick  
> to first 'IK' the upper arm (for orientation) and then do the full arm.

Yes, very important to keep this working.

> - The weird "IK to Parent" flag
> 
> My proposal would be to rename it to "Snap to Parent", as builtin  
> option to ensure Bones can not be dislocated by IK or Constraint or  
> Actions. With the new IK Chain format defining the root and effector  
> bones, the IK module then can also solve Bones with offsets to their  
> parent bones. Right?

Yes, the offset is called 'start' in the API.

> - DOF joints
> 
> We need to define the format how to express a "DOF". End-users would  
> prefer Euler here I guess.

I'm not convinced using Eulers would be a good idea, since they have
two problems for 3DOF and 2DOF XZ joints:
a) singularity at 90 degrees (gimbal lock)
b) don't define an intuitive motion range, since for example the Z range
      would not define how far can be rotated over the Z axis from the rest
      pose, but rather how far can be rotated after rotations over the other
      axes.

It would in my opinion be best to use a swing (XZ) + twist (Y) decomposition
for these cases. Swing is then an axis angle, and twist is a simple rotation
over the Y axis after the swing. The swing component then nicely defines
how far ca be rotated over the X and Z axes. It still has singularity at 180
degrees, but that's mostly beyond joint limits (and singularity simply cannot
be avoided when using 3 parameters).

The user interface would still have three X,Y an Z limits in degrees,
consistent between different DOF types. But they would just work
somewhat different from euler angles for joints with swing in them.

> BTW; by definition Bones are pointing in the  
> Y-axis always. The DOF should be defined within this local 'rest  
> position' as well.
> It's also worth checking on some kind of elasticity here. Where the  
> "DOF" per rotation axis can get 3 values:
>   - Minumum rotation freedom
>   - Maximum rotation freedom
>   - Strength
> Where "Strength" here defines some weighting factor during IK solving,  
> to define which joints can be easiest become bent.

Yes, joint stiffness (can be per DOF of course) is on my list.

> I can make a nice drawing option in 3D for the DOF, and check on how  
> these values can become interactive editable (using transform).

If we do not use euler angles, this would need some conversion routines,
but I can provide those.

> Since all these values should be animatable, the bPoseChannel struct is  
> where the joint information will reside, denoting the freedom of a bone  
> with respect to its Parent bone. I can make sure the Action Channels  
> for it will be added.
> 
> - "Translational Joints"
> 
> I am still not sure what this means... how is this defined, as one part  
> of the DOF? Would that mean three values (X Y Z) too?

A translational joint works just like a typical rotation joint, but instead
translates over some axes instead of rotating. X,Y,Z DOF for it can
be enabled/disabled just like rotational joints.

This is mostly useful for mechanical stuff. But also for characters it
could be used to construct a 'free' 6DOF joint, which is useful as
a root bone that can move freely.

> - "Orientation control"
> 
> You mention this... what's it?

This means that not only the position of the tip, but also its rotation
can be controlled. So if you rotate the target, the IK solver will
try to let the tip follow that.

Brecht.