[Bf-committers] blender2.5's new IK

[Benoit Bolsee]

> Date: Sun, 30 Aug 2009 13:44:06 +0800
> From: Goat Man <goatman.py at gmail.com>
> Subject: [Bf-committers] blender2.5's new IK
> To: bf-blender developers <bf-committers at blender.org>
> Message-ID:
> 	<de5af5e90908292244j24ee1bebtc8d06aef335375d7 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
> 
> Is Benoit's new IK for Blender2.5 for the BGE only, or will
> it use caching and be avilable in the editor to?  What about 
> the problem of the animator going back in time, making 
> changes, and then having unexpected results in the future.
> 

The new IK is also for Blender. Caching is automatically enabled when
used in blender and disabled when used in the BGE. Going back in time in
blender and changing things that may have an influence in the future
usually results in the entire cache to be cleared. This has some nasty
side effects. 
To better understand that, keep in mind that the IK algorithm doesn't
know what is the starting frame of the animation. So it considers that
any frame that doesn't have a previous position in the cache is a
starting frame. In this case, the algorithm converges to the IK targets,
starting from the rest pose, and reiterates until the armature doesn't
move anymore. 
This is the normal behavior for the actual starting frame but it's not
desirable at any other frame. So if you are at some frame and do an
action that causes the cache to be cleared, you'll see the armature
taking a pose that is most probably not the correct one. You can only
see the correct pose if you run the animation from the start => the
initial pose will be set correctly and the cache will build up from
there.
I didn't find a easy fix (or even a difficult one) to this problem. My
best suggestion is to run the animation in cycle while you're changing
things and watch the effect of your changes in the next cycle (blender
2.5 allows that). The IK algorithm is fast enough to run complex
armatures in realtime without problem.

> One simple thing that Blender's IK is lacking now is bones 
> with "stretch" enabled wont respect LimitScaling constraints 
> applied to them.
> 

So far I worked on the basis of reproducing all the effects of the old
solver plus inherent features of the new solver. So bone stretching is
working the same, i.e. without limit. It's not difficult at all to add
limits on stretching. I will try to add it before merging with 2.5
branch in the next couple of weeks.

Regards,
Benoit