driven bone with limits

[Alessandro Padovani]

daz studio 4.15.0.30, blender 3.0.1, diffeomorphic 1.6.1.0893

This is related to #901.

I believe I got a way to keep limits with driven bones. The same as daz studio does.

The actual implementation makes the posable bone a child of the driven bone. This way it is not possible to preserve the limits because the posable bone space is relative to the driven bone. So instead of parenting we should use a add constraint and keep limits. That is, the driven bone rotation is added to the posable bone.

steps:

1. The posable bone parent is not changed to the driven bone.
2. We keep the posable bone limits.
3. Before the limit rotation constraint we add a copy rotation from the driven bone with add as action.

Below an example with the G8F lshin bone.

‌

This way it is possible to use body morphs and keep the limits for posing. The same as daz studio does. Below an example with the "knees up" body morph for G8F. The "knees up" morph is applied at 50% so the driven bone is half way, the posed bone is counter rotated by 60 degrees and the limits are correctly preserved.

‌

[Thomas Larsson]

That might be a good idea. I will look into it eventually, but currently I am too distracted by geopolitical events to think about it.

[Alessandro Padovani]

Yes I guess we all are here in Europe.

[Thomas Larsson]

Just implemented this, and it seems to work well although there may be cases I haven’t thought of. Body morphs don’t work with Rigify, and only mhx-compatibles ones work with mhx, but I think this was the situation before as well. It felt good to think about something normal for a while.

[Alessandro Padovani]

I hear you Thomas. To me this is part of my fun and a good thing. So I won’t let bad things to take it away if possible. That’s not ignoring important/bad things that need to be dealt with, that unfortunately in my own life there are always. I just try to live well for what I can.

Commit d8e9b8c seems to work fine here. But I noticed that the final bones are not there anymore, though I have no idea what they were used for. Before there was a layer with the final bones that just copied rotations from the posable bones, as far as I can tell. I wonder if this is an optimization or a bug.

steps:

1. import G8F and merge rigs
2. import body morphs with make all bones posable

edit. As for rigify and mhx I guess they’re more for original animation using ik so it’s fine if support for body morphs is limited. I mean body morphs are most useful to pose the fk rig anyway.

[Thomas Larsson]

The final bones were used in drivers, to get the rotation of the free bone relative to the driven bone’s parent. But now the free bone has the same parent as the driven one, so the local rotation or translation of the free bone can be used instead. Much simpler.

[Alessandro Padovani]

Ok thank you for the explanation. Will leave this open for #904 to be checked and to hear from Luke #901, then if everything is fine I’ll mark as resolved.

[Luke Graybill]

This is exciting! I will test and report back in #901 later (heading to bed now) but this sounds very cool. Thanks to you both!

[Luke Graybill]

This is awesome so far, but there are a few minor things I’ve noted while testing build 0894.

• Corrective shapekeys don’t seem to be driven by bones any longer. Here I’ve posed lShin and lThighBend bones into roughly the position they’d be in if the Knees Up Left body morph were set (note though that the body morph is not set in these images):

‌

• Possibly related, I’m not sure, but there is also some odd behavior observed by starting from rest pose, first setting Knees Up Left all the way up, and then extending lShin as far as it will go along it’s local X axis:

‌

• If I instead start from rest pose, first extend lShin as far as it will go along it’s local X axis, and then set Knees Up Left all they way up (the order of operations being important there), this is observed - which I figure is probably again due to shapekeys not being driven by posed bones:

‌

• Starting from rest pose and bending lShin as far towards the rear as it will go, and then creeping up from zero with the Knees Up Left morph works okay until the value hits 0.062, interestingly enough:

‌

‌

I’ll continue messing around and trying to find broken things, but so far I’m enjoying this new approach. I haven’t used it on any existing characters yet to know whether it works smoothly with old manually adjusted poses, so that’s probably the next step. Not sure when I’ll have time to check on that though, but I’ll report results when I can. Thank you!

[Thomas Larsson]

There were cases where the shapekeys were driven by the driven bone rather than the free bone with the combined rotation. That should now be fixed.

I also had some problems with the free bone jumping when the slider was moved, but now I can’t reproduce it anymore. It had something to do with the interaction of the copy rotation and limit rotation constraints.

[Alessandro Padovani]

Overall commit caab74c seems to works fine. Both the issue in #904 and jcms are fixed.

The other issues reported by Luke can be fixed by using “affect transform“ in the limit rotation constraint. This way the transform tools (move rotate scale) are affected as well. There is still some flipping if we push over the limits too hard I guess this is due to the euler system, but no more strange deformations.

‌

[Thomas Larsson]

No, this doesn’t seem to work. The local rotation of the shin bone doesn’t go below -11, whatever the value of the slider is.

‌

[Alessandro Padovani]

You’re right it seems so. For some reason I can’t get the bad deformations either. I could have sworn that it behaved differently before but I can’t reproduce the issue anymore. Thank you Thomas for the fast fix and for testing this.

Well if Luke has nothing to add I’d mark as resolved then.

[Luke Graybill]

Testing with 0896, and it seems like all the deformation issues have been resolved and the shapekeys (at least for lShin) are now correctly driven.

There is still some bone popping going on as I mentioned before, but maybe that’s unavoidable. As before, the problem occurs when starting from rest position with zero morphs, then rotating lShin by 155d on the local X (e.g., press r, x, x, 155), and then begin increasing Knees Up Left. The pop happens at a different (yet oddly similar) value from before, instead of Knees Up Left being at 0.062 when the leg pops forward, it's at 0.162 now. It feels like some axis flipping is happening, but I don’t know enough about rigging to figure it out. Still, I think it’s probably an acceptable caveat to say that applying morphs after a bone has already been posed is going to be unpredictable.

[Alessandro Padovani]

Luke, I believe the popping is due to the euler system but I see no way to stop it. So it works better if you use the body morphs first then adjust the pose.

Thomas, I got why it behaved differently for me before. I was rotating using the slider. If you rotate with the slider then “affect transform“ works fine, while if you rotate with the “r“ key you get the lock. Dunno why. This is just for information I now believe it is better to leave “affect transform“ off since the behavior seems the same.

‌

[Alessandro Padovani]

If nobody has anything to add I’ll mark as resolved. We have some popping but at least it’s better than nothing.

[Thomas Larsson]

The jump happens when the combined rotation goes beyond 180, to -180 which is the same thing. The limited rotation then jumps from +155 to -11. If this is a problem you can always disable rotation limits temporarily.

[Luke Graybill]

That’s interesting, it makes me wonder about the possibility of dynamically adjusting the rotation limit values on the fly as morphs are applied to offset from the morph bone positions. I’m not even sure if that’s possible within the limits of the blender API, as I’m just barely getting into bpy myself, but it’s an interesting thought.

[Alessandro Padovani]

I’m not a rig expert either but I don’t think this is a good idea. Changing limits on the fly I mean.

The behavior described by Thomas is typical of the euler system and causes gimbal locks and ik flipping in animation. Also, we get this behavior with just a single limit constraint, when we reach the top it flips to the bottom. I can’t fix it, tried with various combinations of order and owner and affect transform, seems a flaw in the limit constraint.

edit. Found this that explains things it seems a common issue in blender.

https://blender.stackexchange.com/questions/180503/armature-copy-rotation-weirdly-flips-the-direction

The issue is that Blender uses aliased versions of Euler angles for the copied and limited values. The solution is, don't use limit or copy rotation; use damped track and locked track, or use drivers. See devtalk.blender.org/t/… for a bit of discussion. 

– Nathan

‌

[Alessandro Padovani]

Thomas, let us know if you may want to play around with drivers instead of using constraints, as reported by Nathan. Otherwise I’ll mark as resolved. As damped and locked tracks are not useful in this case.

[Thomas Larsson]

I use damped track when I get to decide on the constraint type myself, e.g. in the mhx rig. However, this is not an option when a daz character is imported, since daz uses essentially copy and limit rotation (and translation). What I did was to add a new option that disables the limit constraints. This should behave like before, when the free bone is unlimited. The limit constraints are only muted, so they can be restored later.

This shouldn’t really be that much of a problem. If the combined rotation exceeds 180 you probably have other problems as well.

[Alessandro Padovani]

As for commit db46817 it doesn’t seem to work, that is, the limit constraints are not disabled here.

edit. note. It would also be useful if we can use “make all bones posable“ multiple times to switch the limits on and off as needed, if this is not already intended.

steps:

1. import g8f and merge rigs
2. make all bones posable with limits off

‌

[Luke Graybill]

Alessandro, I’ve noticed that the “Rotation Limits” checkbox in the addon’s Posing panel does work on these free bone limits too, unless you meant something more than that? Sorry if I misunderstood.

Also, may I suggest rewording this option, Thomas? “Enable rotation limits by default” is a little more descriptive and better matches the name of the button to use on the Posing panel to toggle them back on.

‌

Thirdly, I noticed that while unchecking that box does correctly disable the rotation limits as it suggests…

‌

… the “Rotation Limits” checkbox on the Posing panel is still erroneously checked, so one needs to toggle the button three times to actually enable the limits again:

‌

[Alessandro Padovani]

Nope, I mean that for me the new limit option in “make all bones posable“ doesn’t work, that is, it doesn’t disable the limits. If it works for you then could be something in the global settings. But I can’t see what, I have the limits enabled and the other options shouldn’t affect this.

‌

While the limit options in the posing panel work fine for me, that is, the checkbox is correctly switched and I don’t have to use it three times. Then, since there’s already limits for posing I believe the limits in “make all bones posable“ is unnecessary. We can switch the limits with the posing panel.

So Thomas we could just remove the new limit option in “make all bones posable“ and everything should be fine as before.

[Thomas Larsson]

The Limit buttons toggle the limit constraints of all bones, both those that have been duplicated and those that have not, because they were not driven in the first place. In the last commits I removed the option in Make All Bones Poseable, and instead use the global settings to determine whether the constraints should be enabled or not. Another change is that limit constraints are now always generated, but muted if the corresponding limit option is disabled. I suppose that a muted constraint does not affect performance, but it could be worth having the limits if you later decide to enable them.

[Alessandro Padovani]

Commit 4106583 works fine here.