Propagate Pose, Next Keyframe #87548

New Issue

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: 9ac7946dd0
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

#87548-propagate-pose-next.blend

**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: `9ac7946dd0` 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 [#87548-propagate-pose-next.blend](https://archive.blender.org/developer/F9985968/T87548-propagate-pose-next.blend)

Added subscriber: @OtherRealms

Added subscriber: @lichtwerk

Changed status from 'Needs Triage' to: 'Confirmed'

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
   */

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.

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:

- key here and the next keyframe
- only key the next keyframe

So question is: what is the desired behavior if current frame already has a keyframe: - - [x] key here and the next keyframe - - [x] only key the next keyframe

Added subscriber: @dr.sybren

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

Added subscriber: @JasonSchleifer

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...

Attribute	101	102	103	[104]	105	106	107	108	109	110
RX	0.0			1.5				3
RY	0.0		1.2							.5

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

example:

Attribute	101	102	103	[104]	105	106	107	108	109	110
RX	0.0			1.5				1.5
RY	0.0		1.2					1.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?

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... | Attribute | 101 | 102 | 103 | [104] | 105 | 106 | 107 | 108 | 109 |110| | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |-----| |RX| 0.0 | | |1.5 | | | | 3 | | | |RY| 0.0 | |1.2 | | | | | | |.5 | and I propogate the pose to the next key, I would expect to now have something like: example: | Attribute | 101 | 102 | 103 | [104] | 105 | 106 | 107 | *108* | 109 |110| | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |-----| |RX| 0.0 | | |1.5 | | | | *1.5* | | | |RY| 0.0 | |1.2 | | | | | *1.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?

@JasonSchleifer that makes total sense. What I'm arguing against is to let Blender do this in your example:

Attribute	101	102	103	[104]	105	106	107	108	109	110
RX	0.0			1.5				3
RY	0.0		1.2	1.1						.5

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

Attribute	101	102	103	[104]	105	106	107	108	109	110
RX	0.0			1.5				3
RY	0.0		1.2							1.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.

@JasonSchleifer that makes total sense. What I'm arguing **against** is to let Blender do this in your example: | Attribute | 101 | 102 | 103 | [104] | 105 | 106 | 107 | *108* | 109 |110| | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |-----| |RX| 0.0 | | |*1.5* | | | | *3* | | | |RY| 0.0 | |1.2 | *1.1*| | | | | |.5 | What Blender actually does now in this example also seems a bit useless to me: | Attribute | 101 | 102 | 103 | [104] | 105 | 106 | 107 | 108 | 109 |110| | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |-----| |RX| 0.0 | | | *1.5* | | | | 3 | | | |RY| 0.0 | | 1.2 | | | | | | | *1.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.

In #87548#1148562, @dr.sybren wrote:
@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 eef811a095:

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...

> In #87548#1148562, @dr.sybren wrote: > @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 eef811a095: ``` 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.

@dr.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.

> I don't think you'd ever want to have the current pose spread over different frames. @dr.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.

Looks like I wont have time for this short-term, will step down to not block others.
Since this also involves a design on how this should work eventually [and we are already a good way into the process], will set subtype accordingly.

Looks like I wont have time for this short-term, will step down to not block others. Since this also involves a design on how this should work eventually [and we are already a good way into the process], will set subtype accordingly.

Added subscriber: @BClark

This issue was referenced by 200a114e15

This issue was referenced by 200a114e159695760cb5cb1d87fc5790b718971d

Changed status from 'Confirmed' to: 'Resolved'

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Propagate Pose, Next Keyframe #87548