pasting bone scale keyframes to frame 0 causes non-intended animation

[Daxel]

Moho 13.5.5. W10.

Today I wanted to modify a bone on frame 0 to be exactly like it was on frame 1. So I copy-pasted the bone keyframes from frame 1 to frame 0. This is something I have done a few times before with no problems, but this time the copy-pasted keyframes were bone scale keyframes. After doing that my rig was automatically changing from F0 to F1 with no keyframes on the timeline. After looking for problems on the smartbones, deleting actions etc I noticed it was that scale copy-paste what caused the problem.

Bones ignore the Scale property at frame 0. Not only you can't edit it, it is ignored. So if you copy-paste a scale keyframe of lets say "scale =0.5" from frame 1 to frame 0, and then you clear de animation, you will still see unintended animation from frame 0 to frame 1 caused by the scale property, that will be 0.5 on frame 0 and frame 1 but will be greyed out and ignored on frame 0 (so it will actually be 1 there) and on frame 1 it will be 0.5 and will start being aplied to the bone shortening it now to it's half. I hope I managed to explain it properly. It may be a little bit confusing.

I don't fully understand why this is like that, but it causes this problem and can be pretty confusing, hard to notice and of course unintended by the user. From my point of view (that could be missing a lot of under the hood crucial knowledge) it could make sense to make Moho automatically convert bone scale values to bone length values when these are copied to frame 0. That way copy pasting bone keyframes from any frame to 0 would have the intended outcome. If that is a bad idea for some reason, just not letting the user modify the scale value at frame 0 could be safer. Or letting the scale affect the bone at frame 0, but I guess that's not like that for a reason.

If you came here looking for a solution: just put the scale back at 1 on frame 0. You can't directly edit it, so create a bone scale keyframe on a different frame, like frame 1, modify it to be scale = 1 and paste that keyframe to 0.

[Greenlaw]

If I'm correctly understanding what you described, that should be normal behavior. Bone Length and Bone Scale are different things.

Bone Length defines the base size of the bone at frame zero. This number can't/shouldn't be changed on other frames.

Bone Scale is the size of the bone relative to the bone's length at frame zero. The scale value can be changed on an animation frame.

So, trying to copy the Bone Scale value to frame zero doesn't make sense because the Bone Scale is based on the Bone Length you set in frame zero; and changing the Bone Length at frame zero will certainly affect all the scaled results in later frames.

Normally you should set the bone length you need at frame zero before you begin animating the project. Changing the base size after the fact can be troublesome.

Or, just leave it alone. Since you're not rendering frame zero, it doesn't matter what frame zero looks like so long as the result is correct for frame 1 and later.

As a matter of fact, this can a valid technique: while frame zero is always the Setup frame, some animators like to think of frame 1 as the Preferred Pose frame. Chucky and I had a discussion about this a while back and we thought it would be great if there was an option in the Project Settings to open a project to frame 1 (the Pose frame) instead of frame 0 (the setup frame) because sometimes the setup frame needs its bones to be positioned or scaled in a awkward pose, and the artist may use frame one to pose the character in a more visually pleasing or useful pose. There should also be a similar option in the Preferences window to set the default choice for all new projects.

[synthsin75]

I know it may seem like a bug, but it is crucial to some rigging.
Frame zero won't display bone scale (it doesn't become bone length either). But if you're doing a perspective rig, you can use bone scale 0.01 (in frame one or copied to frame zero, so the rigging isn't accidentally deleted) and maximum IK stretching 100 to have bones that only shrink when their targets get closer.

[Daxel]

Thanks for the answers.

I am aware that bone length and scale are different things, I'm just pointing out that a user can copy-paste bone keyframes to frame 0 and that if those keyframes contain scale values they will cause the problem I described. The user will be confused, it will be hard to notice what is happening and the scale value can't even be reverted back to 1 to solve it, having to use the copy-pasting trick I described. Also the user won't be able to achieve what he was trying to do: to copy-paste a bone pose from some frame to frame 0. I know it is not a common operation but I find myself doing that sometimes when I reuse a body part and want to reposition it. I animate the bones on a later frame and then bake the drawing positions with a script and copy paste the bone pose. Posing it on frame 1 is easier but I usually preffer to have it like I want on frame 0 because I may need to make more changes and I want to edit things while they are positioned as I need them to be to see how they will look, specially if there's a big change in the pose.

[synthsin75]

Generally, you should probably only copy/paste a bone pose to frame one, or at least avoid pasting scale keyframes to frame zero. Since bone scale doesn't show on frame zero, it's useless, unless you're doing the perspective rigging I mentioned.

If things get weird, always check the bone's parameters with the transform bone tool.

[Greenlaw]

@Daxel,

Oooooh! Ok, I see what you mean now. After I clear the keyframes completely from the timeline, the changed bone length on frame 1 doesn't 'revert' to 1.0, which is what some users might expect. I guess I never paid attention to that before but I can see how this might confuse a new user, especially since the scaled value from frame 1 is visible in frame 0.

But I believe this is how it's supposed to work since you really can't change the scale of the bone at frame 0 (it's always 1.0 on frame 0 even when the box says otherwise.) You bring up a good point but, like Wes, I don't think this is a bug.

I wonder if the scale value at frame 0 should always say 1.0 even if the box is inactive and not editable there, and then show whatever the adjusted scale is at frame 1, keyframed or not? Or would that be more confusing?

[synthsin75]

Well, the bone is technically scaled on frame zero (and the transform bone tool shows the scale), even if it doesn't display on the bone itself. But frame zero is the bone's default...i.e. it's length. It would be really hard to allow changing both it's length and scale on frame zero...other than by pasting. But since the bone has to display it's length on frame zero, the pasted scale is just kind of "baked" into frame one, which protects it when you're using it for rigging.

There's really no other reason to paste a scale keyframe into frame zero. But keeping people from doing it by accident would also hinder a very useful rigging technique. Between protecting new users from errors and allowing advance rigging techniques, I always have to side with more flexibility.

An example of this is how Moho no longer natively allows you to create multiple shapes in the exact same curves. It's a very useful technique, and I had to write a tool mod to get it back, but it was changed because new users could accidentally stack too many shapes and cause bad aliasing in the render. Now, new users have to find that mod to do so.

[Daxel]

Yeah I didn't call it a bug (other than writing the post here) because I knew this was more like a collateral problem caused by an intended design.

I understand your point, Wes. I consider myself an advanced user, use a lot of scripts and tricks and I don't think Moho should be simplified at the cost of advanced features. Still, I think that it should avoid confusing and prone to error user actions. In my opinion, avoiding stacking shapes by default was a good decision. Not so much to not let advanced users stack shapes in some other built in way. A simple option in the create shape tool like "allow stacked shapes", unticked by default, would have been great.

Copy-pasting frames to 0 is a very simple action any user can do that, with this scale design, can easily cause a headache. I don't understand exactly what do you achieve with the technique you mentioned but I think the goal should be to solve the problem without stoping you from using that technique, if it's useful. I also proposed a "warning system" a few times like other programs have and think it would be a game changer for new and many times advanced users too, to make Moho friendlier to begginers, self explainable and less prone to error. A warning when you copy KFs that contain scale KFs to F0 would greatly improve the situation. The user would undo and live happily ever after, probably.

[Greenlaw]

The more I play around with this, the weirder it seems...particularly the part of copying the key at frame 1 to frame 0 to reset the inactive box in 0, just so I can delete the keys with the properly reset value. As you mentioned earlier, if this isn't reset, it affects later frames as if they still have a keyframe. I see what's going on but it's really weird.

Hmm. Not sure what to think about it. I'll mention it to the devs and then quietly walk away.

[Daxel]

Hmm. Not sure what to think about it. I'll mention it to the devs and then quietly walk away.

haha thank you.

[Víctor Paredes]

We have talked about this specific issue with Mike.
The idea of copying a scale value to frame zero can be confusing, but at the same time -and unintentionally- opens some possibilities that now are crucial for some rigs (just this week I animated a deer and a robot with this).
In the future, I would personally like to have an official feature to achieve this bone behavior, keeping the currently made rigs working, but stopping users to paste values they can't modify on frame zero.

[Víctor Paredes]

Here's an example of the technique described by Wes above:

[Daxel]

In the future, I would personally like to have an official feature to achieve this bone behavior, keeping the currently made rigs working, but stopping users to paste values they can't modify on frame zero.

That would be great! That deer is very nice by the way. I will try that technique when I have the time.

[Greenlaw]

Hi Victor,

Thanks for jumping in and clarifying whether this behavior was by design or a bug.

After seeing your example, I'm calling it an unintended feature!