Alt-I in 3D Viewport doesn't respect active keying set #88068

New Issue

Matthew Hinson · 2021-05-05T23:22:02+02:00

Matthew Hinson commented

2021-05-05 23:22:02 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: Radeon RX 580 Series ATI Technologies Inc. 4.5.13596 Core Profile Context 20.10.35.02 27.20.1034.6

Blender Version
Broken: version: 2.93.0 Beta, branch: master, commit date: 2021-05-04 20:58, hash: 96abe5ebbc
Worked: (unknown)

Short description of error
Unlike the "I" shortcut, which inserts keyframes for the active keying set, Alt-I always deletes (only) keyframes for the transform properties.

Exact steps for others to reproduce the error

Load the default startup scene.
In the Timeline editor, select the "Location & Rotation" keying set as the active one.
Select the default light and, with the cursor still in the 3D Viewport, press I. Blender creates Location and Rotation keyframes as expected.
Change the active keying set to "Location."
With the cursor in the 3D Viewport, press Alt-I and confirm. Blender deletes all keyframes including the Rotation ones, even though those aren't in the active keying set.
Clear the active keying set.
Rightclick on the light's "Power" property and choose "Add to Keying Set."
With the cursor in the 3D Viewport, press I. Blender creates a Power keyframe as expected.
Press Alt-I and confirm. Blender displays an error and the Power keyframe is not removed.

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: Radeon RX 580 Series ATI Technologies Inc. 4.5.13596 Core Profile Context 20.10.35.02 27.20.1034.6 **Blender Version** Broken: version: 2.93.0 Beta, branch: master, commit date: 2021-05-04 20:58, hash: `96abe5ebbc` Worked: (unknown) **Short description of error** Unlike the "I" shortcut, which inserts keyframes for the active keying set, Alt-I always deletes (only) keyframes for the transform properties. **Exact steps for others to reproduce the error** * Load the default startup scene. * In the Timeline editor, select the "Location & Rotation" keying set as the active one. * Select the default light and, with the cursor still in the 3D Viewport, press I. Blender creates Location and Rotation keyframes as expected. * Change the active keying set to "Location." * With the cursor in the 3D Viewport, press Alt-I and confirm. Blender deletes all keyframes including the Rotation ones, even though those aren't in the active keying set. * Clear the active keying set. * Rightclick on the light's "Power" property and choose "Add to Keying Set." * With the cursor in the 3D Viewport, press I. Blender creates a Power keyframe as expected. * Press Alt-I and confirm. Blender displays an error and the Power keyframe is not removed.

Matthew Hinson commented

2021-05-05 23:22:02 +02:00

Added subscriber: @Matthew-Hinson

Matthew Hinson commented

2021-05-05 23:28:54 +02:00

On a side note, I noticed that the confirmation message reads "Delete Keyframe" (singular) even though it presumably deletes multiple keyframes most of the time.

Philipp Oeser commented

2021-05-06 11:21:53 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-05-06 11:21:53 +02:00

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

Philipp Oeser commented

2021-05-06 11:21:53 +02:00

Can confirm.

It might be mandatory to split this in two reports [without looking at this in more depth it is not clear to me if this has the same roots].
But for now, will confirm both issues from the report desription.

Can confirm. It might be mandatory to split this in two reports [without looking at this in more depth it is not clear to me if this has the same roots]. But for now, will confirm both issues from the report desription.

James Partsafas commented

2021-05-07 20:25:46 +02:00

Added subscriber: @JamesThePlant

Wayde Moss commented

2021-05-13 20:13:02 +02:00

Added subscriber: @wbmoss_dev

Wayde Moss commented

2021-05-13 20:13:02 +02:00

According to the manual, the delete op isn't explicitly designed to take the keying set into account.

As for the Light Power delete failure, I'm not sure if it's a bug or not. Technically that's animation on the object's data but not the object itself. If it is a bug, then the proper solution is to walk through the object's data and check their animation data. Some data may also contain multiple references to other animatable id datas (materials, shapekeys, etc).

According to the manual, the delete op isn't explicitly designed to take the keying set into account. As for the Light Power delete failure, I'm not sure if it's a bug or not. Technically that's animation on the object's **data** but not the object itself. If it is a bug, then the proper solution is to walk through the object's data and check their animation data. Some data may also contain multiple references to other animatable id datas (materials, shapekeys, etc). ```

Sybren A. Stüvel commented

2021-05-14 10:18:18 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2021-05-14 10:18:18 +02:00

Changed status from 'Confirmed' to: 'Archived'

Sybren A. Stüvel closed this issue

2021-05-14 10:18:18 +02:00

Sybren A. Stüvel commented

2021-05-14 10:18:18 +02:00

In #88068#1156608, @Matthew-Hinson wrote:
On a side note, I noticed that the confirmation message reads "Delete Keyframe" (singular) even though it presumably deletes multiple keyframes most of the time.

This is an interesting linguistic puzzle. Technically, and as I look it, NO keyframe is deleted. A "keyframe" is "a frame that has one or more keys". After the operation the frame still exists, so it hasn't been deleted. The keys were removed, though. Pedantics aside, I think it's fine to keep naming the keys "keyframes" to differentiate from "shapekeys"; both could be (and are, in places) shorted to just "keys".

In #88068#1160433, @wbmoss_dev wrote:
According to the manual, the delete op isn't explicitly designed to take the keying set into account.

The code (see delete_key_v3d_exec()) also simply deletes all keys on the current frame from the active Action, with special handling for bones, where only selected bones are handled.

This means that Blender has been designed this way, and it's not a bug (i.e. there is no code that would handle keying sets here, but accidentally didn't get called for some reason).

> In #88068#1156608, @Matthew-Hinson wrote: > On a side note, I noticed that the confirmation message reads "Delete Keyframe" (singular) even though it presumably deletes multiple keyframes most of the time. This is an interesting linguistic puzzle. Technically, and as I look it, NO keyframe is deleted. A "keyframe" is "a frame that has one or more keys". After the operation the frame still exists, so it hasn't been deleted. The keys were removed, though. Pedantics aside, I think it's fine to keep naming the keys "keyframes" to differentiate from "shapekeys"; both could be (and are, in places) shorted to just "keys". > In #88068#1160433, @wbmoss_dev wrote: > According to the manual, the delete op isn't explicitly designed to take the keying set into account. The code (see `delete_key_v3d_exec()`) also simply deletes all keys on the current frame from the active Action, with special handling for bones, where only selected bones are handled. This means that Blender has been designed this way, and it's not a bug (i.e. there is no code that would handle keying sets here, but accidentally didn't get called for some reason).

Philipp Oeser commented

2021-05-14 10:27:43 +02:00

Cough, we should maybe be consistent and change this then (which explicitly mentions deleting):

RNA_def_property_ui_text(prop, "Active Keying Set", "Active Keying Set used to insert/delete keyframes");

Cough, we should maybe be consistent and change this then (which explicitly mentions **deleting**): ``` RNA_def_property_ui_text(prop, "Active Keying Set", "Active Keying Set used to insert/delete keyframes"); ```

Matthew Hinson commented

2021-05-14 10:32:07 +02:00

Personally I'd say that the manual should be descriptive of how Blender behaves, not prescriptive of how it's supposed to be behave. The software should evolve to do whatever makes the most sense, and the manual should follow - wouldn't you agree? And from my point as an (admittedly new) user, I felt it would make sense for keyframe deletion to be consistent with keyframe creation. If the "I" shortcut can create a Power keyframe, "Alt-I" should be able to delete it.

From a keying set point of view, shape keys, materials etc. appear to be treated in the same way as lights: the object data gets referenced directly instead of through an object, so that walking seems unnecessary. Instead, it seems sufficient to resolve the data Path based on the target data block.

Blender does have code to delete keys based on the active keying set (Timeline -> Keying -> Delete Keying-Set Keyframe). It's just that the Alt-I shortcut doesn't use this code, even though it would seemingly make sense for it to do so.

Personally I'd say that the manual should be descriptive of how Blender behaves, not prescriptive of how it's supposed to be behave. The software should evolve to do whatever makes the most sense, and the manual should follow - wouldn't you agree? And from my point as an (admittedly new) user, I felt it would make sense for keyframe deletion to be consistent with keyframe creation. If the "I" shortcut can create a Power keyframe, "Alt-I" should be able to delete it. From a keying set point of view, shape keys, materials etc. appear to be treated in the same way as lights: the object data gets referenced directly instead of through an object, so that walking seems unnecessary. Instead, it seems sufficient to resolve the data Path based on the target data block. ![image.png](https://archive.blender.org/developer/F10100510/image.png) Blender does have code to delete keys based on the active keying set (Timeline -> Keying -> Delete Keying-Set Keyframe). It's just that the Alt-I shortcut doesn't use this code, even though it would seemingly make sense for it to do so.

Philipp Oeser commented

2021-05-14 10:45:47 +02:00

Blender does have code to delete keys based on the active keying set (Timeline -> Keying -> Delete Keying-Set Keyframe). It's just that the Alt-I shortcut doesn't use this code

Oh, I wasnt aware there are multiple of these:
bpy.ops.anim.keyframe_delete
bpy.ops.anim.keyframe_delete_v3d

One takes a keyingset, the other one doesnt.

@Matthew-Hinson : what you can do of course is map {key Alt I} to the former, then you'll get the desired behavior

> Blender does have code to delete keys based on the active keying set (Timeline -> Keying -> Delete Keying-Set Keyframe). It's just that the Alt-I shortcut doesn't use this code Oh, I wasnt aware there are multiple of these: `bpy.ops.anim.keyframe_delete` `bpy.ops.anim.keyframe_delete_v3d` One takes a keyingset, the other one doesnt. @Matthew-Hinson : what you can do of course is map {key Alt I} to the former, then you'll get the desired behavior

Sybren A. Stüvel commented

2021-05-14 12:09:33 +02:00

In #88068#1160638, @Matthew-Hinson wrote:
Personally I'd say that the manual should be descriptive of how Blender behaves, not prescriptive of how it's supposed to be behave.

When there is a doubt whether something is "a bug" or simply "not designed very well according to our current view of things", looking at which behaviour is described in the manual can help.

The software should evolve to do whatever makes the most sense, and the manual should follow - wouldn't you agree?

Yes, but evolving software involves proper design. This is not the same as simply marking something that's currently unwanted as "bug" and hoping it gets "solved".

And from my point as an (admittedly new) user, I felt it would make sense for keyframe deletion to be consistent with keyframe creation. If the "I" shortcut can create a Power keyframe, "Alt-I" should be able to delete it.
Blender does have code to delete keys based on the active keying set (Timeline -> Keying -> Delete Keying-Set Keyframe). It's just that the Alt-I shortcut doesn't use this code, even though it would seemingly make sense for it to do so.

Yes, that makes total sense. That would be an improvement, but it's not seen as bugfix, hence shouldn't be handled in a bug report. I've put it on the agenda of the next Animation & Rigging module meeting so that it can be discussed.

> In #88068#1160638, @Matthew-Hinson wrote: > Personally I'd say that the manual should be descriptive of how Blender behaves, not prescriptive of how it's supposed to be behave. When there is a doubt whether something is "a bug" or simply "not designed very well according to our current view of things", looking at which behaviour is described in the manual can help. > The software should evolve to do whatever makes the most sense, and the manual should follow - wouldn't you agree? Yes, but evolving software involves proper design. This is not the same as simply marking something that's currently unwanted as "bug" and hoping it gets "solved". > And from my point as an (admittedly new) user, I felt it would make sense for keyframe deletion to be consistent with keyframe creation. If the "I" shortcut can create a Power keyframe, "Alt-I" should be able to delete it. > Blender does have code to delete keys based on the active keying set (Timeline -> Keying -> Delete Keying-Set Keyframe). It's just that the Alt-I shortcut doesn't use this code, even though it would seemingly make sense for it to do so. Yes, that makes total sense. That would be an improvement, but it's not seen as bugfix, hence shouldn't be handled in a bug report. I've put it on the agenda of [the next Animation & Rigging module meeting](https://devtalk.blender.org/t/2021-05-27-animation-rigging-module-meeting-upcoming/18846) so that it can be discussed.

Matthew Hinson commented

2021-05-14 14:43:35 +02:00

That's fair. Thanks for considering it!

Sybren A. Stüvel commented

2021-05-27 17:31:47 +02:00

Changed status from 'Archived' to: 'Confirmed'

Sybren A. Stüvel reopened this issue

2021-05-27 17:31:47 +02:00

Sybren A. Stüvel commented

2021-05-27 17:31:47 +02:00

This is discussed in the Animation & Rigging module meeting, and agreed that the way things work now are sub-optimal. This could be a nice thing to fix for a new developer.