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

[Benoit Bolsee]

You can actually run some tests now if you want. I put test builds on
graphicall some time ago:
http://www.graphicall.org/builds/builds/showbuild.php?action=show&id=108
0
http://www.graphicall.org/builds/builds/showbuild.php?action=show&id=108
2
They are based on an old revision (I will update them this week), but
you can already see the interaction between the cache system and
blender.

/benoit

*****************
Mon Aug 31 02:38:41 CEST 2009, Goat Man <goatman.py at gmail.com> wrote:


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