Hello!
As the topic of the thread says, I have a constrained bone with copy location with offset that is constrained to an IK bone, I am moving the IK bone, but then cancelling the movement to snap it back to its original position, yet the constrained bone with copy location is not snapping back to its original position.
This video shows the issue more clearly.
Thanks! 
If anyone is interested in the artist who created the awesome model+painted it: https://www.artstation.com/artist/hedstrom
It’s tough to tell just what you’ve got going on there. Is the constrained bone the elbow pole? Is it constrained to the IK target, or a bone in the IK chain? If it’s the pole, and it’s constrained to a bone within the IK chain, it’s a cyclic redundancy, and it will not update smoothly.
It is constrained to an IK.
So what is a good workaround for this?
Edit: I take it back, it was constrained to the first bone in the IK chain. Woops!
Thanks, constraining it to the IK fixes it! 
Here’s the way I like to setup the parenting of a pole bone. The MCH-ElbowParent does a damped track toward the IK_Target…
IK_Arm.blend (91.5 KB)
Thanks for the blend, really cool way to solve it!
Now when I have a thread up anyways, is there a way to prevent the IK bone deviating from the first bone? (I suck at explaining so see the pictures below)
So if I move the IK too far in any direction it keeps going away, instead of being locked in place like how I want it to be.
Edit:
Also any tips in how to make the shoulder rotate along with the IK when I for example put up the arm to a T-pose? Would be cool if I could get the rig to handle that without me having to do it manually every time
I’ve played with that a bit and haven’t figured out a way to do it cleanly. If you figure it out post your solution, cause I’d like to see it.
Which of the two are you referring to? I will probably post solutions(If I manage to solve it) to both anyways, just curious
You snuck that edit past me. I was referring to have the IK target stick to the end of the arm. But actually my response would apply to both. They’re both functions that, I think, can be hacked, but end up being limiting, or not working at all in some situations. From an animators point of view, I think, it’s simpler to deal with the bones as they are, rather than fighting constraints that keep getting in your way.
If the IK target is parented to the root bone, which it should be, I cannot see a reason why it needs to “stick” to the arm bones in the IK chain, since it still works even if it is not exactly in place. The arm bones won’t stretch if you move the target away from them, unless you have enabled stretch in the IK panel. I will of course withdraw this remark if it can be proven that there are bad side effects to this situation. Also bear in mind that if you add other constraints to the bones, they will be ignored in the IK chain since that takes preference. You could try a Limit Distance constraint, so the target does not move more that the length of the arm away from the shoulder joint, but I cannot see any reason to do this…
Cheers, Clock.
Yes - I tried it and Limit Distance worked: :yes:
The limit distance target is the “arm-rot” bone just above the shoulder. The IK is parented to that bone, which in turn is parented to the root bone. This enables me to rotate the arm like you would if you where bowling a cricket ball for example and the IK target then moves along an arc. The limit Distance keeps the IK within a max distance of the control bone so you cannot “over-flex” the arm. Varying this distance keeps the arm slightly bent if the distance is less than the true length of the arm.
Cheer, Clock.
PS. the Limit Distance target bone CANNOT be a bone in the IK chain or a cyclic dependancy occurs.
I don’t see how that works in practice clock. If the shoulder moves, the arm-rot is no longer located at the shoulder. If the arm-rot follows the shoulder, and the ik target is parented to it, that defeats the advantage of ik. Doesn’t it?
I see what you are saying, If you parent the arm-rot to the shoulder, you have to shorten the arm IK chain so it does not include the shoulder - then it works in practice, however, if you want the shoulder in the IK chain then the arm-rot cannot be parented to the shoulder, or you get the cyclic dependancy. When I use this system, I want the shoulder to move when the arm “bowls” a ball for example, so the way I find it works is to have the arm-rot close to the shoulder joint but not on it so it can move the shoulder as well. It is a bit of a compromise, the alternative is to parent the arm-rot to the spine so it moves as the back is moved. That is probably a better solution to what is really an impossible problem since the ideal solution, keeping arm-rot at the shoulder, results in a cyclic dependancy if the shoulders part of the IK chain. To be honest, I don’t worry about the IK target moving away from the arm, since that does not effect the animation at all, it merely extends the arm to “full stretch” when it is moved away. use of the arm-rot bone does allow me to do the “swinging arm” action easiest of all rather than change to FK since I might want the arm to extend as it swings in certain scenarios. For that I tend to move the arm-rot to a theoretical centre of rotation, so the arm extends as it swings.
Cheers, Clock.
Solutions to both problems:
One, do not include the shoulder in the IK chain. It’s better to deal with it separately. There is a good reason that pro riggers leave it out and that reason is, including it in the IK chain causes more counter animation then it prevents. I’ve tried many methods to automate the shoulders and I always revert to excluding it and animating it as a separate control.
Two, do not use a pole target. You can directly change the direction of the arm by rotating the upper arms local y axis. Pole targets are not needed and it’s “cleaner” in the graph editor.
Check out the the blend file with simple IK chains and no pole targets.
Points of interest: The rotation of the upper arm or thigh bones controls the direction of the elbows and knees. All axes are locked on the upper arms and thighs with the exception of the Y and W rotation values. Using quaternion rotations is more stable then Eulers for this method. Leaving “W” unlocked also makes it more stable.
Just my two cents.
Good luck!
Edit: I took a look at your vid that was posted. I’m surprised no one mentioned that your pole targets are in front of the arm instead of behind. Change their location to be behind the arm in edit mode if you still wish to use pole targets for your IK chains.
SimpleIK.NoPoles.blend (508 KB)
DanPro, multiple videos I have followed set the pole targets in front of the model, you saying this is not the correct placement of them?
Thanks all for the helpful tips and everything! Appreciate it tons, it helps a lot
Now when I have this thread still running, I might as well keep shooting questions!
If I am in Edit mode of the model, and want to assign weights to vertices manually rather than painting (because then I can also hide parts of the model) is there a way to see the result of that as opposed to having to tab over to object mode?
Yes, that you can do. In the top row of the armature modifier turn on “Display modifier in edit mode” and “Adjust cage to modifier result”
Yep. There is a lot of crap out there. Be careful what you watch. 
Knee targets should be in front, elbow targets in back. (For a typical A or T Pose) Put the pole target on the side that joint will bend. This is not a hard rule, just good rigging practice.
I would also align the IK pole target bones with the world axes. A lot of tutorials skip this too. If you align the target bone with the world, it makes more sense in the graph editor. In your screenshot above, your pole targets have the Y axis up. Again, not a hard rule, but good rigging practice.
Good luck!
Ahhhh, thanks! I knew I remembered the possibility to do that!
Thanks a ton for your help! Appreciate it a lot!
I tried it out with the positions and correct axes for the poles, but I believe I will go with your poleless workflow you suggested earlier, the less messy and daunting the graph editor get, the more fun I can have when I finally get to animate this thing
