[Bf-committers] Rigging limitations / IK Features

[Charles Wardlaw]

I wanted to pull the reply to this this out of the convo on the robotics IK
stuff and put it in its own thread.

On Mon, Aug 31, 2009 at 9:06 PM, Matt Ebb <matt at mke3.net> wrote:

I hear in this thread about problems in the existing IK system, but in
> my experience (animation) I've never seen problems in practice, nor have
> I heard our animators/rigger complain about it either.


There are a few things missing, actually, things that I wish I had
constantly when I rig in Blender:

- There's no way to set a local pole vector without adding a pole vector
object.  It would be nice to be able to set a vector based on the local
space of the root of the chain (the way Maya does it) when pole vector
objects aren't wanted in order to define the rotation plane.

- Pole vector offset rotations are limited to -180 to 180.  This limit needs
to be removed, especially since it's something that should be applied after
the IK has already solved.  Again, this is a wish from a full-time Maya
user.  Most riggers I know use the pole offset (the "twist" value) for knee
control.

- There's no way to specify which local axis becomes the pole axis on the
constrained object.  IE, if I want the axis to be aligned to the root
object's +X, but the pole vector comes up as -X, there's no easy way to fix
this.  If you use the offset to fix it then you can't use the offset to
adjust knees since you'd hit the 180 degree limit immediately.

- There's no way to blend between two separate pole vector objects.  This is
something that no software I know does well; it requires a proper quaternion
slerp between the two vectors generated by the pole objects, and I think
only XSI or Houdini are currently capable of this.  On our current project
at work we're not using motion blur so I fudged it. ;)

In any case, Blender IK is stable and useful.  It's just not as robust as
other solutions, causing certain kinds of rigs to be more complicated than
they need to be.  I'd be keen to hear what other people think.

And if we're on the topic of rigging limitations of the current constraints
system, the Track To constraint needs a pole vector object option as well,
separate from the TargetZ axis button (which shouldn't be just TargetZ, but
should be able to use any of the axes, positive or negative).  The Up axis
should be specifiable on both positive and negative vectors.

If any of the above doesn't make sense, I'll make a video and post a link.
If any of the above is handled in Blender already and I just didn't see that
patch float through the dev RSS feed, please let me know. :)
~ Charles