Hey @Lichen I read your answer on Right-Click Select and came here to see what’s going on and… WTF! I think I practically agree on every single thing you mentioned before (I could have missed something tho).
To be sure, I’ll just recap here how I think a grouping system should work:
To me, the main purpose of groups should be:
-
quick grouping objects together for transformations as a whole: select objects, CTRL+G groups objects together. Basically the same thing that you do parenting objects to an empty. But with one shortcut and not using a simple empty as a parent.
-
quick selection of objects as a whole: select any of the children selects the group. This should be an option. I agree with you that It should be a toggle, IMHO possibly per object (like “open/close group” or “lock/unlock group”), but as @Claus suggested, it could be a global option. I’m not sure what’s the best solution.
-
visibility toggle inheritance: hiding the groups hides children as well, right now, animating visibility of dozens of objects must be done one by one (afaik).
-
bulk deletion of children: By default, deleting the group, should delete the whole hierarchy. There are cases when you don’t wont that, and it could be just resolved with a prompt on delete (Delete Hierarchy - Delete Only Parent ?). Right now you can do that by rightclicking on parent in the outliner (Delete hierarchy).
Now, my Ideas on how It can be implemented:
I think that collections are a completely different system than groups and made for different purposes and they work great right now. I think groups should be a completely separated concept and should not be a funcitonality extension/option for collections. I’m pretty sure that It’s possible for Groups as described so far can live together collections without any conflicts.
Even if you see groups like tags, if you limit just one tag per object, I suspect that they are still strictly hierarchical (in terms of logical organization), like folders. Any way In my opinion groups should be hierarchical (as opposed to collections) both in logical sense and also regarding transformation hierarchy. So that’s cool!
My first Idea was to make things very simple and not involving a new type of object, but rather create a couple of new empty display modes: “None” to just display nothing, and “Bounding Box”, which is basically the same thing you want implement with an empty mesh for the python prototype.
All the rest is about using the existing parenting logic and extending it a bit with all the functions mentioned before : automatically creating the empty and parent the objects with CTRL+G, adding all the functionalities to the empty like make children inherit visibility and every other useful property, adding the “open/close group” functionality ecc.
To me this is the bare minimum to give a great boost to blender usability and grouping with “minimal” design revolutions, and probably (I assume, but I may be completely wrong) with higher chances of not being rejected.
Of course I thought about the functionality of assigning modifiers, materials to the whole group at once, but that has a serious shift in design complexity, and it certainly can’t use empties as a parent object, at least not as they are.
It probably needs a new “group” object type that supports modifiers and material assignment, but still, this is huge and hides dozens of design questions.
Some examples:
- what happens if you group different type of objects and then try to add a modifier to the group that is not supported by one of the group members? (eg. group of a curve object and a mesh object, and you add a displace modifier)
- what happens if you group objects that already have modifiers and add a modifier on the group? Do the children modifier get overridden? Does group modifier stacks on top of the children ones? It needs a design regarding the stacking rules