Dynamic bones aren't working

[Hugging_Bear]

Hi Guys,
I face another problem. The dynamic bones stopped working. Please watch https://youtu.be/f2XjKj9rOlI
I also have uploaded my project file here https://mega.nz/file/AOkX0QJI#tNNsnzBtg ... pJ_lvKJcXo
CORRECTION: I meant to say 'I deleted all keyframes (not bones) from the dynamic bones timeline'.

Thanks for your help!

[Víctor Paredes]

Hello. I checked the file and on frame one of every action the bones have Rotation keyframes, plus layer Translation, layer Scale and layer Rotation keyframes.
Having unrelated keyframes inside of the action can generate conflicts for the rig.
This can include problems with Dynamics. Deleting those frame 1 keyframes on all the actions fixes it.

[Greenlaw]

Just adding to Victor's comments...

Keyframes in Smart Bone Actions tend to override the mainline, which is something to be aware of when rigging. For example, I avoid using Animated Layer Order inside a Smart Bone Action because, in practice, there's a high chance I'll want to make edits or modifications that fall outside the range of what the Smart Bone will allow. (BTW, there are other ways to get the same effect in a Smart Bone Action without using Animated Layer Order.)

So, how does unintentional keyframing occur? Inside a Smart Bone Action, there's a good chance you accidentally clicked on a bone while all bones were selected, which will keyframe everything. Everyone occasionally makes this error, and a skilled user just learns to be careful about it.

Another way this happens is if you have Auto-Freeze Keys enabled. This option can be useful in certain situations, but I keep it off most of the time because if I'm not careful, it can quickly degrade the performance of a rig by generating too many unnecessary keyframes. (TBH, I don't remember the last time I needed this option enabled.)

Hope this helps.

[Hugging_Bear]

Hello. I checked the file and on frame one of every action the bones have Rotation keyframes, plus layer Translation, layer Scale and layer Rotation keyframes.
Having unrelated keyframes inside of the action can generate conflicts for the rig.
This can include problems with Dynamics. Deleting those frame 1 keyframes on all the actions fixes it.

Hi Victor,
thanks for checking my project file. I can tell you, how this happened! Whenever I start animating an action/smart bone I select add keyframe from the Animation tab. This automatically also creates those pesky layer Translation/Scale/Rotation keyframes. Well, in future I'll delete those right away. But I don't quite understand how those smart bone actions can influence the bone dynamics. Those are completely different bones.
I also think, the program shouldn't allow users to create keyframes on dynamic bones (which will happen most likely by accident). If a user wants to change dynamic bones back to plain vanilla bones, he or she can do so by unticking/unchecking the box in the 'Bone Constrains' Tab. Maybe a 'reset' button would also be helpful, forcing the movements of the dynamic bones to be recalculated by the program. Those are just suggestions.
Thanks again for checking!

PS: I've just deleted those layer Translation/Scale/Rotation keyframes from my actions/smart bones. It has NO effect whatsoever on the bone dynamics!!! In other words they are still NOT working.

[Hugging_Bear]

Just adding to Victor's comments...

Keyframes in Smart Bone Actions tend to override the mainline, which is something to be aware of when rigging. For example, I avoid using Animated Layer Order inside a Smart Bone Action because, in practice, there's a high chance I'll want to make edits or modifications that fall outside the range of what the Smart Bone will allow. (BTW, there are other ways to get the same effect in a Smart Bone Action without using Animated Layer Order.)

So, how does unintentional keyframing occur? Inside a Smart Bone Action, there's a good chance you accidentally clicked on a bone while all bones were selected, which will keyframe everything. Everyone occasionally makes this error, and a skilled user just learns to be careful about it.

Another way this happens is if you have Auto-Freeze Keys enabled. This option can be useful in certain situations, but I keep it off most of the time because if I'm not careful, it can quickly degrade the performance of a rig by generating too many unnecessary keyframes. (TBH, I don't remember the last time I needed this option enabled.)

Hope this helps.

Hi Greenlaw,
thank you for your feedback. I'm not sure what you mean by 'Animated Layer Order'!? Is this a fancy way to say that someone created layer Translation/Scale/Rotation keyframes? I explained to Victor how this accidentally happened (by clicking an the 'Add Keyframe' option in the Animation tab. But deleting those keyframes didn't bring my bone dynamics back

[Greenlaw]

Is this a fancy way to say that someone created layer Translation/Scale/Rotation keyframes?\

Nah, I only meant that it's easy to limit or even lock up a rig with Smart Bones when there are any keys there that can override or conflict with what you want to do on the Mainline. Animated Layer Order was just an example; some users will try using this in a Smart Bone Action only to find it can limit things when they want to go beyond what the action allows. You can ignore what I said with this example if it's just confusing the matter.

Anyway, check your Smart Bones carefully because in some situations the unintended keyframes may be found in an unexpected place.

If you're certain there are no unintended keyframes, it could be that the action or project is actually broken. This is pretty rare but I've seen it happen. When I run into this, I first try importing items from the broken project to a new project and sometimes this will clear up the issue.

If this doesn't work, I'll take a deep breath and rebuild the broken parts in a new action...sometimes that winds up being faster than trying to fix a broken action. If you do this, be sure to completely remove the existing action, save, and then quit and restart Moho. This is to make sure any 'junk data' remaining in memory is gone and doesn't affect the new action.

[SimplSam]

PS: I've just deleted those layer Translation/Scale/Rotation keyframes from my actions/smart bones. It has NO effect whatsoever on the bone dynamics!!! In other words they are still NOT working.

I just tried removing the dynamic Bones 'Rotation keyframes' in the Actions and their dynamics are now working.

For reference: I selected all/only the dynamic bones. Edited each Action, and removed all Red/Selected channel keys

As intimated by Greenlaw - Deleting and recreating those dynamic bones, or actions would also resolve.

[Greenlaw]

What SimplSam wrote reminded me of something else to be aware of: changing the parenting of control bones can break a Smart Bone Action if the new parent has a different rotation value. What happens in this case is that the rotation value of the dial itself changes, and the range may become invalid. I don't think this is what happened in your case, but it's something else that can 'lock' a rig.

Fixing it is usually easy: just delete all the rotation keys and re-key them to the correct values--this is easier than unwinding the bones to the correct values.

To prevent it, I parent all my Smart Bones (the dials, not the ones inside a skeleton) to a common 'SBD' (Smart Bone Dials) bone. This gives me a handle to move all the Smart Bones at

Then, the SBD bone is parented to the character, so it moves with the character. This also prevents the 'broken' dial problem when I need to parent the controls to move with the character.

Bonus Tip: if you decided to parent your SBDs to a character, parent the SBD bone to a child bone branching from the root bone of the character, and set the child to have Independent Angle. This way, the SBD bones will follow the character as it's moved, but the z-rotation of the character will not affect the SDBs as a group. This makes it much easier to animate a character, even when it flips completely upside-down.

Hope this helps.