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

[Brecht Van Lommel]

Hi Benoit,

On Mon, Aug 31, 2009 at 2:19 PM, Benoit Bolsee<benoit.bolsee at online.be> wrote:
> On Mon, 31 Aug 2009 10:49:32 +0200 Brecht Van Lommel
> <brecht at blender.org> wrote :
>>
>> I don't think the cache is good default behavior for
>> animators. It may be for robotics but Blender is primarily an
>> application for animations, so in my opinion it should be
>> disabled by default. When you're posing a character on a
>> particular frame, you want to see how it looks immediately,
>> while you're grabbing the hand. Seeing it only when you
>> release, or even later in a playback, that would be a big
>> step back in my opinion.
>>
>
> The new solver is stateful, which implies caching the pose for previous
> frames if you want to be able to go back and forth in time in a reliable
> way. Having a stateful solver has some definite advantages: speed and
> consistency of the armature movements. The drawback is the cache issues
> that we are discussing now.

The current system definitely has a disadvantage that it does not
ensure consistency between frames, which may lead to flips. However,
riggers make IK setups to avoid this problem, and if we wanted to
solve the consistency problem there are other ways to do it without a
cache, based on inserting FK keyframes after moving an IK targert.

In robotics of course you approach things more like a simulation, then
you need the cache. In animation the animator needs to be in complete
control, and will spend time anyway to get each frame looking right.
So automatically ensuring consistency then is less important, and the
drawbacks of such a cache system become a bigger problem.

> Actually it is possible to disable caching (as it's done in the BGE). In
> this case, the solver simply starts from the current pose position in
> all cases. This has the advantage of being fast all the time but it
> makes the animation unreliable: running the same animation twice might
> give a different result since the start pose of the second run is the
> end pose of the first run. I don't think this is a desirable effect but
> it can be an option in the solver.

I'm not sure why the animation would be unreliable, the current IK
system does not have this issue, it looks the same each time you run
it?

Thanks,
Brecht.