Page MenuHome

Propagate Pose, Next Keyframe
Confirmed, NormalPublicBUG

Description

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 461.40

Blender Version
Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-03-24 17:47, hash: rB9ac7946dd03f
also 2.92

Propagate pose not affective for mode 'Next Keyframe'. It works for other modes however.

steps:
create a bone with two keyframes, with playhead on first frame, alt-P > 'To Next Keyframe'.

thanks

Event Timeline

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Fri, Apr 16, 11:51 AM
Philipp Oeser (lichtwerk) claimed this task.
Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".

Yep, there seems to be a bit of a hickup.
If you are on one keyframe on the current frame, this will actually be keyed as well (see comment below).
Logic then fails to proceed to the next, fix should be incoming shortly.

/* find the first keyframe to start propagating from
 * - if there's a keyframe on the current frame, we probably want to save this value there too
 *   since it may be as of yet unkeyed
 * - if starting before the starting frame, don't touch the key, as it may have had some valid
 *   values
 * - if only doing selected keyframes, start from the first one
 */

Note the above code comment actually contradicts the documentation in https://docs.blender.org/manual/en/dev/animation/armatures/posing/editing/propagate.html

To Next Keyframe

Simply copies the pose to the first keyframe after (but not including any keyframe on) the current frame.

So question is: what is the desired behavior if current frame already has a keyframe:

  • [1] key here and the next keyframe
  • [2] only key the next keyframe

I feel that the documented behaviour (so option 2) is the sensible one. Copying the current frame to the current frame is rather useless.

One question - does it copy the current values, or the current keys? If I have a key on the rx on this frame, but not ry... and I propogate the POSE.. I would expect the values of both rx and ry to be placed on the next keyed frame... for both attributes.

For example,

if I'm on frame 104 and I have these keys...

Attribute101102103[104]105106107108109110
RX0.01.53
RY0.01.2.5

and I propogate the pose to the next key, I would expect to now have something like:

example:

Attribute101102103[104]105106107108109110
RX0.01.51.5
RY0.01.21.1.5

It would take the interpolated value of RY on 104 and copy that to 108.. but not set a key at 104 for RY.

Does that make sense?

@Jason schleifer (jasonschleifer) that makes total sense. What I'm arguing against is to let Blender do this in your example:

Attribute101102103[104]105106107108109110
RX0.01.53
RY0.01.21.1.5

What Blender actually does now in this example also seems a bit useless to me:

Attribute101102103[104]105106107108109110
RX0.01.53
RY0.01.21.1

It is a very literal interpretation, though. It takes the current value of each property, and copies it to the next keyframe of that particular curve, where "next" is "the current key" if it exists.

I think I know why Blender currently behaves the way it does, because this way it can be implemented for each curve individually, making it easy to build. Propagating to the next keyframe this way won't actually create new keys, which kind of makes sense in a technical way. It makes little sense to me from an animator's point of view though. I don't think you'd ever want to have the current pose spread over different frames.

From the source:

* - if there's a keyframe on the current frame, we probably want to save this value there too
*   since it may be as of yet unkeyed

This is something to decide. Personally I think "propagate to the next key" should not touch anything except "the next key". If you want to modify the "current key", just key the value.

* - if starting before the starting frame, don't touch the key, as it may have had some valid
*   values

I don't know what this means, or why "it may have had smoe valid values" wouldn't apply to any other key. This point could just as well be used to counter the first point.

* - if only doing selected keyframes, start from the first one

This doesn't convey much either. You always start from "the first one" -- either the first key of the curve or the first selected key.
It does raise the question how to deal with key selection, though. Since this is an operator you'd run from the 3D Viewport, I'd say let's ignore key selection in the graph editor, and act on the FCurves that correspond to the selected bones.

@Jason schleifer (jasonschleifer) that makes total sense. What I'm arguing against is to let Blender do this in your example:

Would think so, too [dont create a new keyframe here]

I don't think you'd ever want to have the current pose spread over different frames.

Not sure reading the commit message of rBeef811a0954a: Animation Tool: Propagate Pose:

This tool automates the process of copying a pose to successive
keyframes, making it easier for animators to go back and change the
pose for some controls which remain "static" for periods of time.
Previously, animators would need to do a "{Ctrl-Pageup Ctrl-V} *
number_of_static_keyframes" dance for each set of controls that this
happened on, which is not too good ergonomically speaking.

From the source:

* - if there's a keyframe on the current frame, we probably want to save this value there too
*   since it may be as of yet unkeyed

This is something to decide. Personally I think "propagate to the next key" should not touch anything except "the next key". If you want to modify the "current key", just key the value.

Think in the light of Joshuas commit message (having this used for "holding" / "static" periods) dropping the key on the current frame (if there already was one, you changed the pose but still unkeyed) plus copy to the next might actually make sense as convenience [though of course, you could just key "by hand" - requiring an additional click though].

Still thinking about the cases of pushing the 1.1 to either frame 108 or frame 110...

I don't think you'd ever want to have the current pose spread over different frames.

@Sybren A. Stüvel (sybren): I think I might have misread your comment, if this is about the pose of frame 104 ending up spread across 108 and 110 in our example then yes, I too think that this is probably not desired in the majority of cases.
As you said, this would require changing the operator to insert new keyframes though, raising the code complexity which should be fine though.