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

[Goat Man]

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.
-brett

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
>