IK broken with 2.73 and 2.74 RC

hello,

I try to do IK rigging

so I have the simplest bone chain made out of 4 bones

I select the last one and the second one, I do shift+ctrl+c
I grab or rotate the last bone and the whole armature rotates at light speed for no reason

If I select the second bone then the last one and add the constraint, then the bone chains cycles on itself, and on grab/rotate, the whole thing rotates all over the place

where do I report this bug ? (if you dont believe me, just give it a try)

regards

post a blend. I don’t believe you (and IK is working fine for me)

here it is
http://robot.isp.imath.be/ikissue.blend
as mentioned, I grab the last bone and everything goes to whack
I also tried by inverting the constraint between the two bones, but then I cant move anything, the last bone target stays in place

I used IK with 2.5 a zillion times, so, either IK concept has radicaly changed since or there is a bug

so?? did I lie ?

please can you post a working example ??

hello, mr oh-you-must-be-a-liar-it-is-working…

I found on another forum that the IK target cannot be bound to the bone chain
wich is odd since tha’ts the way it worked in 2.49
having to move a foot + another bone is quiet tedious, why cange something to make it worst ?

Your bone chain is backwards. Consider a leg, the foot is child of the shin, the shin is child of the thigh, but the IK constraint is placed on the foot, and works opposite the direction of the heirarchy. Plus the IK is supposed to point to something. In other words, a bone, not in the heirarchy chain, is the target that the IK bone tries to maintain contact with.

From the sound of things your IK target is parented to a bone within your IK chain. That does give problems and, as far as I can remember, always has? Maybe someone can correct me on that.

When IK setups go whack, it’s almost always because of a circular dependancy somewhere in the set up.

A circular dependancy happens when bone A controls the motion of bone B, and bone B controls the motion of bone A. so A moves and that moves B, which moves A in turn, which again moves B, which moves A, which moves… you get the idea? It keeps going until it runs into Blender’s iteration limit, usually something like 500 loops, and the visual effect is an out of control armature “going whack.”

There are lots of ways to create circular dependancies. One of the most common is to have the IK target parented to the IK chain.

I think you might get an error message somewhere, so check the info window header carefully. But, basically, check each bone, and anything that can make it move (parent-child relationships, IK constraints, follow rotation or location constraints, etc.) If you find a bone affecting another bone that affects it, there’s your problem.

It has never worked that way. It cannot, logically, work that way. You cannot have bone A’s location or rotation affected by a bone that is similarly affected by bone A.