Animation: Remove collection hotkeys from pose mode #105120
No reviewers
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
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
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
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
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
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
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
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
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105120
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "ChrisLend/blender:remove_collection_hotkeys"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We have been chatting in the Animation&Rigging module meeting that the collection hotkeys (1, 2, 3 etc.) in Pose Mode are unwanted and could be replaced with something more useful.
This patch only removes the hotkeys, we can later decide what should be in their place.
I thought this was useful for similar reasons as it is in object mode. To quickly show/hide one of multiple characters, the background, props, etc.
@brecht in theory yes, but you hardly ever know the order the collections are in the scene, so you need to check in the outliner anyway at which point it's easier to click on the eye icon
Usually what happens is you press one of those numbers by accident and everything disappears.
That's an argument against this feature in general though, not about animation specifically.
It indeed has issues, though some users rely on it anyway. If an animator has a convention for setting up their shots with collections in a particular way this can work well.
I would not preemptively remove this until there is something for those keys to do instead.
I'd argue it's a special case for pose mode because the workflow is usually
usually you are not jumping around that much like e.g. with modelling
I think removing it is already an improvement, and we can then make a lengthy design task to figure out what to do with the available space. I think that there will be a lot more discussion around what to add.
But I get your point. I'll ask around outside the module as well to see if anyone is unhappy about this removal
I've posted polls on Mastodon and Twitter. Curious what people will repond.
To me this is an argument for why setting up your scene for quick collection switching is especially useful in pose mode.
But if the mechanism to do so is not liked by the majority of Blender of users, I suggest we remove it from the keymap entirely, not only in pose mode.
For context, this was also discussed in yesterday's module meeting.
Sybren A. Stüvel referenced this pull request2023-03-10 11:43:46 +01:00
This was merged without approval or an explanation, even though the discussion here did not come to a conclusion. If it was decided elsewhere, please add that information here.
I still think we should remove either neither or both pose and object mode shortcuts, not do this halfway change.
my bad, this has been discussed so long ago I didn't realize that there was no reviewer.
It has been discussed in the A&R module meeting though and I quote from Sybrens notes
@ChrisLend
@brecht
This is because it wasnt designed properly during 2.8 redesign.
The demand for realtime control still exists in massive cluttered scenes but it has never been satisfied. The entire system was abandoned in a barely usable form.
@1D_Inc yes, it's known that 2.8 wasn't perfect, and it's known there are lmitations today in Blender. Rubbing it in doesn't help anyone.
@dr.sybren
It is not specifically about 2.8, it is about development style in general, when one developer corrupts some functionality being completely out of a context, and the other cuts it out as corrupted instead of fixing.
The situation with polls is essential.
In short, devs didnt succeed to design and promote a usable system, and then they ask people if they like it, having predictable results.
I'm discovering this issue on upgrading to 4.0 and getting a handle on the new bone collections. My perspective is as someone that is primarily a rigger.
I used hotkeys to control armature layer visibility frequently. They were among my most used hotkeys. I knew exactly which numbers corresponded to which layers because I was the one that put the bones on those layers, via numbered hotkeys. My armature layers are often very fluid, as I need to be able to create relationships between bones that are, very often, located in the exact same place, may not yet have descriptive names, and where distinguishing by color or shape is not yet appropriate as it will obscure other essential information. The layers that I create do not necessarily represent the final layers that I deliver, but instead, whichever layers I need to simplify my operations and testing for the next few minutes.
My experience is that many Blender users don't use very many hotkeys, but that when they do, they should see their throughput increase dramatically. While animators that used my rigs may not have used hotkeys to control layer visibility, I encouraged them to do so, and include packed text files with bone layer names and numbers to make it easier for them to do so. I would also organize layers intentionally, so that even if they didn't read or understand the text files, if they just started on layer 1 and worked their way down, they'd probably be working in the order in which they'd like to work (gross manipulations -> tweaks.)
So I know that as a rigger, rapid control of layer/collection visibility is important; and even if animators don't take advantage of this, they would be working faster if they did.
This wouldn't be as much of a problem if I could just replace these hotkeys, but instead, I can no longer find any keybindable operations to control collection visibility in 4.0. What I see instead is that we have two redundant operations to move bones to collections, "bone collections" and "move to collection" but no way to rapidly control visibility of collections.
Since a lot of talk here is about the parallels with object collections, I want to add that I also use object collection visibility hotkeys frequently. It's true that the move from layers to collections complicated these hotkeys (I made a "paper cuts" entry about the lack of parallelism with numbers to move to collection and display collection) but I have found my way around these issues, sometimes just by prepending a number onto the names of my collections. The time I spend doing this is hugely worth it for the time I save on being able to use collection hotkeys easily. If other users aren't using hotkeys because they have trouble associating numbers with collections (of either bones or objects), then this is a simple way to ease that association, and could be done automatically by Blender.
This is because complex rigging belongs to multiref-related workflows, and quick access slots system (slots UI and hotkeys) is supposed to solve it across the entire application.
If you feel need in using such a system that means that you deal with stuff which is more complex than average simplified method allow to handle.
This system is typically used for real-time combinatorial navigation of complex and visually confusing structures, which is an industry level demand which has been solved exclusively in Blender.
To make it more specific to animation, animators in a prod environment will be working with overridden collections, which cannot be re-ordered via outliner drag&drop, not even at the scene root level. That may be possible to address by the core module though, but I don't think it's on anyone's radar at the moment.
That said, I tend to agree this feature is a bit awkward in the first place. I think it was trying to preserve similar behaviour from 2.7 and its layers system, which is understandable.
As always, my proposed solution would probably involve pie menus. Let's say you press the "4" key, and it pops up a pie with 8 entries that all just say "Choose Collection". When you do it, you get a pop-up to choose one. Chosen collection gets isolated, and assigned to that pie menu entry in this file, so you don't need to choose it again the next time you call the pie. Ctrl+Click to remove it from the pie, which you can learn via the tooltip.
It looks like if developers tried to preserve a system they dont know how to use. Using this system assumes dealing with much more complex and visually confusing real-world data structures at higher workflow speeds than devs are facing.
There was lots of promises from them to fix fingers they broke to Blender users, but everything we get is nothing but just more damage up to extremely sadistic cutouts.
This is not the way quick combinatorial acces in dynamic context could be solved. It is necessary to understand what problem and how exactly the original system solves workflow-wise before making any proposals. Piemenues are not able to satisfy realtime combinatorial control requirements.
@1D_Inc You're welcome to contribute a concrete idea for a solution, or to follow the thread in silence. Please stop using this thread just to vent. Thanks.
It is a complex system design level problem with no simple solution that require taking into account quite deep context the discussion of which (the problem, the purpose, possible solutions and their comparisons) goes in many different places for many years already.
Please stop behave like all of this has never been.
@vasiln
Just to be clear, these were your custom hotkeys, right? As far as I understand, the 1,2,3,etc hotkeys never worked on armature layers, only scene collections, and that's what this PR is removing, in pose mode only.
When it comes to toggling visibilities of the bone collections though, you're right that the 32-box toggle pop-up that used to be on Shift+M is no longer there, but I believe that is a separate topic.
Switching from dynamic context system (32-slots box) to static context system (bone collections) is a long awaited progress for sure, pros of a static context systems are well known (high capacity).
However, like it was before with regular collections, dynamic context management conditions (like speed of a combinatirial access) always remains ignored and unsatisfied.
The system realizations are different, but the problem is the same.
I was talking about the change armature layers operation, shift-m since before 2.8, at least on 2.79 keymap, not sure about the other setup keymaps. A typical thing I might do would be shift-m, 2, to switch to armature layer 2, so yeah, you'd use numbers to control visibility using that operation.
I don't consider this a separate issue-- collections, layers, from the user standpoint they are barely different. Collections are prettier, but the important functionality is the same. The issue is that controlling the visibility of groups of bones, whether you call those layers or collections, used to be something that was hotkeyed; now, not only is not hotkeyed, it's not even possible to hotkey.
I don't think this is a complicated issue, not without making the perfect into the enemy of the good. Just as with object collection visibility hotkeys, referring to nested collections via numbers is maybe not ideal. But, it is better than not being able to refer to them at all. If we don't know what the ideal solution is, then settle for good-enough. And, there are plenty of ways that this good-enough way can be improved in small ways-- perhaps, by adding explicit numbering to collections, regardless of whether those are collections of bones or objects.
I'm not a fan of pie menus, and I don't think I'm alone in that-- I'm moving my mouse for the next operation at the same time that I'm hitting hotkeys. But my memory of pie menus is that you can use numbers to choose options from them, and as long as that's the case, it really doesn't matter whether you're hitting keys from a circular menu or a square menu.
The problem of a pie menus is that it disallow to obtain information about current visibility combination fast enough - it takes much more efforts to read combination from circular-shaped UI and it is needed to call pie menu each time when it is needed to check it and also make sure that mouse stand still which distracts from actual content.
Reading is always much slower than percepting, this is the main difference between static and dynamic context handling. Quick temporal actions are supposed to be performed at perception speed, which is the highest available speed for humans.
This is why using pie menu will not bring any sufficient enhancement over using regular bones collections menu in comparison with direct realtime control.
Ah, I didn't know the number keys worked in that pop-up.
Fair concerns about the pie menu idea. For me, using a pie is definitely a lot easier and faster than lifting up my hand from the keyboard to press keys 6-9 and then moving it back. But that's me I guess.
Perhaps we could take inspiration from the Quick Favorites menu. There could be an ability to mark "favourite" collections, and the 1-9 keys would toggle visibility of those, in the order of the current view layer's hierarchy. I would make this a built-in add-on though, so the 1-9 keys stay open for people who don't use this kind of behaviour, since according to the poll, only about 10% of users do.
Just for the sake of theory, and I hope this isn't off-topic, but quick temporal actions should be performed faster than perception speed, because perception is not always necessary. A baseball pitch isn't finished through responding to feedback, but through anticipation, through knowledge. Perception is not the fastest speed available to humans; anticipation is. If we had an Olympic sprint where the opening gunshot was announced with a 4:4 drum roll, we'd see the finishing times decrease by >150ms (but we'd also see a few more disqualifications.)
When I make a new cube and hit g->x, I don't have to perceive anything. I know what will happen. If there was instead a menu that offered me x, local x, all but x, all but local x, etc, then that would slow me down. At some point, as with vertex/edge/face selection in edit mode, I might be able to associate these options with different keystrokes-- with numbers on the menu. But the cognitive association of x the letter with x the axis eases that association considerably. Blender's GRS hotkeys are amazing: I can transform that cube as fast as I can think it. I could probably do it pretty well with my eyes closed. I definitely could do it with my eyes closed if I wanted g x 2.
And by the same measure, when in earlier version of Blender I type m, 2, shift-m, 2, I know exactly what will happen. I don't need to perceive which layer I want to display; I know which layer, because I just put it there. (This is part of why parallelism between move and view actions is important. I can, as with object collections, eventually understand that I need to move n, then type n-2, but that's not an easy association to develop.)
Not sure why you guys are getting all philosophical over here. Fast is fast, and slow is slow. We all can tell the difference.
The pie menu idea I proposed earlier would provide this.
The favourites system I proposed would also provide this.
Nobody's bouncing ideas or providing meaningful feedback. Unsubscribing from thread.
@1D_Inc get a hold of yourself. This behaviour is simply unacceptable.
@vasiln if you're up to it, we'd welcome some concrete proposals on how to address the "hotkeys for bone collection visibility switching" feature. Ideally this would work for scene collections as well, to keep things consistent. This shouldn't happen as a discussion on this pull request, though.
One concrete, good-enough, better-than-nothing solution, is exactly what this commit removed.
If you're genuinely interested in my thoughts, I would be delighted to discuss them with you, and to hear your thoughts as well. Just tell me how/where you would like this conversation to occur.
@vasiln anticipation is a nice goal to follow for sure, but perception is the only speed that allow to reach stable predictable results by avoiding possible missclicks because of a proper amount of a visual feedback. In anticipation you act fast, in perception you act fast and have an action confirmation.
Anyway, nice to meet a person who also follow path of a reaching maximum workflow speed, that usually comes with editing of a higher complexity content, when reading-based workflows became expensive.
Such an input system is called Noun/Verb which we call simply as "Verb input system" since it operates in verb style (select->operate). An alternative is Verb/Noun input system, which we call "Noun", which is easier to learn since it is single-handed but more limited and slower to perform.
@dr.sybren The issue of a workflow speed during complex content management is deep, context-rich and pull request is for sure not an appropriate place for discussing it.
However, this issue exists for a long time already - since collections has been originally presented, all those context has been missed during system design and each time we tried to discuss it in the other appropriate places it didnt gave an appropriate result since the issue keeps going and even growing. And most of the times we are also suppressed by users who didnt reached the appropriate workflow speed yet, who are not familiar with this system and mostly has come from the other software which opinion is usually prioritized.
As a result Blender became a hostile place specifically for Blender users who relies and are dependent from Blender systems (for example, workflow speed is one of the reasons our studio originally switched to Blender in order to compete on the market by working with more complex and structurally confusing content than other software approaches allow to deal with). Hope it is understandable.