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
4.1
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.
Remove built in keying sets
In order to reduce the list of options for keying, the choice of which channel gets keyed is moved to the user preferences. There will be a list of types that can be toggled on or off depending on what the user wants keyed.
Location
Rotation
Scale
Rotation Order
Custom Properties
BBone Shape
Custom keying sets are relative to the selection
A use case that was brought up was to automatically key the focal length of the camera in addition to its transforms. While custom keying sets have that power, they are bound to an ID. That means it will always key the same object, regardless of its selection or visibility state. It would be a lot more useful if the RNA paths were relative to the selection. So you could select camera A key transforms+focal length, then select camera B and do the same.
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.
Logic Diagrams
These diagrams do NOT show code structure. Rather they help to illustrate what is going to happen in various scenarios.
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.
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?
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).
Keying sets- get rid of the giant ASK-what to key menu, filter what gets keyframed, set up how it gets keyframed.
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
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.
i.e.
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.
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.)
Sorry I’m a bit late to the game here. But before we commit to a plan, I think it might be good to explicitly enumerate what key framing workflows (not features) we want to support. And then from there we can figure out what features/options we need for those workflows, how they should work, and where they should live. Right now I feel like the workflows are a bit implicit in the discussion, and I’m a little concerned that we might be overlooking some things because of that.
Some rough examples of workflows:
Animator always explicitly inserts keys, never uses auto-key.
Animator always uses auto-key, never explicit insertion, and expects anything manipulated to get keyed.
Animator explicitly sets keys to create new keys, and auto-key only modifies existing keys, never creates new keys.
Animator explicitly sets keys to create new f-curves, and auto-key only inserts/modifies keys on existing f-curves. (Or to generalize a bit more: animator specifies what controls and properties they want to be animated ahead of time, and then auto-keying sets keys on those things when they are manipulated, while other manipulations aren’t keyed.)
(These descriptions are almost certainly not detailed enough, but just to give an idea of what I mean by workflow. I’m also not suggesting that we should necessarily support all of the above workflows, nor that all workflows we should support are in that list—they’re just examples.)
Additionally, for the workflows we want to support, outlining the rationale and motivation for each is also probably be a good idea. I don’t mean in the sense of “prove that your workflow deserves to be supported!” I mean to better inform how the features we derive from them should fit together.
I can write up a few examples, but the idea was that the diagrams encapsulate what is possible.
All workflows will be a specific way through that graph. The reason for the diagram as opposed to writing it out is that I felt the image is a lot easier to understand.
Oh, don’t get me wrong, you’re doing awesome work! I think the diagrams are great. But the diagrams are more feature-oriented. That’s great as a kind of specification of how things should work.
But I think it would be good to also be explicit about the workflows we’re trying to enable with that functionality, and what those workflows are for, so we can be confident we’re not accidentally precluding a desired/useful workflow with the design.
I’m also happy to help writing those up. I had a discussion with the studio animators recently that touched on some of this, so some of it is fresh in my mind.
maybe I misunderstood, you are saying I should write a few user stories that explain how people are expected to work with that system. Not necessarily all of them. At the end of the day, people will use the system in all possible ways
