[Bf-committers] new IK algorithms in Blender
Brecht Van Lommel
brecht at blender.org
Tue Jan 13 15:44:12 CET 2009
Benoit Bolsee wrote:
> Unlike the current IK algorithm in Blender, the new algorithms are
> stateful and time dependent: you cannot get the pose for a given frame
> number if you don't know the pose and the internal state at the previous
> frame (and recursively at the begining of the simulation). The BGE is a
> natural place to implement the algorithm because it is naturally time
> dependent but we also want to have the animation available in Blender
> for frame by frame inspection of the actions.
> One possible approach is baking via the BGE: you prepare the setup,
> define the task by constraints and run the simulation in the BGE. The
> joints positions are stored in Ipo curves and retrieved in Blender.
> Another approach is to have baking or caching in Blender like cloth (I
> didn't look at cloth code yet). Baking the IK solution should be fairly
> quick, potentially much quicker than the current IK algorithm that
> always starts from the rest position at each frame.
> My idea is to implement a flexible caching system that will be available
> in Blender for animation and in the BGE for recording the simulation or
> the actual physics parameters when the BGE is used to control a real
> robotic setup. I'm interested to hear your opinion on that.
I'm not sure about the best solution, both point caching and ipo
curves give a part of the solution. Point caching as used by cloth
deals with a part of the problem doing caching, baking, clearing
caches on changes, etc, but it works with modifiers currently and not
ipo curves or the armature animation system. If it's baked in ipo
curves on the other hand that means you already have playblack,
editing and visualization of curves. But you still need a way there to
distinguish between ipo curves as animated by the user and fed into
constraints and the cached/baked ipo curves resulting from those
I have no idea how the workflow would be for robotics, and also how
such a system works best in an animation system even, mixing animation
and simulation is complex. So I suppose you should look at practical
use cases and figure out what you need for them.
From the animation point of view you quickly get questions like:
* How to interactively edit animation at keyframe 200 without having
to wait and rebake from frame 1 each time? Is this possible at all?
* How to keep animated data and simulated data separated? By layering
one on top of the other? Like layering actions in the NLA perhaps?
* How to tweak simulated results? How do you make it clear to the user
that edits to simulated data will be lost? Or can such edits be
However from the robotics point of view maybe all you want to do is
specify parameters, and then run the simulation from scratch each time
and inspect it? In that case the solution can be simpler but perhaps
not as suited for animation.
More information about the Bf-committers