KeyFrame Types redesign #79857

Open
opened 2020-08-17 20:35:35 +02:00 by Luciano Muñoz Sessarego · 12 comments

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.

2020-08-17 18_40_33-Blender_ [E__Dropbox_005_Gumroad_Beefy_2.8_walk_002.blend].png

  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.

  2. Also being called type implies that it does something different, and as the zen of pythin says: "explicit is better than implicit"

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

  4. 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.
    2020-08-17 19_16_49-Microsoft Store.png

Proposed Solutions: General Outline of the Tasks to be Created

  1. Change name from "Keyframe Type" to "Keyframe Color".

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

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

image.png
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.

image.png
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" -> https://developer.blender.org/T86180

  2. 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 blender.chat it seems pretty well accepted.

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. ![2020-08-17 18_40_33-Blender_ [E__Dropbox_005_Gumroad_Beefy_2.8_walk_002.blend].png](https://archive.blender.org/developer/F8788785/2020-08-17_18_40_33-Blender___E__Dropbox_005_Gumroad_Beefy_2.8_walk_002.blend_.png) 2. 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. 3. Also being called type implies that it does something different, and as the zen of pythin says: "explicit is better than implicit" 4. 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. 5. 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. ![2020-08-17 19_16_49-Microsoft Store.png](https://archive.blender.org/developer/F8788907/2020-08-17_19_16_49-Microsoft_Store.png) Proposed Solutions: **General Outline of the Tasks to be Created** 1. Change name from "Keyframe Type" to "Keyframe Color". 2. 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. 3. Name the keyframe colour according to the color "the red keyframe is called red" 4. 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. ![image.png](https://archive.blender.org/developer/F9860663/image.png) 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. ![image.png](https://archive.blender.org/developer/F9860666/image.png) 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 5. Implement "Select Grouped" menu with a "By color" -> https://developer.blender.org/T86180 6. 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 blender.chat it seems pretty well accepted.
Author
Member

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

Added subscriber: @arrow_x86

Added subscriber: @arrow_x86

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

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

Added subscriber: @RedMser

Added subscriber: @RedMser
Author
Member

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

@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.
Member

Added subscriber: @BassamKurdali

Added subscriber: @BassamKurdali
Member

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?

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 changed title from KeyFrame Types redesign. to KeyFrame Types redesign 2021-03-04 17:08:46 +01:00

Added subscriber: @JerBot

Added subscriber: @JerBot
Member

Ok, from a chat on blender.chat, 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)

Ok, from a chat on blender.chat, 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)

Added subscriber: @AndyCuccaro

Added subscriber: @AndyCuccaro
Member

Added subscriber: @EosFoxx

Added subscriber: @EosFoxx
Marion Stalke self-assigned this 2022-12-01 18:07:24 +01:00
Member

Want to make some design concepts
probably until end of January

Want to make some design concepts probably until end of January
Philipp Oeser removed the
Interest
Animation & Rigging
label 2023-02-09 14:36:11 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#79857
No description provided.