Animation: Remove collection hotkeys from pose mode #105120

Christoph Lendenfeld · 2023-02-23T12:05:16+01:00

2023-02-23 12:05:16 +01:00

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.

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.

👍 4

Christoph Lendenfeld added 1 commit 2023-02-23 12:05:26 +01:00

8d0270baa4 remove collection hotkeys from pose mode

Christoph Lendenfeld added the

Module

Animation & Rigging

label 2023-02-23 12:21:55 +01:00

Brecht Van Lommel commented

2023-02-23 18:59:59 +01:00

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.

Christoph Lendenfeld commented

2023-02-24 09:08:01 +01:00

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

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

Brecht Van Lommel commented

2023-02-24 09:13:17 +01:00

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.

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.

Christoph Lendenfeld commented

2023-02-24 09:52:38 +01:00

I'd argue it's a special case for pose mode because the workflow is usually

set up your scene
go to pose mode and stay there to animate

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'd argue it's a special case for pose mode because the workflow is usually * set up your scene * go to pose mode and stay there to animate 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

Sybren A. Stüvel commented

2023-02-24 10:25:17 +01:00

I've posted polls on Mastodon and Twitter. Curious what people will repond.

I've posted polls on [Mastodon](https://mastodon.art/@sybren/109918973373654183) and [Twitter](https://twitter.com/sastuvel/status/1629049598764371972?s=20). Curious what people will repond.

❤️ 1

Brecht Van Lommel commented

2023-02-24 11:36:35 +01:00

I'd argue it's a special case for pose mode because the workflow is usually

set up your scene

go to pose mode and stay there to animate

usually you are not jumping around that much like e.g. with modelling

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.

> I'd argue it's a special case for pose mode because the workflow is usually > * set up your scene > * go to pose mode and stay there to animate > > usually you are not jumping around that much like e.g. with modelling 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.

Sybren A. Stüvel commented

2023-02-24 12:09:15 +01:00

For context, this was also discussed in yesterday's module meeting.

For context, this was also discussed in [yesterday's module meeting](https://devtalk.blender.org/t/2023-02-23-animation-rigging-meeting/27757#patch-review-decision-time-5).

Sybren A. Stüvel added this to the 4.0 milestone 2023-03-10 11:34:43 +01:00

~~Sybren A. Stüvel referenced this pull request 2023-03-10 11:43:46 +01:00~~

Breaking changes for 4.0 #105523

Christoph Lendenfeld added 1 commit 2023-05-25 12:13:35 +02:00

8630cf08f4 Merge branch 'main' into remove_collection_hotkeys

Christoph Lendenfeld referenced this issue from a commit

2023-05-26 09:04:06 +02:00

Animation: Remove collection hotkeys from pose mode

Christoph Lendenfeld merged commit adef3a4556 into main

2023-05-26 09:04:06 +02:00

Christoph Lendenfeld deleted branch remove_collection_hotkeys

2023-05-26 09:04:07 +02:00

Brecht Van Lommel commented

2023-05-26 09:28:40 +02: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.

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.

Christoph Lendenfeld commented

2023-05-26 10:34:43 +02:00

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

Christoph: removing collection hotkeys from pose mode?

#105120: Animation: Remove collection hotkeys from pose mode 1
Module is in favour. The people present either never used it, or got confused and disliked the numbers.
For bigger changes to the keymap we should involve the UI module. After the meeting Sybren checked with Pablo Vazquez and Julien Kaspar (on Blender Chat), and there are people who do use them for collection switching. For removing them from pose mode we have Pablo’s blessing. He did mention this could be a big change to people’s workflows, so might be good to hold on until Blender 4.0. Development of that version will start in 3 months 1 anyway.

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 Christoph: removing collection hotkeys from pose mode? #105120: Animation: Remove collection hotkeys from pose mode 1 Module is in favour. The people present either never used it, or got confused and disliked the numbers. For bigger changes to the keymap we should involve the UI module. After the meeting Sybren checked with Pablo Vazquez and Julien Kaspar (on Blender Chat), and there are people who do use them for collection switching. For removing them from pose mode we have Pablo’s blessing. He did mention this could be a big change to people’s workflows, so might be good to hold on until Blender 4.0. Development of that version will start in 3 months 1 anyway.

Howard Trickey referenced this issue from a commit

2023-05-29 02:51:36 +02:00

Merge in orign/main:

Paul Kotelevets commented

2023-07-11 20:00:28 +02:00

First-time contributor

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

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

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

Sybren A. Stüvel commented

2023-07-13 15:52:24 +02:00

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

Paul Kotelevets commented

2023-07-13 17:33:54 +02:00

First-time contributor

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

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

Nathan Vasil commented

2023-11-19 18:23:39 +01:00

First-time contributor

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.

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.

Paul Kotelevets commented

2023-11-24 17:49:41 +01:00

First-time contributor

I used hotkeys to control armature layer visibility frequently.

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.

> I used hotkeys to control armature layer visibility frequently. 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.

Demeter Dzadik commented

2023-12-08 13:00:58 +01:00

That's an argument against this feature in general though, not about animation specifically.

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.

> That's an argument against this feature in general though, not about animation specifically. 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.

Paul Kotelevets commented

2023-12-10 15:25:07 +01:00

First-time contributor

I think it was trying to preserve.

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.

Pie menus

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.

> I think it was trying to preserve. 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. > Pie menus 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.

Demeter Dzadik commented

2023-12-11 12:32:46 +01:00

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

Paul Kotelevets commented

2023-12-11 18:50:35 +01:00

First-time contributor

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.

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.

Demeter Dzadik commented

2023-12-12 13:30:44 +01:00

@vasiln

I used hotkeys to control armature layer visibility frequently

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.

@vasiln > I used hotkeys to control armature layer visibility frequently 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.

Paul Kotelevets commented

2023-12-12 14:12:06 +01:00

First-time contributor

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.

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.

Nathan Vasil commented

2023-12-13 06:25:21 +01:00

First-time contributor

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.

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.

> 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. 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, <enter> 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.

Paul Kotelevets commented

2023-12-14 10:38:57 +01:00

First-time contributor

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.

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.

Demeter Dzadik commented

2023-12-14 13:11:43 +01:00

shift-m, 2, to switch to armature layer 2

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.

> shift-m, 2, to switch to armature layer 2 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.

Nathan Vasil commented

2023-12-14 22:03:05 +01:00

First-time contributor

Quick temporal actions are supposed to be performed at perception speed, which is the highest available speed for humans.

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

> Quick temporal actions are supposed to be performed at perception speed, which is the highest available speed for humans. 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.)

Demeter Dzadik commented

2023-12-15 12:25:12 +01:00

Not sure why you guys are getting all philosophical over here. Fast is fast, and slow is slow. We all can tell the difference.

I know which layer, because I just put it there.

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.

Not sure why you guys are getting all philosophical over here. Fast is fast, and slow is slow. We all can tell the difference. > I know which layer, because I just put it there. 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.

Sybren A. Stüvel commented

2023-12-15 14:13:32 +01:00

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.

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

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

Nathan Vasil commented

2023-12-15 19:24:07 +01:00

First-time contributor

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

Paul Kotelevets commented

2023-12-17 02:45:24 +01:00

First-time contributor

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

GX2

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.

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

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Animation: Remove collection hotkeys from pose mode #105120