[Bf-committers] Constraint-based IK project integration in blender

[Benoit Bolsee]

Hi,
 
The Constraint-based IK project has reached a state where integration in
Blender can start. My goal is of course not to break anything that works
today, so I will create a plugin model to allow concurent IK algorithms
(this will come handy when dynamic armature algorithms are implemented
in Bullet). 
Initially I will need to work on a branch but as soon as the plugin
model is in place, I can go back to trunk. Is there a branch I can
reuse? I will mainly work around the "where_is_pose()" function;
anything above it should be left unchanged.
 
So far I have reviewed the code in where_is_pose() (and all functions
below it) and I have complete understanding of the pose operations
except the NLA modifier that I still need to review. I wrote a document
explaning the data structures and workflow of where_is_pose(). If there
is a wiki about Blender internals, it could find its place there.
 
The current IK algorithm tracks on position and optionally on
orientation. The new IK algorithym can track on many different things
but as I need to start somewhere, I will start with this capability
alone (the "CopyPose" constraint). Here is how I see the UI: when you
define an IK constraint on a bone, you can also activate a "handle" on
that bone which can be used as the target with several options: the tail
or the head tracks the handle, with or without copy rotation. You can
drag and rotate the handle, the bone (and the IK chain) does its best
effort to track the handle. The goal is to be able to control position
and orientation of a bone like we do today but without having to
disconnect it from the parent (no need to disconnect the "foot from the
leg"). The algorithm does not guarantee exact match on position but the
precision should be good enough for the benefit of speed. 
 
I think this approach could also be useful to the current IK system: as
the full bone chain is always connected, there is no critical need to
match exactly the target and it could stop iterating before an exact
match is reached. You can already have a feel of this system if you set
the maximum number of iteration to a small number like 8. Of course the
precision gets worse when you bring the target far from the rest
position, this is because the current IK always starts from the rest
position. The new IK starts from the pose of the previous frame and
should track much more accurately with as few as 4 iterations per frame.
 
To summarize this long Email
- Can I get a branch to start working on that?
- Do you think it's useful that I add this "handle" concept to the
current IK (I must implement the UI anyway)?
 
/Benoit