Various rotations stacking with dynamic bone

I have a torso and a head, both with a dynamic bone applied(ragdoll/bone gravity).
Each also has a script which rotates them towards a target.

direction = target.transform.position- transform.position;
rotation = Quaternion.LookRotation(direction);
transform.rotation = Quaternion.Lerp(transform.rotation, rotation, weight);

The torso rotates fine, but when the head rotates, it is almost as if it is inheriting the torso rotation, causing it to look past the target. (torso look-at + head look-at)

What’s more, if I disable the look-at script and re-enable it, it fixes it. The problem also never happens if there is no dynamic bone component, so something about that causes it.

What behavior from dynamic bone could be causing this? It also does not happen with Unity’s LookAt constraint.

It could be some rigging in your model that has some weird initial (bind pose) orientations. I’ve seen this mix up other code trying to do some manual animation in the model.

The object has no animations, and is in it’s default (T-pose) position.
What would be a weird bind pose orientation? I think if that were the case, then all of the look directions would look weird, rather than the strange doubling and on/off behavior.

The problem I had was with an asset store model rigged with bones that were twisted 180 at one level, then twisted again, at the next level down, both on their linear axes, and something about the Ragdoll Wizard just couldn’t choke that down: Unity would just lock up.

There doesn’t appear to be any bones with unusual rotations on the model. They are all zeroed out and aligned.

Does the look-at script implement any OnEnable/OnDisable methods that might do something funky?

Nope. It works in general unless dynamic bone or similar types of components are added.

I also dont get why it works if you disable it and enable it. I might have to resort to doing that in code but I dont know how to do that either.

Another candidate to explain this is order of script operation. Make sure your scripts work regardless of which ones run before the other.

If your inspection reveals that execution order turns out to be the case, do NOT use the script execution order settings to fix this: that way lies pure madness.

Instead, either refactor your code to not care about order execution, or expose some MyUpdate() types of methods and drive the order yourself.

Why are script execution settings bad to use?

Because they are not in the code. Six months from now you will copy this to another project (or give it to a friend to use) and there your script execution settings will not have been set up, and now mysteriously you’ll see weird errors.

Keep it in the code and put it under source control. Otherwise you’re not really engineering, you’re just YOLO-coding.

Yes, I suppose that is true.