KeyFrame Types redesign #79857

Open
opened 3 years ago by LucianoMunoz · 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.
Poster

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

Added subscriber: @RedMser

Added subscriber: @RedMser
Poster

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

Added subscriber: @BassamKurdali

Added subscriber: @BassamKurdali

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?
dr.sybren changed title from KeyFrame Types redesign. to KeyFrame Types redesign 2 years ago
JerBot commented 2 years ago

Added subscriber: @JerBot

Added subscriber: @JerBot

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

Added subscriber: @EosFoxx

Added subscriber: @EosFoxx
EosFoxx self-assigned this 2 months ago

Want to make some design concepts
probably until end of January

Want to make some design concepts probably until end of January
Sign in to join this conversation.
No Label
good first issue
legacy module/Animation & Rigging
legacy module/Core
legacy module/Development Management
legacy module/Eevee & Viewport
legacy module/Grease Pencil
legacy module/Modeling
legacy module/Nodes & Physics
legacy module/Pipeline, Assets & IO
legacy module/Platforms, Builds, Tests & Devices
legacy module/Python API
legacy module/Rendering & Cycles
legacy module/Sculpt, Paint & Texture
legacy module/Triaging
legacy module/User Interface
legacy module/VFX & Video
legacy project/1.0.0-beta.2
legacy project/2.81
legacy project/2.82
legacy project/2.83
legacy project/2.90
legacy project/2.91
legacy project/2.92
legacy project/3.0
legacy project/3.1
legacy project/3.2
legacy project/3.3
legacy project/Alembic
legacy project/Animation & Rigging
legacy project/Asset Browser
legacy project/Asset Browser (Archived)
legacy project/Asset Browser Project Overview
legacy project/Audio
legacy project/Automated Testing
legacy project/BF Blender: 2.8
legacy project/BF Blender: After Release
legacy project/BF Blender: Next
legacy project/BF Blender: Regressions
legacy project/BF Blender: Unconfirmed
legacy project/Blender 2.70
legacy project/Blender Asset Bundle
legacy project/Code Quest
legacy project/Collada
legacy project/Compositing
legacy project/Core
legacy project/Cycles
legacy project/Datablocks and Libraries
legacy project/Dependency Graph
legacy project/Development Management
legacy project/Eevee
legacy project/EEVEE & Viewport
legacy project/Freestyle
legacy project/Game Animation
legacy project/Game Audio
legacy project/Game Data Conversion
legacy project/Game Engine
legacy project/Game Logic
legacy project/Game Physics
legacy project/Game Python
legacy project/Game Rendering
legacy project/Game UI
legacy project/Geometry Nodes
legacy project/Good First Issue
legacy project/GPU / Viewport
legacy project/Grease Pencil
legacy project/GSoC
legacy project/Images & Movies
legacy project/Import/Export
legacy project/Infrastructure: Websites
legacy project/LibOverrides - Usability and UX
legacy project/Line Art
legacy project/Masking
legacy project/Milestone 1: Basic, Local Asset Browser
legacy project/Modeling
legacy project/Modifiers
legacy project/Motion Tracking
legacy project/Nodes
legacy project/Nodes & Physics
legacy project/OpenGL Error
legacy project/Overrides
legacy project/Papercut
legacy project/Performance
legacy project/Physics
legacy project/Pipeline, Assets & I/O
legacy project/Platform: FreeBSD
legacy project/Platform: Linux
legacy project/Platform: macOS
legacy project/Platforms, Builds, Tests & Devices
legacy project/Platform: Windows
legacy project/Pose Library Basics
legacy project/Python API
legacy project/Render & Cycles
legacy project/Render Pipeline
legacy project/Retrospective
legacy project/Sculpt, Paint & Texture
legacy project/Text Editor
legacy project/Tracker Curfew
legacy project/Translations
legacy project/Triaging
legacy project/Undo
legacy project/USD
legacy project/User Interface
legacy project/UV Editing
legacy project/VFX & Video
legacy project/Video Sequencer
legacy project/Virtual Reality
legacy project/Wintab High Frequency
migration/requires-manual-verification
Module › Animation & Rigging
Module › Core
Module › Development Management
Module › Eevee & Viewport
Module › EEVEE & Viewport
Module › Grease Pencil
Module › Modeling
Module › Nodes & Physics
Module › Pipeline, Assets & IO
Module › Platforms, Builds Tests & Devices
Module › Platforms, Builds, Tests & Devices
Module › Python API
Module › Render & Cycles
Module › Sculpt, Paint & Texture
Module › Triaging
Module › User Interface
Module › VFX & Video
papercut
performance
Priority › High
Priority › Low
Priority › Normal
Priority › Unbreak Now!
Status › Archived
Status › Confirmed
Status › Duplicate
Status › Needs Information 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

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#79857
Loading…
There is no content yet.