Page MenuHome

KeyFrame Types redesign
Needs Triage, NormalPublicDESIGN


First of all lets think about what keyframe types are and what is their function:

The objective of having a sort of "tagging" system for keyframes is to be able to glance at them so when you need to select them it's easier to know what is what.

What is the current state:

We have 5 keyframe types to chose from: Keyframe, Breakdown, Moving Hold, Extreme, Jitter,
with 4 of them having different colors and 2 having very similar colors (keyframe and moving hold), adding to that Jitter and Breakdown are slightly smaller and extreme being slightly bigger.

The problems with the current design:

  1. As you can in the following picture, when the keyframes are unselected the colos are so simiar different enough that it's hard to tell what is what which fights the main "objective" of having keyframe types which is being able to understand roughly what is going on with a glance.

  1. Secondly they have been named with specific character animation terms which is understandable but not universal enough and not easy to communicate with:

example use: If i tell you: "select the keyframe keyframe?" you wouldnt understand, if i tell you "move the moving hold keyframe" you'd probably have to go and look up what type is the "moving hold" type and then find it.

  1. Also being called type implies that it does something different, and as the zen of pythin says: "explicit is better than implicit"
  1. Currently that's it, but an other problem with this is the missed pportunity of being able to do things like selecting all the keyframe keyframes, or selecting all the jitter keyframes (or deselecting them) performing action on this keyframe groups.
  1. Under the keyframe popover there is a menu to define what is the new keyframe types, so if i create a new keyframe with the extreme option selected it will create them all "extreme" but if there is a keyframe already where i'm standing with the playhead then it only affects new keyframes does not replace the type to the keyframes that are already there.

Proposed Solutions: General Outline of the Tasks to be Created

  1. Change name from "Keyframe Type" to "Keyframe Color".
  1. Use the same colour palette that Nate Craddock proposed for the outliner colours: Red, Orange, Yellow, Green, Cyan, Purple, Gray, Brown.
    • as stated we could potentially create a selection of colors that can work also for colorblindness --, but as far as I'm concerned 5 colors is more than enough.
  1. Name the keyframe colour according to the color "the red keyframe is called red"
  1. Unify the selection colour, whenever the keyframes are selected they'll go White-

This particular point as has a downside which is not being able to recognise they keyframe colour when they are selected, but I think it's good compromise because normally you want to know before you select them, after you select them it's usually fine. --, on the other hand and option would to highlight the keyframes by keeping the same colour but drawing a White outline in the selected ones.

Now here are 2 ideas on how to implement this:

The colors displayed in these examples are orange for selected but not active and white for selected and active as it happens in the graph editor and edit mode of object to make selection states coherent with the rest of blender.

in this one we make the interior of the key frame the desired color and the outline will change acording to selection, this will allow to easily maintain the colors even if the selection state changes but will still be clear, the downside to this option is that the key color becomes the most important thing visually.

In this second example the key color is the outline and the interior is the selection state, I personally think that this may be the better way to go as it still more important to see what is unselected/selected/active

  1. Implement "Select Grouped" menu with a "By color" ->
  1. Make the "new keyframe type" option also replace whatever keyfame is being modified with the new one (this could be a tickbox for the desired behaviour)

Obviously this is all open for discussion but based on the feedback from it seems pretty well accepted.

Event Timeline

perhaps adding a way to make custom keyframe types and colors, and changing the proposed colors and giving them a name

@Hossam Eddine (arrow_x86) the idea is to keep it as simple as possible so it becomes a common language, like move the red key or do this to the blue key.

I'd argue that more than 5-8 color types would be too many as you start having to go for shades of color and then they start becoming hardly distinguishable, but having an option to rename them in the "themes" would be okay.

I like the outline = keyframe color rather than than the outline = selection state (idea 2) a bit better as I'm more interested in selection state usually. Other than that I don't have very strong feelings about this proposal, it would need to be coordinated with grease pencil though; right now the interpolation tool creates breakdown frames, and you can delete breakdowns preferentially - I much prefer the "delete breakdowns" to "delete blue frames" and there's a consistency there.
Should we:
Keep breakdowns in Grease pencil, but replace everything else with these colors?
Or something else? I wouldn't want to lose that functionality/simplicity. Thoughts?

Sybren A. Stüvel (sybren) renamed this task from KeyFrame Types redesign. to KeyFrame Types redesign.Mar 4 2021, 5:08 PM

Ok, from a chat on, here is a proposal that could make Luciano's idea work.

1- keyframe colors are tags, they don't exist until the user creates them
2- by default, the tags are color+color name e.g. blue keyframes being called 'blue'. Users can pick colors from a smallish list, and rename the default names
3- before using interpolate sequence in grease pencil there are no keyframe tags
4- the first time interpolate sequence is used the tag 'breakdown' with a blue color is created and assigned to breakdown keyframes

I can elaborate further if this isn't clear. I'm not 100% sure this is something I would prioritize, but it would need to not hurt the functionality in grease pencil. (that's my concern)