[Bf-committers] blender2.5's new IK
goatman.py at gmail.com
Mon Aug 31 02:38:41 CEST 2009
If working on a long animation, waiting for it to cycle might take too long,
what if my animation is 10 minutes long?
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.
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.
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
> 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.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers