Better ways to grow/shrink selections over a hierarchy, or even ways to move the selection up/down hierarchies I feel is a separate feature, but still useful/nice to add. As I’m sure you know, Maya calls it ‘pickwalking’
Instances yes, but the collection itself, the original, is a loose set of unconnected objects
Though there is an issue with possibly forcing a parent on collections, since a collection can be composed of objects which have varying parents…
In this sense I’m not sure it’s really possible to get them to work even similarly to your normal grouping systems - they’re typically locked in a state. Could be the best option is the ability to edit instances by using overrides - but that still keeps messy originals around, and adding a new object to an instance wouldn’t really work.
Actually, never heard, we don’t have a deal with maya setup.
But yes, it is nice example of such a thing)
1 Like
I think there’s nothing in particular that would not make it possible to convert a normal Collection into a Collection Instance.
Just like you can do manually by:
- Going to Add -> Collection Instance -> My Collection
- Move or hide original Collection
- Whenever you want to edit, jump back and forth between these two
Technically it works already, it’s just clumsy in practice. But it doesn’t have to be.
1 Like
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.
The main problem with hierarchical solutions is that it is difficult to predict how good they are without actual testing in practice.
1 Like
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.
Now full research map is looking like this.
4 Likes
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.
They are marked in table as Filtering. They provides common assigning and filtering, nothing about quickness.
I am referring to the image you linked.
Purpose
Quick Visibility Navigation
Dynamic Contextual Separation
The popover takes into account visibility navigation.
Menus takes into account dynamic contextual separation.
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.
1 Like
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.
1 Like
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.
Let me explain. By speed is meant speed.
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.
2 Likes
Ctrl left click on eye icon works like that in outliner.
It would be good to have that in collection popover, too.
But you can adapt filtering in outliner to only display collections.
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…
1 Like
You forgot the rubik’s cube in the Collections illustration. I was so sad of it that I added it in a dirty way:
Now I can leave this world in peace.
1 Like
