2.5 bonestiffness

Hi all. Thought I’d start a discussion (unless one is already underway) on the current settings for bone stiffness in blender 2.5.
Here is an example of how I see the current implementation falling short. Each bone has a global stiffness irrespective of how many IK chains it’s a contributor to. In the image below, you can see how it’d be useful for a bone’s stiffness to vary from chain to chain.
http://www.glennmelenhorst.com/misc/blender/bonestiffness.jpg

The bone pointed to should be set to .9 for the arm’s IK chain and .6 for the spine’s IK chain.

Any thoughts/opinions?

Glenn

Okay, first off, I’m presuming you’re talking about a multi-target IK setup? So both of those chains simultaneously have an IK constraint on them? As opposed to some kind of IK switching setup?

Presuming that’s the case, the problem is that they’re not actually separate IK chains to begin with. Blender is actually solving the whole thing as a single system. In reality it’s a single chain that branches, not two separate chains that overlap.

I’m not entirely sure how the latter would even make sense, actually. How would it solve two separate overlapping chains at once? You’d need not only two separate stiffness values for each bone, but also a third value per-bone to specify how to blend between the two chain’s solutions. And I guess I’m not sure what behavior you would really expect from that.

What use-case are you thinking of for this? And what differences in behavior would you expect relative to the current system?

This sounds sort of like ‘Full Body IK,’ if I’m understanding it correctly.

Full body ik is one usage case scenario. But multiple-chain ( or ‘branch’ as Cessen points out ) can apply to only certain bones in an armature.

If a bone on one ik is at 100 percent stiffness, while for another chain, that same bone is 0, how does that bone interpolate? Assuming both ik constraints are at 100 percent influence?

To me, that introduces to many variables, that can only lead to more configuration. While configuration is fine, I can’t think of any usage case scenario requiring it.

The cognitive problem here is that the IK weights property is only applicable to “tree” IK chains (which from the tool tips seems to indicate a chain of bones all of whom have an IK constraint applied) which has never AFAIK been demonstrated using Blender or for that matter any other app AFAIK .

If you can post a blend showing how this is currently implemented (this is not a 2.5 innovation) that might help .

What you seem to want to do would be to finally have a IK solver that doesn’t ignore other constraints such as limit rotation which the new iToc IK solver is supposed to do (this is is in the trunk and in current builds, though I don’t know how functional it is) .