Also - a very nice solution from Michael Soluyanov
Looking like Group Pro, but doesnot messup with scene structure, using default abilities
2 Likes
Interestnig solution of Collection numeration from Dfelinto
https://wiki.blender.org/wiki/User:Dfelinto/Reports/2019#June_17_-_21
But the problem is that numeration 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) numeration independently of hierarchy depth, but with numeration starting from first level of hierarchy.
Static is looking not so fancy 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.
That should be dynamic, too.
Imagine that user changes is mind. He considers that would be more practical to move Flowers collections into Vase Collection and Vase Collection into Table collection to consider table and what is on table as a whole.
If you kept order of creation, things are a lot more confusing because you end-up with 8 corresponding to Leafs collection at fifth level but 9 corresponding to Rim collection is still at third level.
Imagine that user changes again its mind and decide to replace Car by a Truck. So, user makes an append/link of Truck collection and keeps Car during a moment to copy location of Car, and then, deletes Car collection.
If numeration is not dynamic, Truck is associated to number 10 and nothing is now associated to number 2.
OK with a system based on collection creation, user is always using same number for same objects during the session.
But how is it supposed to be simple, when user re-open his .blend file, 2 days, 1 week or 1 month after that session ?
It seems, it was terms confusing.
Static autonumeration behaviour is when all collections are numbered automatically starting from highest level.
It is shown on screenshot.
Dynamic autonumeration is when your numbering changes every time you changing hierarchy depth.
it is shown on gif.
If numeration is not dynamic, Truck is associated to number 10 and nothing is now associated to number 2.
This is not static autonumeration behaviour, this is manually assigned numeration behaviour.
So you’ve just asked to make static system, avoiding assigned system.
Well, it seems, we has got Ctrl+G buttons to further common grouping system realization)
A very nice!
34:40
2 Likes
the numpring can be indebindant for every nesting level for example
.1
–1
–2
.2
–1
----2 < that one
–3
.3
–1
–2
that way you have predictable addreses
sending an object to 212 means seconed root collection first nested collection in root and the seconed in that is the final.
it could ba anotated for large numbers as 10.15.7 maybe not user frindly it inclode alot of typing 
Yes, it is nice for fast sending
but, unfortunately, doesnot support fast switching (as in GIF with scull) for making comparisons.
https://devtalk.blender.org/uploads/default/original/2X/b/b8ce698024c2843f2f1fa8152a132135b412fec9.gif
I think a favorite system will work for switching. Where you have some favorite collections and switch fast between them with a hotkey?
I think all this can be made with add-ons as well
A lot of things can be made with addons.
As you may know, I have large toolsets (like 1D_Scripts) where are collected fixes research for a lot of Blender’s usability problems. (All of them are broken now, since 2.8 API Changes)
Basic usability things, like Extrude, Bevel, common Groups, Ngons support, and especially, that are unique for entire industry, like QCD and Collections, have to be built-in.
Because usability things makes soft more usable.
3 Likes
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.
1 Like
I use a blender as a (level/UI/scene) editor for my engine. The new collections system made it possible to greatly simplify the software part of my tools, due to the fact that collections are now objects (with their own properties, and so on). This is convenient from a software point of view. But in the process of working directly with the blender through a graphical interface, this significantly reduces the efficiency and speed of work. Although it looks clear in statics.
It is a pity that version 2.8 is already lost in favor of lovers of beautiful buttons and gizmos.
I would like to know the opinion of Comrade 1D_Inc regarding such a proposal:
Cells for storing collections in them. With the ability to add and remove cells.
(very crude surface idea to clarify the principle)
Just in case, I’ll clarify: This is just a proposal that does not pretend to solve the existing problem of organizing the scene.
UPD:
After thinking a little, I realized that the ability to increase / decrease the number of cells is a bottleneck, because It’s hard to come up with an obvious way to synchronize this phenomenon between different scenes of the same project. But this does not cancel the proposal to introduce this technique of grouping objects.
1 Like
In general, such a cardinal innovation as collections turned out to be so wretched that it raises a lot of questions and makes one seriously doubt the adequacy of the developers.
A well-designed grouping system can greatly expand the functionality of the program. For example:
It would be convenient to be able to assign one material to the entire collection. Or assign one stack of modifiers to the entire collection. This seems obvious.
Why it was impossible to design a hierarchy like this:
No master collection.
Instead of this:
Can anyone explain why this is not so, and what is the problem?
Well, it seems developers want to make a mess, that cannot be managed in that way.
They are making dynamic numbering with manual assigning, and we need to stop this mess in order to survive.
Why is this:
It can’t be like this:
?
That’s easy - because currently structure doesnot allow such placement.
That’s logical problem - you need manually assign number to collection, and in 1000 collections file those 20 numbered are dissolves just immediately, and you don’t know where are they, and what belongs to, so you need search tool for locating them in outliner and so on, and so on… Problems keeping problems.
Also developers want to make shuffle - change number of collection, based on current “depth”.
That’s brokes even possibility of proper QCD system.
I don’t like the idea to get the old layers back. It’s not visible what is in these things.
What is the purpose of the Master Collection?
It is not old layers, it is quick access QCD slots.
Master collection contains everything unsorted.
This system can provide possibility to handle and manage files with ~1000 collections.
1 Like
Here are proposals about global visibility functions in outliner.
The way to provide control for heavyweight (~1000 collections) setups.
A) Normal state - initial state of outliner
B) Ability to use ctrl+LMB outliner isolation as toggle, with restoring previous global state.
First ctrl+LMB press remembers inital state of scene visibility, and isolates collection, second - restores previous state of scene, stored by firts ctrl+LMB.
This will allow to quickly figure out what is stored in any collection.
C) Ability to invert visibility - to figure out what is hidden in scene. Red line is drawn in UI.
D) Ability to swap any column with visibility. This will allow to view and edit render/other state of objects of entire scene as visibilty for better scene handling and control. Column, that was swapped with visibility column became purple.
E) Ability to make everything visible via single toggle hotkey (maybe * key), to make sure what it contains during setup.
Here is GIF:
2 Likes
Could not be bettter make that proposals in outliner GSOC thread?
2 Likes