Added a hierarchical systems comparison table at the end of topic post.
I’m in doubt about assigning numbers to 20 collections.
Automatic (Current behaviour) is more transparent, less flexible.
Manual numbering is more flexible, less transparent - it is easy to lost 20 collections in 2000.
Analysis about Groups interpretation, pickwalk and Cumulativeness.
Cumulativeness - ability to assign the same object to different hierarchical structures, I didn’t found more appropriable term for this.
Here is some hierarchiclal structure, and behaviour prototypes.
Cumulative object dependency here is the same object in different collections.
It seems, cumulativeness completely breaks Grouping interpretation.
On my mind, 2nd variants are more suitable as result for pickwalk ability (A2, B2, C2)
I don’t know if it will be useful to have ability to pickwalk select collection without selecting sub collections.
Also, it seems there no way to find origin collection of a linked collection, if it’s name were changed.
Hierarchiclal research is updated.
As far as cumulativeness kills grouping representation, added two new modes to for consideration.
Manual marking Collections as Groups, and AutoGrouping, that ignores Cumulative elements.
I think that current problem is more a lack of features to manage hierarchy of collections than a real need to have QCD.
Actually, if you want to isolate a nested collection, collection visibility popover requires that all objects not included in that nested collection have to be under another nested collection at same level.
There should be an item for uncollected objects into this popover.
When I simply do a left click on Circular collection, Cube is still visible but it should not be.
Shift G menu to select all objects of same collection does not take into account hierarchy, too.
It proposes all collections in which object is immediately linked.
But if these collections are just nested collections, there is no way to select all objects of collection at a more global level.
In topic teprms this sounds like you also want pickwalk, but also in doubt about cumulativeness.
Check up research map for pickwalk prototype behaviour.
QCD is a separate system, it cannot be replaced with pickwalk, they both can be implemented as far as they solves different tasks.
Well, collection visibility is LayWALK feature, it is pretty much weak concept for unlimited count support, but on your screenshot everyting seems to be correct. Cube should be visible because it is collected to Meshes collection, that is turned on.
I think that you are neglecting the popover and M, Shift M, shift G menus that are allowing a quick workflow.
IMO, that are just a little insufficient in their actual form.
Just completing them a little bit should make collection system satisfying in terms of speed.
Well, if something contains popovers (aiming with the mouse to some GUI elements) it is already cannot be called “quick”, because of limits of human’s perception and body, it have “common” status.
Like any other menus and popovers in program.
But it is totally ok - some workflows does not requires enhanced quickness.
The popover is simply an extra click.
There is a strong probability that a widget for QCD would also end-up in a popover of header or should be a closable floating panel.
In terms of CG Workflow Design, The popover is “Aiming to menu call button, press, then [seraching name], then aiming, another press”. That’s why it is a common operation, like in any other menus.
It can be repeated 10-15 times in minute, while QCD nums allows about 100.
But, again, it is totally ok - some workflows does not requires such enhanced quickness.
Widget for QCD will not help to Collections mostly because QCD and Collections are heterogeneous systems with different capacity (20 vs infinity).
QCD widget with anonymous slots can be the only part of QCD system, so it is possible, but will not replace popover.
Collection visibility popover supports click&drag like 2.79 layers.
2.79 layers were problematic, too. If you did not remember on what layer you set an object , you had to select object, go to its properties or browse layers to find it.
In 2.8, nothing prevents user to keep a reasonable manageable amount of collections included in a viewlayer and to multiply amount of viewlayers.
ViewLayers feature was main point of first viewport demos.
These ones deserves a shortcut to cycle through them.
With no popups, no aiming GUI, no names searching, no shifting, no holding - pure speed at full control.
It is required by some workflows, like multiple inplace LOD comparison during editing, and others listed in the topic.
A simple example, It will be incredibly difficult to make the same visual comparison of a set of models when using any kind of GUI, independently of how much profound it is.
In 2.8, nothing prevents user to keep a reasonable manageable
Unless if the scene did not come from another user who did not care about it.
Quite a frequent occurrence, when deadline is yesterday.
I agree 2.8 requires extra-steps to put in place fast display.
But if you take that 2 minutes to re-organize a little bit outliner, you can work efficiently during 2 hours.
There are no GUI solutions, that can be faster, because of mathematics.
As said, it was a simple example.
But we are talking about really massive production workflows.
Hundreds of files. Thousants of models. Tens of thousands of elements and variations derived from different programs, perhaps billions of comparisons throughout the entire production process.
The question is simple - to bring those billions unnecessary aimings, searchings and menu calls with GUI or not to bring.
We who have been working in such conditions for quite a long time, our answer is no, please no more, we have families, we just want to live sometimes…
Obviouly, it was not forgotten, but lost, because blender doesnot have common grouping system yet.
So everything there were right.
The cube is hidden between the paws of a lion as a sign of seamless integration.
For me it’s better to make a separate type of object - “Group”. I think it’s better because it can uses it’s own “Edit mode” instead of empties. And then replace empties with collection instances by this “Groups”.
But of course the main problem with collection instances is that then you want to edit collection in instance, instead to pressing tab to enter in edit mode (like in node groups and metastrips) you need to search collection in outliner, move camera to this collection, change visibility settings of all collections (or use local mode) then bring camera back - so a lot of useless actions…
I love group pro, but I really want this functionality in master, fully supported and guaranteed to work forever, even when Group Pro is no longer updated.
Also - important - fuction to inverse visibility is needed.
That will split scene into two global “slots” (visible vs invisible) with ability to switch between them.
Maybe Alt+Ctrl click on any eye sign in outliner.
That will give full fast control over hidden objects of entire scene.
A very nice tool for vertical (hierarchical) scene navigation.
