Yes, parenting is easy, that isn’t the function and workflow of quickly grouping objects though. Also that is “easy” but way too many clicks and steps to do something that is “easy”.
Thank you Herbert123, I see that it sort of does what I want
The core of how easy this is in Maya and how and what happens when you auto create empty node and parent the selected items to it. Here is the Maya documentation to explain
Also that script is outdated but it works fine as a start just had to update the header to say 2,80 and while it needs to have some changes to it as well, it is closer to what a Maya user would expect out of being able to quickly create a hiearchy out of selected nodes.
Blender can’t have proper common groups based on collections because Collection system is cumulative - same object may belong to different collections.
Collection instances are too complex to manage.
Parenting does not matches grouping because parent object is the only way to manipulate hierarchy.
Group Pro breaks backward compatibility, so it is impossible to use its scenes in vanilla Blender.
You know, an idea came to my mind. There was a suggestion on RCS to be able to ‘lock’ a collection so it could be selected, manipulated and modified as a single object. The problem was that, as you mentioned, the system is cumulative and this could lead to problems.
What if - you could actually do that to collections that contain only unique objects? The program would count the collections’ memberships and if all containing objects belong to only a certain collection - ‘locking’ into one entity would be allowed for this specific collections.
This way, all the user should do if he wanted to use collection selection is keep his relations clean. If he wanted that, he would be careful. And when the containing objects would be assigned to multiple objects and the rule was broken - the program would notify the user, break the lock and disable that collection from ‘locking’ and return it to normal behavior.
Common groups are usually forces dynamic context (I want to group that, that and that one thing) rather than static (I want to group all the trees in a scene)
So, they can follow collections structure in a static context, and this can be useful, for sure, but I am not sure that this solution is flexible enough.
For example, in Sketchup, 3dsmax and Group Pro groups are common group realizations that follows dynamic context way. And it would be nice to get rid of using Group Pro already, since it makes files unusable without this addon. So common groups usually creates their own hierarchies in the most of the software to saltisfy flexibility demands.
Not sure that hierarchical concepts can be over-analyzed)
This ensures the mathematical completeness of the concepts.
Yes, one could argue in that direction. I also made a fairly broad analisys of the layer / group / collection concepts in some places.
However, this is a suggestion that uses the context that we have at the moment. Untill an effort is made to make a real grouping system from ground up.
We could always automate the group creation process to verify the possibility, make the collection, ‘lock’ it and hide it from the collection list.
So, when I am talking about scene complexity it is not about my scenes and my setups, I am talking as a project manager that works with setups made by other artists.
From my experience, artists are pretty much bad at creating clean scene hierarchical structures, so their setups almost always falling into mess.
Thats why I putting lots of efforts to make hierarchical systems clear but flexible in order to survive complex projects.
Collection engine is too much overloaded already, so I can’t say that putting grouping ability to the static context - to collections - is a good idea.
The ability to turn non-cumulative collections to groups and work with them as with groups is nice to have, but, for example, the process of creating collections by grouping whatever random selected objects will bring the need to separate regular collections from created as groups, otherwise we are mixing static and dynamic context separations in the outliner.
Thats why all other software that provide common grouping handles groups separately, keeping outliner clean.
From the one side, separate groups engine is industry standard, that will possibly bring some formats compatibility, from the other side, collections are needed to be handled as groups, and separate groups will not have rtos (otherwise rtos management will be split to impossible to properly controled mess)
So, in overall, there are too much things to design, to anticipate and to think about.
Well, if you are indicating that because of that fact the suggestion is not viable we have to have in mind that the artist will not be able to generate the group if he does not obey the rules in the first place.
Suggested the former as the means to use what we have at moment, which is right now arguably better then nothing.
Although the existence of the division between static and dynamic content is a fair observation, i am not sure it should be pushed so far along as to determine viability of pipeline ideas. In my professional experience these two categories often overlap and interlock.
I hope you have observed this part of the fore-mentioned discussion.
Well, we can always shy away from suggestions in the light of analysis, some of which, in the astronautics business, indicating that propulsive landing of a first-stage rocket buster is not possible.
I am not entirely sure what do you mean.
Yes, I read that part of discussion and I glad that it corresponds with Layers Maniphest.
But the difference between us is that when your the most complex projects cosists from 80 layers, we are working with 4000-8000 layers projects on a daily basis.
So, for us the consequences of wrong decisions will be different.
4000 - 8000 layers? Named layers, on a scrolable list?
Surely, you mean groups of some sorts? If not, if you don’t mind me asking, what kind of projects exactly are we talking about, and what applications manage this?
For sure, named lists (with properties like visible, freezed or plottable - like rtos) in Autocad. We just don’t counting groups, for example, in Sketchup and 3dsmax, because don’t care about their quantity.
We are making cities, actually.
Not quite sure what to say to that, honestly
If you can find your way in such sea of entities, i can’t see a scenario that ‘sealing’ a certain number of collections for selection could make worse.
We are actually making sure, that system will allow comfortable work with more than 200 collections.
For example, that’s one of the reasons why we are making Collection Manager toolset.
Unlike other systems, like Autocad, we can’t even use 2.8 because of collection engine issues - it is a system that supposed to create an infinite amount of collections, but its management efficiency is limiting that amount to 20-30 collections.
50 are painful.
200 are impossible to control in reasonable amount of time.
We designed special framework to work with that amount of layers in Autocad, thats why it causes no problems.
Now we are trying to make the same thing for Blender, because devs make all those mistakes we know about.
So we know that there will be a serious issue.
And it is too easy to create an overcomplicated system, that will make even the possibiliy of comfortable work with large amount of entities mathematically impossible.
Empties are not suitable solution, because you need to select empty every time just to move a whole group.
Common groups allow to view/select/transform a group by selecting any grouped member - immediately
