Armature is distorted in 2.80 but not 2.79

I recently switched from Blender 2.79 on Windows to Blender 2.80 on Zorin OS (a Linux distribution based on Ubuntu). On 2.80 there is a problem with the armature that I didn’t have on 2.79. IK works fine, but when I rotate the upper arm bones with FK, the mesh gets distorted. It looks like the bone is rotating the mesh by a bigger angle than the bone is rotated. The other bones seem fine. There are a lot of modifiers on the object but when I deleted them all I still had this problem. I also have a python script that runs automatically in the file, but it is a simple function used for drivers.
shoulder_test_20190925.blend (1.1 MB)

If you delete the drivers, the problem goes away. Guess they’re not so simple. (and reset the pose, since your shoulders are aimed diametrically opposite where they should be.)

If you deleted the modifiers, upload the version with the deleted modifiers. We want to see the simplified problem. We don’t want to delete four thousand modifiers to simplify the problem. For next time.

Thanks for your response. Deleting the drivers removed the problem but I needed the drivers to rotate the shoulder/collar bone when the arm rotates over the head, and so that the arm is above the shoulder when rotated over the head, but to the side when rotated down. The latter I discuss in Arm rotation 180 degrees: Is the arm out to the side or over the shoulder? .

I suspect this issue is related to dependency cycles. The shoulder has a driver which depends on the upper arm and the upper arm is a child of the shoulder. However, the upper arm only inherits the offset for loc/rot/size, and the shoulder being the parent does not affect the upper arm bone’s own rotation value. The shoulder bone only depends on the upper arm’s own rotation value (and not what the upper bone inherits from the shoulder) so I don’t think the cycle is really dependent.

I guess I’m going to have to redesign my rig so that there would be separate bones to rotate for FK, then put a copy rotation constraint on the arm bones to copy the control bones. If I make the top spine bone the parent of the upper arm control bone, then the shoulder would still depend on it but it would not depend on the shoulder.

Something I’m not sure about is if I should leave the IK chain how it is, or if I should make a separate chain for the IK bones.

Making sure I understand correctly: upper arm’s scale+location is dependent on the shoulder. Shoulder is dependent on upper arm rotation.

If this wasn’t an IK system, there wouldn’t be a true dependency, and you could figure out a way to fool Blender somehow. But because this is an IK system, the rotation of the upper arm depends upon the scale and location of the upper arm-- so shoulder depends on itself.

That means that, yes, if you separated out the IK to an independent structure, you could find a way to make that work for FK. But for FK only. It’s never going to work for IK.

Not that that’s necessarily the problem. I personally draw the line at debugging other people’s drivers, so I haven’t inspected beyond what I needed to discover that, yup, the drivers are involved in the problem.

I found this page https://blender.stackexchange.com/questions/65849/shoulder-movement-following-the-arm which has an animation showing how the shoulder should lift has the arm lifts over the head. This is the purpose of the drivers on the shoulder. Somone has a suggestion of how to solve it, but other commenters say it creates a dependency cycle. Another commenter says there is no clean way to automate shoulder rotation in Blender.

How do people animate the shoulder? Do they manually lift the shoulder any time the upper arm rotates above the head? Do people simply leave the shoulder as it is?

On a past thread I talked about the conflicts between drivers and IK What algorithm will solve IK? . Someone said that a driver does not introduce a dependency per say, even when a child object property is used as a variable for a parent. In my rig, the upper arm inherits location and scale from the shoulder, and the shoulder depends on the upper arm’s local rotation. I’d expect this to mean the upper arm’s rotation will affect the shoulder’s rotation which will affect the upper arm’s location and scale, so the upper arm’s inherited location and scale depend on its own local rotation. I wouldn’t expect that to be a dependency cycle since no individual property of the bone depends on itself (even though some properties of the upper arm bone depend on other properties of itself). Maybe my expectations would only apply if it were only a FK system.

In any case, could anyone tell me how they handle the shoulder rotation while the arm lifts over the head, or does anyone have an suggestions as to how I could handle it?

I haven’t come up with a perfect solution yet myself.

Here’s what I’ve been doing:

Rather than trying to do it with a three bone IK, or do gymnastics to aim the clavicle properly prior to IK evaluation, I track a non-deforming, two-bone IK chain with shoulder + arm bones. The origin of the chain ensures that the point that the clavicle will track will rise above the level of the shoulder with less rotation than it would take to rise below the level of the shoulder (and tracks the elbow for world Z rotation.)

Then, yes, you need another laer, because clavicles aren’t fully determined by the position of the spine and the elbow-- there’s freedom of motion there.

This isn’t perfect. It’s good enough for me and not too much work.

Thanks for the response but I don’t understand. Which bone(s) should have the ‘Track To’ constraint? Should the IK chain include a shoulder bone?

I attached a rig where I put a ‘Track To’ constraint on the left shoulder bone. A problem is that the shoulder rotates around 60 degrees when the arm is over the head. I can set the influence to 0.25 to limit it to 15 degrees, but the shoulder also rotates down when the arm is at the side.

My modifications in the attachment are only on the left side of the armature. The right side is still rigged the way I originally rigged it.
rig_20191013.blend (4.0 MB)

No, no track-to constraint.

The Ik chain being tracked (not with a track-to) is only two bones. The first bone in the chain is a sort of should and arm combined into one.

The shoulder bone tracks a marker bone that is parented to IK1 via a damped track constraint.

The upper arm and lower arm (in that pic) track IK1 and IK2 respectively via damped tracking bone tails, then locked tracking marker bones.

With a little more play after writing that, I found that actually running the IK twice works a bit better than that, though. First I run the IK to get a proper-ish position of the shoulder bone, then I run it again (with a pole target parented to IK1) to get proper positions for the upper and lower arm from the position I figured for the clavicle.