Layer Switching Shortcut Inconsistency #61492
Labels
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
24 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#61492
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
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?
There is some improvement concept for collections shortcuts.
Currently, 1234 buttons shows a collection, but sending objects requires name in menu (M - "Collection 1" - "Collection 3" for example)
That would be nice if moving to collection will also support their number.
For example, "5" button shows collection called "Lighting Collection", so pressing "M5" will send selected objects to it.
See: #55162#619317 - originally from @1D_Inc
Added subscribers: @1D_Inc, @ideasman42, @antoniov, @CharlieJolly, @schweppie, @Hexbob6, @freemind, @PierreSchiller, @SteffenD, @remotecrab131, @Thane5, @orvb, @brezdo, @iss, @0o00o0oo, @RamiroCantu, @Regnas, @WilliamReynish
#62953 was marked as duplicate of this issue
Thanks, that will make organization of complex scenes faster.
Note that numbers are automatically assigned here, a solution could be to move the top menu item to be the last item.
We could always have an exception where menus can request to handle number keys separately but think this isn't a good idea since it makes otherwise matching menus behave differently.
Making as incomplete since the desired behavior still needs to be resolved.
I think the numbers for collections is a weak concept to begin with. When you have nesting and unlimited numbers of them, the 1-9 numbers don’t map logically very well.
I imagine we could make much more useful use of the number buttons for other things, like active tools or direct access to modes, or just free keys for user shortcuts.
That said, increased consistency is a good thing, so if we keep the numbers for Collections, then it should ideally work inside that menu too.
Removed subscriber: @antoniov
Added subscriber: @DuarteRamos
I agree, it will not map well to be easy and intuitive with potentially unlimited number of layers, and it is not predictable enough for frequent use.
Number buttons should probably be reserved for something that maps better to the limited (1 to 9) available keys like selection modes in Edit Mode.
We don't need to fit all collections, we need to fit all available numbers, and we need fast collection navigation at any cost, regardless of their count or consistency.
Numbers don't fit unlimited collection concept, it doesnot matter, so we are going not from it's consistency, but from functionality - ability to switch/isolate required number fast.
1-9 (+ alt) nums allows to switch fast 20 collections and this is enough for comfortable work.
If user will set more than basic 20 collections - he will be forced by his will to know their names in any way in order to work with them, this is his choise, so there is no unconsistency at all.
Otherwise, if to remove 1-9 nums from collections, user will be forced to know each name every time he work with them.
That means no way to fast preview, no way to localize, no way to sort scenes object, keeping outliner opened (still without ability to isolate collection), and all of this is truely PAINFUL.
It was already removed from edit mode, so ability of comfortable modeling of something tightly surrounded by objects (like restoration) has gone.
Removing 1-9 nums from collections is a Really Bad Idea.
That easily can be explained by workflow.
We pressing "5" - we see objects, that are in this collection, like, for example, trees. Or lights. Or masking objects. Or some other context.
So, we want to send another objects there, by the same context. (By the way, names were given to collections to represent that context.)
We are unhiding everything, selecting what needs to be sent - and pressing "M5" to send object to that collection. Automatic numeration is also ok there.
Doing that we do not care about collection name, its hierarcial placement, outliner ufolding, menu searches, or other things that makes workflow slower and expensive.
We are doing thing that we truely want behind all that things - we are sending context to context.
But doing it clean and fast.
That's the goal of this proposal.
Added subscriber: @Rusculleda
What's the use case for moving object to "Scene collection" root? As far as I can see that's not something one should be doing often, so maybe that option souldn't even in the M menu? I know that's a different discussión from the problem at hand here, but it would also solve it.
It is useful when you need to move some objects by context from any kind of collections to organize them in other way.
If there are some objects in scene collection left, that means that "you left some objects to sort when has gone home yesterday", and objects in scene collection are that objects.
At least, until there is no "M5" ability we are talking about.
Well, if "scene collection" was removed from the M menu then we would automatically get the "M5" ability. And moving to "Scene collection" could still be done from the outliner in the (I would expect) rare cases where it is needed.
The proposal is to get rid of using outliner/GUI at some possible point.
I would prefer to set scene collection to digit 1 (start collection numeration from it) to have ability view whole scene without higlighing everything with alt+H, that freezes computer on complex scenes with selection outlines.
Also scene collection is needed to hold imported objects.
And no, removing scene collection will not automatically bring M5 ability.
Added subscriber: @crantisz
here is my post on devtalk related to this tread:
So Master Collection can be assign to Enter instead of 1, with same logic as in submenu.
Not exactly, but better than nothing.
Well, placing it to 1 will bring ability to view entire scene without unhiding and outlines)
It worth assigning "1" button.
Also, it may be possible to make it toggle in "entire scene" - "previously isolated collection setup" way, that is, actually, very handy.
Want to clarify issue about nums. First of all, it is a separate system.
A quick content displaying system (further - QCD) - part of verical (hierarcial) navigation, alongside with Outliner and RenderLayers.
There are workflows that depends on it, because it makes them possible, independently of layers, collections, selection groups, or any other hierarcial units and their number.
It is a unique system in the software industry, that makes Blender out of the ordinary. It's demand depends on the industry to which the workflow of user belongs.
You don't need QCD if you are in
You need QCD in industry, that requires close components placement with variations, such as
Some of that workflows requires QCD more than collections itself, that's why it is important.
Added subscribers: @senteria, @nacioss
Here is also Shift toggle inconsistency - Shift+numeral button doesnot toggles collection visibility.
For example, we starting from Collection 2 that containing object to render - pressing 2 to isolate it.
Then adding required collections with scene lighting/entourage objects to it, making them visible - pressing Shift+3, 4, 5, 6, 7... collections reveals
But if collection 7 contains obstacles, it cannot be hidden back with Shift+7, there is no way to hide it back with numeric buttons.
So, without Shift-toggling ability, the only way to get proper setup is to make all the same thing again, but remember that number 7 contains obstacles, and do not press it while Shift revealing nex time, keeping hope, that collections 8, 9 etc contains right objects, because if they don't, you will need to make it again and again.
You need to remember numbers instead of simple keypressing.
Added subscriber: @WillFalcon
I agree with that. Completely.
Usually in my worklow I use [1-5] &alt+[1-5] for collecting objects, armatures in main scene, and [6-0]&[alt 6-0] for assets to get quick access and show them up and hide by adding or excluding layers.
And when I need more complicated layers I just create a new scene in the same .blend file to keep things organized.
Added subscriber: @Rawalanche
I agree that numbers for collections is a really weak concept. I think easy solution in this case is to make sure industry keymap is good enough so that most people will use it, and the people using legacy keymap, which will come with collection number hotkeys, will sooner or later switch to the industry one, once everyone else will be using anyway, and the legacy keymap will finally be deprecated.
For me manage collection with numbers is very important and make my work much faster. Also better is making all collection visible with one shortcut like in Blender 2.7x.
The problem is, the "INDUSTRY STANDARD" keymap never had things for quickly toggle layers. It's a unique Blender feature.
What's the point of making Blender follow the "INDUSTRY STANDARD", while the so-called "INDUSTRY STANDARD" is so far behind blender's innovation on the user interface. You know, the actual "USE" part.
Not to mention, also, as only a small part of the big industry, Blender is not here to change the industry standard. The industry standard is a thing everyone agrees on. Not something you can just change.
Some of these ideas, debates, and changes made to Blender's UI are so counter-intuitive/counter-productive it boggles my mind.
But for the actual topic, yea I think the Move to Collection key should work similarly like 2.7. OR,
what about moving the collection/layer control into a pie menu or something way more efficient than a bunch of keys in terms of efficiency? Such as an infinite scroll menu that corresponds to the number keys when open?
The reason I suggest an infinite scroll menu that responds to number key input only after the menu is open, is that I also don't like filling the 1-9 keys with almost identical functions only with parameter changes.
I was able to create menus in Blender where the operation works differently based on which modifier you held down when clicking the menu items.
So, we could go to this infinite scroll menu, find the collection you want to look at, click it, and show it; Shift-Click it to toggle its visibility; Alt-Click to move selection into this collection; Alt-Ctrl click to take the selection out of its original collection and put into the new collection.
Hell, we could even make this menu persistent after clicking, essentially making it a Collection/layer Manager.
The number 1 keys responds to the first displayed item in the list of collections, and scroll wheel scrolls the list.
The industry keymap, which is already planned, will not be replacement for Blender's standard keymap. It will be shipped with Blender as an alternative. The reason you too will be using industry standard one is that after a few years, there will be almost no people left using Blender's legacy keymap ;)
Remind me what I'm using in a few years. I never use default keymaps for any of my programs and I will never vouch for "INDUSTRY STANDARD" unless it is actually good.
Please stay on topic, alternative keymaps have nothing to do with this issue.
Found, that Shift+num toggling is workind in january build of 2.8
It has been broken recently
More detailed description at Devtalk
https:*devtalk.blender.org/t/layers-maniphest/6578
Interestnig solution of Collection numeration from Dfelinto
https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#June_17_-_21
But the problem is that autonumeration is dynamic. That means, it requires more memory to remember which number belongs to which collection depending on current depth state. For example, if user want to send objects to Collection with number 5 via pressing M5, it is hard to say where objects will be sent.
So it will be better if first 20 slots, that available for numerals keypressing, will have static (adress) autonumeration independently of hierarchy depth, but with numeration starting from first level of hierarchy.
Static autonumeration is looking not so fancy as dynamic but is more usable.
Example - when scene's collections are formed, user can call collection as "1_Room", "2_Car", "3_Table" during single scene setup, and this numeration in static representation will be actual independently of depth parameter.
Here is numeration types comparizon
B2 type is the best one.
I've got a very clean allegory for everything happening around layers, that can explain a lot.
QCD (2.79 Layers) - is a navigational system. It's like a RAM.
It's only goal - to provide quick access to view and sort objects in a limited number of slots.
Collections - is a natural layer system.
It's like HDD - it allows to store a huge amount of stucturized data with low access speed.
The problem is that in Blender, the best RAM available on the market was replaced with a HDD instead of adding a HDD to the current RAM.
That's how this allegory looks like.
Added subscriber: @StanislavOvcharov
Added subscriber: @Harley
Probably a nonsensical suggestion, but...
It seems to me the central problem here is in how to auto-enumerate items in a hierarchical list, but one answer might be to NOT do so.
Why not instead treat this is an attribute of the collection instead: an optional secondary shortcut name? The first 9 collections created, no matter their relationship, simply get assigned shortcut names of "1" through "9". And you could choose to SEE them, drawn in a special way after the collection name in Outliner (off by default).
Afterward you might have many collections arranged in complex ways, but you could just manage the shortcuts if desired. Want to make the "Chairs" collection be number "4"? Just right-click on that collection and set it so.
In fact doing it this way would allow you to use all of "a-z" (and possibly A-Z) as well. So you might make "Chairs" be the "c" collection for a time and then later assign "c" to "Cars" just because it is easier to remember. Then you could move an object to the "Cars" collection by "mc", or hide "Cars" by Ctrl-h c"
That actually makes a lot of sense. Explicitly mapping a collection to a number as a property of the collection itself.
I really dislike how numbers are not scalable and no longer map well to potentially unlimited layer. If this indeed opened up the possibility to map all other keys as well it will be extremely powerful while retaining speed
Added subscriber: @kaiwas
Great allegory!
The speed at 2.79 was that there was no need to look at the outliner and think. There was a clear system of squares always in sight)
An outliner is sometimes a heavy system.
If you compare the occupied space, then the layers in 2.79 are 1 part, and the outliner is 9 parts. Although the size is not important! )))
I've already mapped all possible ways of autonumerating in my previous post in picture, including manual numeration, and marked their weak sides.
https://developer.blender.org/T61492#706904
Manually assigned numerations is easy to set, but have a lot of problems with handling and managing them.
It will require QCD 20 slots widget with object and availability marks.
Also it will be hard to locate 5 assigned slots in 1000 collection list.
Any type of autonumeration is devoid of these problems.
Alphabet has 28 symbols capacity (Capslock can bring a mess).
Also, goal of QCD not in wider range, but guarantee better control for strongly defined slots, including switching between and viewing them.
You can view 5 6 7 collection via pressing 5, Shift+6, Shift+7, but canot do that with alphabet, because it is mapped with blender shortcuts.
Yes, as far as I can tell, every way to auto enumerate is flawed and non-obvious.
Managing manual shortcut names does not have to be complex as the set is small and are identified with a single keystroke. The only important thing is there has to be a way of seeing them in the outliner when desired.
With manually-managed shortcut names there is no reason we couldn’t get our old 2.79 layer widget back. Optionally with 35 little buttons. Made a bit more useable since hovering would show both shortcut and the name of the collection.
Of course it is, Collection system suddenly was designed without taking QCD into count. But if you can view through something fast, it solves problem.
That's complex management that is far away of QCD speed, as it available with Outliner simultaneously.
No remembering names, no setting attributes, no outliner modes switching, minimalistic interface - that's all brings insane amount of speed to QCD systems for viewing, managing, sorting, sending, comparing scene's content.
Just like RAM does.
@1D_Inc : sorry, but I am unsure if your second paragraph is in agreement or disagreement with my comment you are quoting. There could be some words missing or “autocorrected” or perhaps I need more coffee. LOL.
Well)
I want to say it you have to hovering something, to see some name, that you need to remeber to invoke it then, it is already speed lost.
We are working with hundreds of scenes with millions imported objects from different sources to sort and compare.
On such a scale, remembering such local things that someone somewhere has somehow assigned is an overload of user's memory that we cannot afford.
Such system have to be predefined, and as simple as "hey, look at layer 3" or "compare 3 and 5" to allow us to survive.
And this is a serious UMC (User's Memory Consumption) problem.
Huh? I'm just not seeing that complaint.
You would yourself be assigning any shortcut 0-9, a-z to any collection you wanted. Faced with a UI element that had two rows of 5 I'm sure it would be obvious that these were for 0-9 and would be pretty quick to enable or disable the one you wanted.
If you wanted to (optionally) also show a second section containing a further 26 I think you could also quickly see which is which. What I was saying above is that, unlike in 2.79 these collections have names so you could see them when hovering over the little buttons.
Wow, a part of QCD widget!
Looking interesting)
I've seen a concept by Dobarro in twitter about growing widget, according to collections number, but it was looking too complex to use.
That realization is looking nice, I guess it can already help to sort content a lot.
I cant say if manual assignation is a good idea. It definitely have a potential, but we know theoretical problems it can cause, and only usability tests can give an answer how much usable it is.
... and my idea let’s you press “mc” to move an object to your “Cars” collection, “mh” to move to “Horses”. I don’t think you could get much more memorable than that.
that will definitely break nums compartibility, so there will no ability to compare slot 3 and 5, or set visible 2,3 6 and 9 slot simultaneously from keyboard quiclky.
Quick invoke - is a very important part of usability of such systems.
Here is an example of switching speed amount, that provides numeric input.
https://devtalk.blender.org/t/layers-maniphest/6578/32?u=1d_inc
Scull on this example is a pretty much cheating example - usually you have to compare same cars, or houses with some tiny changes, like window movements.
So they both will have almost same name, and only way to compare it - to press, for example, "1 2 1 2" buttons looking just on a model to figure out their differences.
Here is more precise example
As for making management simple I’d say it is by keeping it minimal. There are only 36 shortcuts, no attempt at adding more with sequences or modifier keys, just 0-9 and a-z. So close to, but still more than, our old 20.
And no complex maintenance of keys. You assign “4” to a collection and it happens immediately without confirmation, even if previously assigned. A collection that might have had that previously now has no shortcut. So effortless to change “c” from Cars to Chairs.
This just seems to get us the best of both worlds. We have an unlimited number of collections that can be organized in very complex ways. And we have a quick and simple method of getting to any arbitrary subset of 36 of them.
Well, then we still have problem to invoke and compare A and B slots, while numeric keys assignations are already saved for collections switching.
There is no basic need in 36 slots - in practice, if it isn't enough 20 slots for sort and cleanup , you are doing something wrong.
That's proven by decades of Blender using before 2.8
There's nothing in what I have said that should imply that. If you want to imagine having keys 0-9 assigned directly to the visibility of those collection shortcuts then so be it. That wasn't mentioned and doesn't affect the core idea. It just might be that what you want might only apply to the first 10, not to all 36, depending on how you want to set that up.
... but having the ability to show/hide a layer with a short command that ends in 0-9 or a-z is just a keymap issue.
But switching collections with 0-9 is already working, isn't it?
It is already mapped for 20 slots in 2.8 release
Only letter input can cause keymapping issues, so letter assignation is quite doubtable.
We never needed more than 20 slots to manage scenes all this years, so we, basically, so it is double doubtable from that point.
This thread is about which collections those apply to. You were bringing up keyboard switching.
Yikes. I'm out. The beautiful weather and my bike is calling. Laters.
Okay, I will write some thoughts to clarify whole problem. Cheers)
I want to say that QCD is a quick access system.
It is a solid system, that consists from:
There are 20 slots that already are assigned to 0-9 keymap, that allows to quickly
This amount of slots is enough for any kind of manual navigation/sorting/sending/viewing job, as far as it was enough for Blender since it began.
Adding letters support can increase amount of slots (capacity of system), but there is absolutely no need in it.
Minimalistic GUI that allows to view/navigate empty slots.
GUI is needed to view what slots are currently turned on, that is especially useful when there are turned on several of them.
Adressing slots to invoke them and send objects to them.
Currently, adress assignation is numeric automatic.
All this three parts combined makes proper QCD system.
Numeric input is good, as far as slots are numeric, that allows to slots to be anonymous, as far they are rewritable - any collection can be assigned to a slot.
It's capacity matches numeric keys already available and stored in keymap, so digits 0-9 and alt+0-9 are already managing slot's visibility.
A perfect solution.
Letters support can be also added, but it will definitely mess with current keymap and management.
Example - if to assign "Garments" collection to letter "G" it will not possible to get what slot it should to go and how to invoke it, because key "G" is already assigned for grab.
If to assign to "Garments" collection number 4 it is clear what slot it will take - 4th one, and you need to press 4 to invoke it.
Awesome and clean.
Adress assignation is automatic, that can require scene's collection order preparation.
I can’t say if this is bad, because collections can be dragged into the outliner.
Assignation of adress can be manual, but we don't know if it can casue management problems.
The only change I would like to make to this system - it to assign digit "1" to all collections in case of manual assignation, or assign digit "1" to Scene collection in case of autonumeration.
The problem is - it seems, there is no ability to view all collections via single hotkey.
I mean - at all. If you have 1000 of them, you are in trouble.
If all collections by default will be stored in slot "1" in toggle way, that will also bring clarity if there are collections in scene that do not belong to any other slots, with ability to view them.
Like ammo in an endless clip.
That will allow QCD system to handle and sort content of any amount of Collections.
Like RAM with HDD.
Also, if we are positioning QCD as collection's mess debugging tool, it may have a sense to make autonumbering for just first 20 core collections of first level, including scene collection as first, independently how deep collections will be inside of them.
It will be easy to hanlde them both in gui and outliner, and control them via dragging. This solution also helps to M5 problem.
So, that's how we've got B3 type of autonumeration, a slot numbering:
I still prefer A. The user gets to chose a subset that they feel is the most important, regardless of where the items exist in the list. Any auto assignment of slots will get increasingly bad as the list gets longer.
That's the problem - there are no more or less important collections.
Auto assignment also can't "get bad", it exist or not, as a rule. Rule is bad by default or good by defailt.
List will get longer in any case, but in autoassignation it is easy to tell where slots are - by opening outliner and, actually, looking on top of it. Tha't easy.
Manual assignation supposes that you are opening a scene with 1000 collections with 19 inlay amount of them - and go go search for them through entire outliner, if at least they are assigned, of course.
And, as practice shows, that will be funny only at first time...
QCD - is not a creative tool. Collections are.
QCD - is an emergency tool for Collections.
Something that can be definitely found in all this swamp of content, dumped by someone in hurry, that it supposed to manage with.
Maybe I'm not explaining it correctly, or I am misunderstanding something.
But auto-assignment, by definition, picks collections without your control. If you have a very small number of collections then all or most of them will be assigned. But once you have more collections than can be assigned then the remainder cannot be assigned. And it gets worse as the number of collections increases because the pool of unassigned collections increases. With manual assignment the user is always able to select what THEY think the most important collections are at any one time.
Again, unless I am missing something fundamental here. Which is certainly possible. LOL
If we need some specific collection, that is important - we will definitely knows it's name to have access.
Slots are aninymous structures, so it is more important where they are, than what they contain.
They should be static as dry land to swim to.
Otherwise, they will be like lifebuoy drowned with drowning in a Collection's ocean.
I can't imagine manually assigned 20 slots, that will not be immediately dissolved in 1000 collections file.
Then we will have 30 such files with random slots assignation, and that's it... a mess we were just starting from.
I'm still not quite understanding your concerns with this, so I am probably still missing something...
You are using the thought of having 1000 collections and imagining some difficulty managing shortcuts, even though that management is not fleshed out. So imagining difficulty doing something hypothetical.
But with 1000 collections and automatically-assigned slots, wouldn't those slots simply point at (approximately) the first 20 collections always? And therefore render them useless since the chance of a slot containing something you want is only 2%.
So from my understanding of this, automatic assignment with 1000 collections is not useful at all, while manual assignment would work well, but there might be theoretical difficulty in the management of them?
If I am misunderstanding this please correct me because I would like to understand.
Yes it will.
No, it doesnot, as far as collections are draggable.
Collections are supposed to be used without QCD by developers by default.
But, if it is need in their reorganization, an emergency, they are dragged to QCD in order to be repaired. Like inventory.
So slots are filled with what is needed to be managed - when it's needed to be managed, or are filled with whatever, in case if there is nothing needed to be managed.
I save file, send to user, and he always know where to locate slots.
Also there is case for local scenes and some special type of work, like creating gamedev models with multiple LOD's, historic restoration with multiple refrences and so one, that requires static QCD more, than collections itself.
So autonumeration solution fits both worlds - it can be used as main engine for local work and as emergency for heavy scenes setup.
About manual numeration there is still an insoluble problem - 20 slots irrevocably dissolves in 1000 collections, and in 30 files it inevitably turns to mess.
For example, if to open someone's file, created with manual numeration, and press 2 to show slot 2- it is absolutely impossible to determine where belongs what it will show, and how to locate it in 1000 collections hierarchy.
Also it will be hard to reassing slot 2, because you will never know if it is assigned to something, and it's assignation is still needed, because it was assigned, for example, by other person.
It will take more time to locate and manage slots than to do actual work with them, so, manual assignation creates a logical mismatch at the level of building a workflow.
Thanks @1D_Inc,
Not trying to be obstinate for no reason, just trying to get to something that makes everyone happy.
So with a lot of collections auto-enumeration become useless unless you manually reorder the collections to suit the enumeration. So that is some manual work that we need to compare against the work of manually assignment.
Further, all of the numeration types you have outlined are (necessarily) complex because of collection hierarchy. For all these it would be difficult to drag folders to get a target number. In fact most dragging of a single item would renumber all those after it. That would not be fun.
Right-clicking on any folder within a list of 1000 and assigning it "9" from a popup menu is faster than dragging such a folder to the beginning of a list to a specific location in order for it to become "9". And then it would re-number all below it.
But I can certainly see your point that when sharing a large file you need to easily communicate what slot is for what collection. But with any scheme there needs to be a way to directly show these slot numbers. Otherwise, looking at your graphs there are many ways they could be enumerated and users would not be able to guess.
So if these slot numbers can be (optionally) shown in outliner, then it also makes sense that you can filter on only the collections that have such slot shortcuts. So regardless of scheme (manual or auto) you'd be able to quickly see slot assignments even in a very large list.
Okay. Indeed, there is a lot of things to think about.
Specific number doesnot matter for decades of layer using in Blender pre-2.8, so renumeration is ok.
You opening unfamiliar 2.79 scene and always checking it's layers first to get what is happening in scene.
It is way faster to check 20 books on your shelf, than 20 bookmarks leaved somewhere in a library.
You can filter collections that have bookmarks, but locating them in entire hierarchy to define what it belongs to can take an eternity.
As it was described, easy to setup, hard to control.
I love idea of easy manual assignation, but I see frightening troubles that comes right after that, based on my experience, that can’t solve even in theory.
Removed subscriber: @WillFalcon
Currently Blender provides [B2] autonumeration. It is that is working now.
My proposal is [B3], that allows to view all slots at once in outliner in a plain way, also no outliner changes reqiured, so it can be build on it's current realization.
You prefer - [x], that can reqiure massive outliner changes in order to make system clean enough. There will be a lot of things to do to ensure sufficient control, including additional modes, highlights, and filtering options.
Can't say if it's worth it.
Bookmark system feels like separate system.
A very nice example - photo dump sort and cleanup. A pretty much similar task.
Usually, some static folders are created in "SORTED" folder to move photos there to split them by their context.
Moreover, software such as Irfanview with F7/F8 keys allows you to send the photo you are viewing to one of 14 anonymous changeable folders, actually, a slots)
Like M5 shortcut action from topic.
That's incredibly handy solution, that allows to sort any amount of photoes. You can always see how much to sort is left - it's, actually, every photo beyond slots.
Unlike sending to folders, bookmarking photos strategy reaches its usability limit pretty much fast.
It seems, the only manageable system, based on bookmarking, is a single bookmark.
Easy to set, easy to find, easy to locate in hierarchy, easy to send objects to it.
That can work like a portal.
More bookmarks will inevitably mean the need for a system to organize such a system.
Added subscriber: @nokipaike
Hi, until now I never cared for shortcuts for collections because in blender 2.80 I didn't need them (not having projects of this size that required it ... but now I'm starting to go a little deep ... I had a sneak peek at this task but without really reading what was being discussed ... thinking that these shotcuts
1234567890 + shifthad already been here and were working ... Today I was all happy to start doing in-depth tests .. going to also to review how the situation was in blender 2.7x , and all of a sudden I remembered how comfortable the layers were and how much in the past they helped me to organize the work visually and through shortcut ...And now of all this, there is nothing left, my mouth has remained open and my eyes overflowed becoming aware that you had the courage to take everything away.
Guys, this was a blender killer features, one of the best, ok I perfectly agree that the collections extend endlessly the possibilities, but in practice, to have the shortcts for the first 10 positions, and to have a visual feedback of these, it was one of the best ideas Ton could have over 20 years ago ... so please...
Don't throw the baby out with the bathwater
A nice expression)
Well, there were a good reason, that explains QCD slots.
It is a tool, that effectively reduces UMC (User's memory consumption) in a wide range of workflows, and it has best realization in an entire industry.
There is also problem, that QCD doesnot works as a system with such kind of shuffilng.
Added subscriber: @ThatAsherGuy
I think we could take advantage of the tool system here. It's an easy way to dodge keymap conflicts and introduce niche operators without changing the learning curve. Add in a "Send To..." dialog that behaves similarly to the operator search dialog and you'd have a solid foundation for building new features.
It doesn't solve topic problem - ability to not only invoke, but also immediate sending to fixed number address.
However, I don't know how it is supposed to manage file wilth 1000 named collections list without such search dialog.
Nobody seems to have set such a task. You have 1000 names - you need a search menu to find collection or send selection - it is so obvious that it does not seem to have happened by chance.
The main problem of current collection development is that it follows a very strange way - like collections have limit in 20-30 of them.
We need to somehow convey the idea that it is already possible to make thousands of them, and all of this needs to be somehow managed.
Also, is seems, some steps have been taken in direction of M5 issue.
Now M5 shortcut can send object to somewhere (5th string in a menu), but pressing 5 will not show collection with that object, and you have to find it manually)
So, shortcut inconsistency issue seems to still remain...
Guys, I believe that we are really losing ourselves in a glass of water, because the two systems could really coexist, the "layer" system is a system of mere visual organization ... so it could also contain "VISUAL- 3D VIEW - ORGANIZATION more collections as well as objects "...
so in a sense, it is the 3D VIEW that contains VIEW LAYER, it has nothing to do with the Collections of object in itself ..
in this sense, it also becomes obvious, that every 3D View, can contain its local layout of VIEW levels ...
the outiliner and the collections have global value, so if you hide an object or a collection in the outliner, it's simple.... the object is hidden in all 3D View levels
in 3d view layers, objects can only be moved not hidden. when you select only one level, you are not hiding other objects, but you display everything that is only in that level view.
A very nice picture, that clarifies quick access slot concept.
It also depicts that QCD system can be built on top of collections system, bringing QCD's RAM speed access to Collection's HDD storage.
It also need wildcard match "Quick search" dialog to provide access to deeply located collections by their name.
it would be great!
I have nothing to offer, but I agree that collections and “layers” can exist together.
That would be convenient.
Described overall problems of current realization and latest solutions in that post: https://developer.blender.org/D5118#127263
Well, it seems, it is hard to explain the real need of QCD system without proper workflow example,
because it’s reason is related to UMC (User’s Memory Consumption) reducing, and does not exist out of context.
So, as it was told in Layers Maniphest, there are workflows, that requires QCD on top of collections more, than collections itself.
Let’s look at an average case, because simple ones have nothing to do with the topic.
Let’s look at the general process of building a scene using the example of historical restoration, which, as any other,
consists of two stages
Let's look at first one :
An example of historical restoration is interesting because of its unusual attitude to references.
There are several groups of references quality, such as drawings and photoes.
As a result, the photos do not coincide with the drawings, and we are forced to use both types of sources together, comparing them during process.
This means that we must place all kinds of references on the model in order to be able to make it, in the end we get the following picture:
But here is an obvious problem - you know, it’s kind a mess)
Basically, to even start to make such a model you need such abitities:
And all this for only one element out of thousands!
So, making such kind of objects does not even need all that infinite amount of collections, it requires the fastest way of management of several numeric slots.
Actually, management of combinations of them!
Well
The QCD system solves that just perfectly - it allows to control huge amount of visibility combinations of slots at a glance!
Here is GIF:
So, what we have got for now:
_________ A
Without QCD widget, managing all this things in outliner or that new “somewhere hidden or closing third of the screen” widget, it is impossible to finish the work without reading them in an amount the size of Tolstoy’s “War and peace”.
The work turns into a constant game of “find 20 differences from previous state you don’t see”.
Look how precisely you define the difference between this states because of human’s perception ability called subitizing :
This way abscence of QCD widget makes regular work incredibly hard.
_________ B
Without numeric acces there is no way to control all that states at all!
(it was a VERY STRANGE proposal from devs to remove numeric keys assignment. Also it is already removed from edit mode, so now we have to quit it any time we need to manage visibility.)
_________ C
As long as sending to slot number is not equal to invoke slot number (M5 issue), everything you sending with M5 shortcut goes to slot you can never guess because of those combinations mechanism!
Everything sent with the M5 is lost in the space-time combination paradigm!
Every management solution that was made in 2.8 makes you work with the only possible way - imperatively read and remember every time again and again,
raising levels of UMC to unprecedented heights.
read and remember to get involved to the scene
read and remember to send objects
read and remember to set states every time you trying to do so
read and remember to compare states
But human temporary memory is a very fragile thing - it’s hard to keep in mind even a couple of phone numbers for most people on earth.
So, even after a single day of such unnecessary reading and remembering and forgetting, human’s brain starts melting.
In such production like historic restoration with all those refs, or architectural modeling with inside structures, or gamedev asset making with all this LOD inplace producing and comparisons,
people need to make such operations with a maximum speed of their perception, to make thousands temporal setups and, probably, billions comparisons.
At the moment you can forget about changing state 20 times per minute, it will damage your health.
That’s the cost of using systems with high UMC level.
And that’s needed to be fixed.
IMPORTANT!
We understand power and flexibility of unlimited Collection's system.
We DON'T request go back to limited 2.7 layers!
We are asking for visual feedback and better control over current numeric slot system, because it will allow to perform a wide range of complex workflows.
Please, be careful with that.
Added subscriber: @Miamikichi
I agree with a lot of what Paul Kotelevets says. Collections are good but we are missing a few very convenient features. The old layer hotkeys were great but they only have a partial replacement in 2.80.
This is a problem for a fluent workflow.
Example:
My layer from a 2.79 scene was (correctly) renamed Collection 11, accessed with alt+1 in 2.79. In 2.80 the shortcut key for it is now 4 instead... which isn't unrelearnable, but that's not the point. I had it set to alt+1 because it contains very different things than layers 1-3. Not only is the mental organization more prone to mix ups since I can't use alt+number layers nor use my own numbers of choice to help logically separate content, but if I add even just 4 collections more - a stretch for my simple character modelling but totally imaginable for even slightly more complex scenes - I will be up to key 8, which is so far away it's hard to press with my left hand, especially if I need to use shift as well. Remember, this is a situation where quickness is the whole reason for hotkeys existing in the first place so hard-to-press hotkeys are always less ideal. Shift+alt+1 is dead easy to press and to remember, and shift+8 is actually a lot slower in comparison. The amount of layers provided was perfect for the scene in v. 2.79, and the current hotkeys for collections in 2.80 are a lot clunkier to use.
Well, a character modeling is really not the case.
The reason is - currently it turned just less fluent for character modeling, but in the same time it also turned deadly impossible hard for a wide range of concave/constructive modeling workflows, full of dynamic/temporal contexts that cannot be properly named to be controlled with collections.
Added subscriber: @HDMaster84
A bit about why it is important.
Quick access slots are widely used for multirefrenced modeling (when model have multiple types of simultaneous references, like drawings, photos, photoscans, pointclouds at the same time in the same place),
constructive modeling workflows (where are lots of unnamed parts and tightly placed groups of them - like in vehicles, engines, buildings, etc),
gamedev modeling (inplace LODs, stages, variations to compare and control)
etc
It is possible to use other software for simple modeling, visualization, realtime rendering, sculpting, simulations or animations, but it is not possible to perform such
complex workflows fast enough anywhere else - the problem is that quick access slots system is unique to the entire industry.
We were literally forced to switch to Blender because of it, to be able to perform such kind of workflows fast enough.
Removed subscriber: @brezdo
Removed subscriber: @nacioss
@ideasman42 since workflow issues are usually hard to explain, we made proper explanation video, that explains QCD system, and includes shortcut inconsistency issue description and solution.
We hope it will be interesting and useful.
https://youtu.be/yiti0xWO7Wg
Removed subscriber: @Hexbob6
Removed subscriber: @Thane5