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

[Matt Ebb]

Goat Man wrote:
> What about just having a way to save the current frame as a
> "cache-save-point", this takes whatever state its in and saves for later
> recall by the solver.  Changes before the cache-save-point will NOT update
> this saved cache.  Then the animator can place these cache points to have
> predictable results where he needs it.  This could be a very useful tool for
> animators, we just need the right interface for it i think.
>   
This doesn't sound too good to me. If you're talking about replacing the 
existing IK, animators should be able to use it the same way. No extra 
steps and hurdles, no caching to keep track of, no save points, no 
superfluous keyframes added. Animators need to be able to quickly and 
easily go to any frame in the animation and tweak poses immediately, 
working entirely fluidly. They also need to be sure that the pose 
they're looking at on screen is what they're going to get.

I hear in this thread about problems in the existing IK system, but in 
my experience (animation) I've never seen problems in practice, nor have 
I heard our animators/rigger complain about it either. I understand it 
may not work well for robotics, and it's good to make life easier for 
people working in this area. However robotics is not blender's primary 
target, animation is, so if there are to be any changes they should 
result in something at least as usable for animators as the previous system.

cheers,

Matt


> On Mon, Aug 31, 2009 at 8:53 PM, Brecht Van Lommel <brecht at blender.org>wrote:
>
>   
>> 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.
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>>     
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>