You’ll have the group of objects as child of the top most parent.
I’ve never used C4D. In Maya, the group becomes parented to the old parent.
I don’t see how this is relevant. We don’t need a grouping system from Maya, or from Max, or from wherever. We need a grouping system that lets us box the objects, transform them as one, modify them as one (as much as is applicable), refer to them as one. With the ability to unbox them (temporarily or permanently). Within Blender, interacting with the rest of Blender.
You can break most anything in a few clicks. You can brick your PC with a few clicks if you’re feeling creative. Is that a valid reason to not make PCs anymore?..
5 Likes
Sounds good to me. Additionally I’d like it to be robust.
So, now, develeopers. Do your thing. 
3 Likes
Where do i sign?
1 Like
Right in Machin3Tools tread 
2 Likes
I would think that “boxing” the objects into a single unit (as far as scene management and workflows go) could be done as an enhancement to the collection concept (ie. making some collections more than a simple category of independent objects).
The devs. would of course need to figure out how to handle non-boxed collections nested inside the boxed ones, I guess you could have the nested ones boxed with the parent collection by default and be able to unbox just those objects. Like the Blender UI concepts, I do not think the idea of collections has been fully explored by any means (since the Blender devs. often don’t push anything to its full potential right away).
I’d be more cautious with that. Too many eggs in one basket - something’s liable to give. Better have separate concepts working well within their function than one gigantic thing not working well with anything.
So do you believe then, that some workflow concepts are better off as a set of rigid and blackboxed rules?
This would contradict what the Blender devs. along with other projects have been working towards, more flexibility and less rigidity, which means more choices for users on how they want to approach a given project.
One way that is accomplished is to reduce the number of terms the user has to learn (through the combining of similar, yet different concepts that can’t be combined or mixed). I also don’t buy the argument that if collections was a proper system it would crash, are people now so accustomed to commercial apps. crashing all the time that they now expect unstable and low-quality code as a condition for viability?
No, I believe that one should be cautious with delegating too many concerns to single entity. That quickly becomes hell to maintain from programming standpoint, thus liable to break for the user.
See, to my mind, a group would be something of a cross between an Object and a Collection. It would need to be able to contain hierarchies, but also participate in hierarchies. It will need to have proper origin, and not the obscure offset property tucked away in an obscure panel, half-married half-divorced from 3D cursor. It will need to support modifiers, constraints, and perhaps even some semblance of edit mode. Could it all be put onto Collections? Perhaps. Should it be? Perhaps not. That’s something that needs careful consideration.
I think we’ve finally grasped the roots and borders of this problem. Let me try to summarize.
- There seems to be a certain (i will dare to say large) number of people, asking for this lightweight, fast organizational system that exists in a vast majority of apps, some of which have it developed to a very high degree of usability (a first hand experience). This is mostly used in static scenes such are urban scenery, architecture, interior design, some forms of engineering and amateur modeling and concept generation, that do not require a lot of movable objects but consist of a lot of repetitive static elements (rows of windows, fence posts, chairs around tables, plates and glasses on the top of the tables) that are often required to have sharing the same datablocks for easy later variation of the swaths of objects at once. Fit for sequential nesting, consisting of up to tens of thousands of entities, mostly not named (for obvious reasons), not fit for searching in a list but mostly selected BY ONE CLICK visually in 3D view and quickly manipulated just as standard Blender objects are. Without the need for parenting, constrains, vertex painting, criss-crossing an zig-zaging. Simple bundling. An organizational entity most commonly known as - a group.
For the sake of the argument, let’s give it a new name that has sometimes been brought up - a container.
I personally, have built whole city blocks with this simple concept and manipulated, multiplied, instanced and transformed it’s sub - elements with such ease that i still haven’t found since i came to Blender. And this is the system i miss and crave for a decade now. My speed for manipulating organizational groups of objects has been cut to a third coming to Blender, and years of practice did not enhance this a great deal.
- On the other hand, there is a wast majority of Blender users looking for advanced and flexible organizational systems that support every bit of existing modifier assigning, constraint applying, library linking and overriding capabilities, primarily made for animation and complex interaction that simply can not be ‘shoved’ into a simple container system because such a system would not allow any of the before-mentioned technologies.
TO CONCLUDE: The existing capabilities of Blender that are preventing the introduction of a container system are the very ones that the users of such a system would rarely use. In other words - either we have the Blender for movie production, with all the bells and whistles and without the container system, or we have the Blender with the container system, preventing the bells and whistles. Right?
I may have an idea:
WHAT IF we take an certain IF approach?
Let us say we start to experiment with a certain type of “right of passage” principle. A capability reserved only for such collections of objects (why not, it could be the collection entity that already exists in Blender) that fulfill a certain set of RULES. We decide what the rules would be. No sharing and intertwining of members, no cross-parenting, over constraining and whatever you already mentioned. You name it.
If the user obeys this set of rules while generating such a collection, and the program verifies this is the case, this specific collection of objects is given a certain “mark of pureness”. Or this mark can be given at the making of every collection and simply revoked when breaking one of the rules. Otherwise, the collection remains “pure”.
Now, by the logic of all things said in this and other threads, and somebody please correct me if i am wrong - such collection is TOTALLY FIT TO BE A CONTAINER ENTITY.
It can be “boxed in”, behaving as a single object, it could support fast transformations, i presume - unlimited multiplication, copying with linking (instancing it’s members with the members of the source container, with the possibility to ‘open’ each and every linked container at it’s place thus changing all others linking to it). Bare-bone Blender functions that all multi-app architects, archvis artists, urban developers and amateur modelers look for and are used to. And this is a great deal of people in DCC.
And guess what - this rule obeying procedure wouldn’t be any different to the way i personally was already doing things in those other DCC apps. Actually, i would do exactly that. Each object would be a member of only one collection (in other apps known as layer), without any complicated parenting and constraining relations to any of the members of other collections. I would obey all the rules because i am already used to such a pipeline. I myself, don’t need a parented, constrained object belonging to multiple collections. I need a group.
A special, pure, cleanly built and nourished collection, by the conscious choice of it’s user. A collection ready for blizzard speed, simple hierarchical buildup and transformation. A SPARTAN COLLECTION, that can not only survive all the acrobatics of the container system, but is made for it by it’s user.
THE PROCESS
We can experiment with such a system inside a separate development branch at first, just for proving its validity. A developer could make this addition, bare bone at first, just enabling a single-click on-screen selection of such container entity, with it’s members stripped of the bells and whisthles at first and work uphill from there, gradually introducing features from standard collections that prove itself not threatening to other organizational entities now existing in Blender and viable for further development.
At this point, we would already have a whole new organizational system in Blender, benevolent to the rest of it’s existing architecture that would satisfy a wide range of users. Further on, as new capabilities are gradually introduced to this system, the amount of people using it and building their environments to it’s requirements would increase. Linking datablocks would follow, then probably modifiers, then limited set of parenting etc., as long as the whole Blender ecosystem is preserved.
2 Likes
I hadn’t noticed this thread. It’s good that people are actually suggesting improvements instead of just complaining about the state of grouping, which I agree is very imperfect.
I don’t think collections are good candidates for “group containers”/“parents”. My reasoning is : many of the systems that use collections (cloth, rigid bodies, dynamic paint and other physics systems, boolean modifier, instancing system, etc) rely on the fact that they don’t have exclusivity over objects : any given object can be in several collections. Removing this possibility would break those systems, as well as scene management (visibility/renderability), and it would be a regression over 2.7x groups, because those already allowed objects to exist in several of them.
On the other hand, we can’t make collections into actual, selectable and transformable objects because then what would happen to objects part of several collections ? which parent would they follow ? There is no way to answer this : the parenting system would be broken.
This is why I think we have to keep both systems (parenting, and the tagging system known as collections), but 1. improve parenting both functionally and visually, and 2. improve interoperability between parenting and collections so that we don’t have to juggle between two systems to do simple things (ie manage transformations and visibility at once).
In order to do this, I suggest a very simple thing : that grouped objects not part of a collection (other than scene collection) simply inherit visibility/rendereability from their parent. This way, hiding the parent will hide its children, like so many of us expect. This would allow to work completely disregarding collections, and keep transform and visibility linked.
Full disclosure… this is exactly how Maya works : you can just work from the outliner, grouping objects to your heart’s content and objects will always inherit visibility (this can be disabled, but it’s another subject). However, as soon as you add an object to a view layer, it will obey that layer’s visibility settings.
There is indeed no “tabbing in/out of the group to edit it”, but I don’t see how that would be helpful since we can just edit objects directly ? I may be missing something ? (Come to think of it… that would be a great addition to collection instances wouldn’t it ? node groups already offer this functionality, and they’re conceptually the same thing.)
Children objects could be highlighted as well whenever you select a parent -as @Romanji noted, this exists in Maya and is extremely helpful to see at a glance what’s part of the group and what’s not.
Hello!
I created a plugin for this workflow, you can try and test it for free:
4 Likes
Now that 2.92 has been released, I think it is a good time to continue the discussions.
While the requirements as listed by Okavango are what the users are expecting from a simple grouping, perhaps one of the main reasons behind the reluctance of the blender developers to tackle this request is related more to the rationale behind the request rather than the clarity of requirements. Anyway, I made a comparison with the existing parenting and collection systems which you can see in the images below. Obviously, none of them is achieving the goals of the grouping, but both are providing partial solutions. (I avoided for now to suggest any shortcuts for the grouping functions because they are assigned to the parenting system, so, most probably they will need to be changed. I would set the start of working on this request as the primary goal leaving the shortcuts to be discussed by the blender devs).
I’m sure they will have questions like “What happens when …” using the parenting system as reference. I think we should provide some of those answers in advance, as part of the requirements. For example, when asking “What happens with the transformations of objects when ungrouping?”, the answer would be: “Always ungroup keeping the transformations.” Therefore, could you provide some more complex use case scenarios where the grouping system should behave in a certain way compared with the parenting and collection systems?
That is EXACTLY the Idea I had in mind.
I’ll add a couple of ideas:
-
Implement two new types of empty display shapes: one that depends on the bounding box of all children, useful to have a visual hint in viewport of what objects are grouped together. It could be a bounding box, or just the bounding box corner. And another one that just draws nothing, if you want it to be invisible by default.
-
The select part of your first attached image could maybe be optional, and ON by default? Like an “Open/Close” “Lock/Unlock” toggle on the group, that is set to ON when the group is created. The toggle control could be on the outliner, properties editor and even accessed by W/right click menu in the viewport (depending on the keymap).
-
On the selection part: it could also be implemented just selecting the parent, when clicking on whatever child object, instead of selecting the whole Hierarchy (For transforming purposes).
But for Deleting blender should select the whole hierarchy behind the scenes before performing the operation. Example:
What happens when you select a group and then delete it? Click on one of the children objects in the viewports and blender just automatically selects the parent, then hit x or delete in the wiewport and blender automatically select all the childrens recursively and perform the delete action.
If the selection is performed as you designed it, then what happens if you select the group and rotate on local axis mode and around individual centers? Is it the expected behaviour? -
Viewport and Render visibility inheritance and animability: I know that you can ctrl+click (or shift+click? I don’t remember) on the parent toggle icon in the outliner to toggle the children visibility in one click, but this can’t be easily animated. It would be great if there was an option on every object to to inherit parent’s visibility. Then what happens when you create a group from selected objects? they get parented to a new empty as you suggest, and the “inherit visibility” toggle is set to ON on every child object.
-
What happens when objects in the group are animated and get un-grouped?