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

[Benoit Bolsee]

> If working on a long animation, waiting for it to cycle might take too
> long, what if my animation is 10 minutes long?

You could just run a cycle around the frames that you are changing. The
variability of the pose depends greatly on the armature and the target
configuration. If you have a complex armature with many degrees of
freedom, then a lot of different poses are possible for a set of IK
targets and which one is chosen depends on the past. Same if your IK
targes are moving too fast for the armature dynamic: the pose lag will
depend on the past. But if you have few degrees of freedom and
reasonable targets, then the variability is minimal and running a small
cycle around the frame will give you the correct pose.

> Can some kind of progressive refinement be used here?  Lets say i
> made several changes to the fcurves, and now i am scrubbing my
animation
> back and forth.  If i could at least get a preview of what it will
look
> like quickly that i can work around.

When you bring the timeline backward after a cache clear, you basically
set a new starting frame everytime you decrement the frame. This is
because the solver will not find a previous cache position and take this
frame as the starting frame. This result in high CPU consumption
(because of the reiteration) and may be slow. That's why it's better to
set a starting frame and run from there. Once the cache is built up,
going back and forth is fast. If you set the starting frame somewhat
before the frame where you did the change, you're likely to see quickly
what it will look like. 

> What if when the cache needs to be cleared, maybe in a background
thread
> it starts refilling the cache, but skipping every so many frames, and
> then when its done it goes back and fills in the holes.  So if the
user
> waits long enough, its fully accurate, if they are impatient and start
> scrubbing right away the results are close by not perfect.

The IK solver needs the target objects matrix to compute the pose. If
it's possible to run a background thread that sets the objects matrix
according to their f-curve, then it's possible to rebuild the cache. I
don't know anything about this kind of operation. For example, I didn't
put any thread safe protection in the cache system, would it be
necessary? Where can I find information about this kind of operation?

/benoit

On Mon, Aug 31, 2009 at 6:52 AM, Benoit Bolsee <benoit.bolsee at
online.be>wrote:

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