The same switch can be made between render visibility and viewport visibility, to view what actually will be rendered as visible objects, control it with visibility switch from picture, and then switch back.
This way visibility can be the map for displaying different unobvious properties like render visibility.
Can be the solution for an issue.
We made such switch system for AutoCAD, and it is nice if it properly marked, we have full control over visibility and plottable state of thousands of layers.
We can switch in, edit plottability as visibility, and switch back.
In the Eisenhower matrix, this is how the switch looks like.
Here is an example addon, an example of swap/invert modes.
First button inverts visibility state
Second - swaps visibility and renderability
Object visibility can be inverted or swapped, that gives ability to view rendederability of objects as visibility.
Personally, I would like to prefer columns switching, to define mode (first column is for changing value by visibility), that will make things more clean.
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.
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
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.
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.
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.
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.
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.
