Page MenuHome

Alt-I in 3D Viewport doesn't respect active keying set
Closed, ResolvedPublicKNOWN ISSUE

Description

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

Event Timeline

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 (lichtwerk) changed the task status from Needs Triage to Confirmed.May 6 2021, 11:21 AM

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.

Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Bug".May 6 2021, 11:37 AM

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

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

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

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");

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.

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 (arc_) : what you can do of course is map Alt+I to the former, then you'll get the desired behavior

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.

That's fair. Thanks for considering it!

Sybren A. Stüvel (sybren) reopened this task as Confirmed.Thu, May 27, 5:31 PM
Sybren A. Stüvel (sybren) triaged this task as Low priority.
Sybren A. Stüvel (sybren) changed the subtype of this task from "Bug" to "Known Issue".
Sybren A. Stüvel (sybren) added a project: Restricted Project.

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.