Keyframing, Auto Keyframing and Keying Sets

This thread should be a jumping off point to design a more coherent and predictable keying system.

Current Issues


Less confusing for users

Judging from the bug reports there are combinations of settings that have unexpected outcomes for the user. This should be cleared up or made to work as expected.

More configurable

Currently keying sets are hardcoded and while you can add them it’s not a straightforward process.

Compatible with animation layers

With the upcoming changes to the animation datastructure it is important that keying sets are kept in mind. A potential use case is for example to automatically split up keyframes onto a body and a face layer.

Target Version


Questions for the community

  • what is the intended use case of keying sets in your opinion. What do you expect to happen when you enable one. Key a set of objects, or a set of channels or both or neither?
  • What are your issues with the current keying system

Proposed Changes

Separate Keying Set responsibilities

Currently a keying set defines three things:

  • which channels get a key

  • which objects get keyed (Whole Character)

  • what value that key has (visual keying)

I think this would be best split up to reduce the amount of keying sets needed. Keying sets would only be responsible for defining which channels get keyed. The key value would then be determined by a separate mode flag/enum.

Which objects get keyed are defined by the selection. This might be controversial and I’d love to hear opinions on it, but with bone groups and quick select sets this shouldn’t be too slow while a lot more precise. (Or maybe it should be possible to specify a bone collection + a keying set?)

Never Key Locked Channels

In a production environment the rigger locks channels that he/she doesn’t want the animator to be able to change. Currently keyframing still allows adding keyframes to locked channels, effectively being able to animate them. Even if this is done by accident and the animator has no intention to animate the locked channels it still creates a lot of unnecessary data that also slows down Blender.

As an extension to that Custom Properties should be lockable.


If Selection Sets are indeed becoming a thing and we would be able to store multiple sets of object / bone selections I would like the splitting too. But what I would do is introduce “Selection” picker in the keying sets. Which would work kinda similar to how modifiers work with vertex groups - If it’s empty and has no input - key selected objects, whether single or multiple. If it has selection set specified, then key objects/bones in selection set.

I had a similar thought yesterday after I posted this
At the moment it is not clear to me what the intention of keying sets is.
Does it

  • only define which channels to key
  • or also define which objects to key
  • and if it keys objects does it key them even if they are hidden

I think it would be great to find the intended use case, that will make it a lot easier to decide what needs to change

In my opinion keying sets should be only for specifying channels. For specifying objects we could use selection sets, because that is something you want additionally, but not always. For example in mograph with hundreds of objects you’d probably not use it, but for character animation you would.

As for hidden objects and channels i’m not eure either. I can see use for either cases. So if possible probably setting in the preferences would be the best

I’ve never found any benefit from using keying sets, but I have very frequently encountered issues when a keying set isn’t what I expect or want. It would bring me an endless amount of joy if key sets were removed, they are an unnecessary and error-prone complication

Maybe it’s worth framing this as a distinction between a rig specifying which channels can be edited and keyed, and then the subset of those that the animator wants to edit and key at a given time.

Taking into account locked channels is one part of the rig specifying what should be edited and keyed. The Whole Character keying set mechanism help specify what should be be keyed, and maybe should be always on, with a distinct way for animators to indicate which subset of those channels they want to key now. For example an animator might want to animate the body but keep the facial expressions fixed initially.

In an IK/FK switching setup or an ephemeral rigging setup, the rig might also know which channels should be edited and keyed, and where visual keying should be used. Maybe there is some way that the rig could specify this dynamically so the animator doesn’t have to think about it, but how and how well this would work is not trivial to figure out.

I personally never quite understood why you might want to select one of location / rotation / scale in keying sets. I would think that for an animator you mainly want to think about body parts or different objects. Or do a bunch of edits that you don’t want to keyframe, and then do a bunch of other edits that you do want to keyframe. But not so much have to think in advance what the appropriate channels are for that.

In my opinion, when auto-keying is behaving better than it now does, you should not have to specify a keying set.(only insert needed is conflicting with ‘only insert available’ at the moment, causing unexpected behavior when both turned on). I made a proposal a long time ago on ‘rightclickselect’ for better behavior for autokeying:

It’s probably outdated for what you are thinking about Christoph, but it might help.

I mapped out a basic version of keying of what issues I encountered and what i would expect from autokeying.


In terms of channels there is not much the rig can specify, but if the keying set takes a bone collection, they could be provided by the rigger. What I want to avoid is making assumptions about the rig setup or the animator workflow. Some configuring work will always be left to the user.

Is the conflict between “only insert needed” and “only insert available” your only issue with autokeying?

1 Like

Thank you for looking into this topic!

It always confused me that there is a hard cut between “absolute keying sets” and “python keying sets” with little overlap in features.

While there’s a lot of UI for creating the former in the Scene properties, it only allows for keying one specific object. Rarely useful in my experience, since I needed custom keying sets that work for multiple objects that have similar structure.
On the other hand, creating your own keying set using python allows for more advanced stuff like taking the selected objects into account, but then requires writing code to set this up properly.
Is it planned to deprecate the old keying set system, or to extend it and update it?

I would wish the UI allowed you to create something like “relative keying sets” that use an RNA path to determine the full keying path (including allowing bpy.context variables - maybe extending this system of drivers?). Sample use case: animating selected camera objects + FoV & DoF settings directly, without a rig.

For armatures, bone collections make a lot of sense to me here (especially since library overrides can add new ones now), should be part of this UI as well. Or maybe the other way around - in armature options, marking a bone collection as a keying set?

There is existing control in terms of the Whole Character bone name conventions. Instead you could imagine bones having a property indicate if they should be keyable or even use visual keyframes. And that property could potentially be driven or updated through Python based on the state of IK/FK switching.

I don’t know that this is actually a good idea, just throwing it out there. And it goes into the design of how IK/FK switching and ephemeral rigging would integrate as a whole. Since it’s not really just about keying but also which bones the user should be editing based on the state.


When autokeying would ‘only key if changed’. I would not have to specify any keying since i’m aware of what i am changing. I.E. When only translating an object with autokey turned on. I would expect those channels to get a key. Then i don’t need to specify ‘translate’ when setting a key.

The issue is that ‘only insert needed’ doesn’t have this behavior. Btw I’m happy to elaborate in a google meet if that makes it easier to discuss (on monday).

Posting this here also

Custom keyfsets allow for keying a group of properties that can be animated but the existing animation tools don’t allow unless you use something like animall to keyframe verts, or physics properties or things that just fall out side of what gets keyframed.

Selection related, having a keyset per rig pat, IK?FK leg etc… could help make sure all parts of the rig that need keys get them

  • current whole character keying set- name based built for blender studio movie, cc Nathan Vegdahl and built around how Nate rigged at the time but then get created and left as “standard” but isn’t really whole character

  • and as a selection method Aligorith's Lair: GSoC11 - Select Grouped by Keying Set

1 Like

ah good glad you posted!! After you showed me what it was doing, I haven’t been able to get over how frustrating it was.

1 Like

Adding comments from Blender Chat here so they don’t get lost

From @JerBot

Been awhile… and not a full-time Blender animator… BUuUUUuuuu…

…for complex characters, I use keying sets to isolate areas that I’m focused on, and gives me a hotkey to key everything within that context.


If I’m animating the upper torso of a character, I might have a keying set for each arm, one for the head and one for spine. So when I’m tweaking arm, hand and wrist, I can tap a hotkey and all the bones of the (active) arm’s keying set are keyed. Fast way to work without leaning on auto-keying, having to manually key each bone as I do the adjustments, or dumping keys on the entire body.

Potentially also helpful in using keying sets as selection sets to jump to specific bones for manipulation… though haven’t ever tested this potential in Blender (does it exist?).

related / off topic (but perhaps the analogy helps): I used to skin like this in the past (when I had the tools). Isolating and locking weights for all areas of a mesh that I’m not focused on. This way I could paint, flood and adjust… knowing I wasn’t breaking other areas of the skinned mesh/body while I was focused in a certain area.

And yes, being able to filter keying by channel would be handy. i.e. if working in FK and animating an arm… no point in keying translation… though typically this stuff is managed by the rig, where translations would be locked / unkeyable on an FK chain. But yeah… again… it’s been awhile and my animation in Blender is usually pretty basic/focused.

From @Cessen

Yeah, the “Whole Character” keying set was built specifically for production on Sintel, and was based on the bone naming scheme we used for those rigs (e.g. “MCH-”, “DEF-” etc. prefixes). For some reason it ended up being a default available keying set in Blender, which in retrospect doesn’t make much sense since it doesn’t work properly for any rig that doesn’t follow Sintel’s naming scheme exactly.

(Notably, Rigify also follows that naming scheme, since it also came from Sintel production originally, so “Whole Character” works with Rigify rigs. But Rigify is just one of many valid approaches to build rigs.)


thats exactly how it should work!

1 Like