Yeah, parenting to an empty to each collection would be similar to what folks do with CATIA. If all collections by default had a transform/empty parent associated with them, which we could have a checkbox to disable, it would be a bit more intuitive for things like instancing and we would have a handle to manipulate in the scene. We’d need the outliner to recognise the enabling of the empty and separate out the geometry collections (with transforms) from things like collision detection collections and view layer visibility toggles.
I think this is what this thread is blundering towards? That would not be a huge job and would not break backwards compatibility or introduce another feature to manage.
1 Like
The direction right now is more Or less what you describe but without involving colections. The parent empty will already represent the group entity, so no need to automatically assign it to a collection.
This workflow is already common in blender and every other 3d software I can think of, it’s all about streamlining it and extend it with more features like inheriting groups modifiers and marerials on children.
As already mentioned, the current idea is to keep the collections original purpose , which is replace old blender’s layers by extending what blender used to call ‘groups’.
The maya’s behavior with layers/groups by @thinsoldier is a good analogy here. Maya also has Sets that can be used to group objects for other purposes, without Affecting parenting hierarchy.
In blender you manage visibility and other purpose organization with collections without affecting parenting hierarchy, wich is great in my opinion.
2 Likes
Collections already have an origin that is used to define the origin point of Collection Instances. There are several ways to change it to any value you want. It would be great if there was a way to easily see and move the origin point you have set on a Collection.
The complication is that an object can exist in infinite different collections. This is why I would prefer an official concept of “groups” where the group members cannot be a member of more than one group AND a concept of “group instances” to go along with it.
The thing annoying me the most lately is lack of finalized support for Collections in the Asset Browser. This is more important than groups to me and it’s a royal pain that it seems it’s not being worked on at all.
1 Like
Thanks @thinsoldier and @RiccardoBancone for helping out explain what functionality we’re aiming for. I was away on vacation and was happily detached from my computer. Haha. I’ll be starting work on the prototype / nailing down features and design next week. Looking forward to it and I’ll keep the first post updated with the specs and add new posts with prog updates 
1 Like
I don’t remember if I posted these in here already:
I haven’t read everything that’s been described here so forgive me if I reiterate anything that has already been touched on. I was just in a hurry to join the discussion as this is something that has been bothering me for a long time with Blender. I remember the Blender Today mentioned in the initial post this one was split form and it actually made me a little mad when Pablo couldn’t quantify what groups are. Nothing against Pablo by any means. It’s the idea I have seen echoed so many times over the years that made me mad. The idea that what is done in other software is bad. I thoroughly understand the need to do things differently. However, some things are done a certain way because it just makes sense, or are typically ubiquitous. Groups is one of these things. Every time it is brought up the immediate respnse is “We have collections”. Which is not an answer. Collections are neat, but they don’t do the job. Anyway, I say all of this just because I feel one of the biggest drawbacks of Blender is the inability to work with assemblies in an intuitive manner.
My solution was to change how we interact with colletions as opposed to introducing a different data type. I was able to create a very simple addon that when enabled double clicking on an object selects the rest of the collection it belongs to. I wanted to eventually further expand this to enable it to select any child collections as well. Also I wanted to eventually expand it so that if you select all the objects in a collection and duplicated that collection, or copy and pasted that collection, that it would create a new collection with the “xx.00x” naming convention that is default to Blender. Essentially using the “Duplicate Collection” command in the right-click context menu of the outliner. However this is all above my ability and available time. The addon as it stands is just a glorified hotkey with a button on the UI to toggle it on or off and it only took a couple of hours to make. The ultimate point is the approach I took is to just change how we interact with collections seems to be the less intrusive route. I went this direction because one of the typical responses is “Collections already does that” which also drives me nuts, because while collections do a lot of things, there are also a lot of things they don’t do. So for simplicity sake I decided to try and just change how we interact with them because that is seemingly the root of the problem. As well it seems much easier to accomplish as all of the functionality is already there, it’s just the interactions that should be more surface-level are hidden in menus making them the convoluted work flow, and thuslly less intuitive.
Anyway I hope my point of view adds something positive to the conversation. I’ve been begging for a proper grouping system in Blender for a long time now as it continues to be one of the things that makes Blender difficult to use for large projects.
6 Likes
Thanks for chiming in William!
I think having the ability to interact with collections in an improved way is definitely a good thing. Thanks for assisting in that arena!
I do think that having a different data type called group would be helpful. The reason being that collections can contain objects that can exist in other collections. So they’re not purely hierarchical. The benefit of this is flexibility, with the drawback being simplicity.
If you’re trying to apply things like materials, or modifiers to a collection, you quickly run into problems of priority. How can you determine what to apply in what order since there is only one object, and there are multiple collections telling it what it should look like / behave.
Having said that, it would be great to have both the flexibility, and the simplicity of having one data type. So I’m totally open to discussing enhancing collections instead of adding a new group data type.
What do you think?
I totally agree with you on a new data type. It is actually the correct way to do it. I only ever started thinking about changing the way we interact with collections as an alternative because 1) Every time someone says “Groups in Blender when?” 20 people scold them and bark about collections. and 2) It was far easier for me to implement and it also perfectly suited all my needs. Which is to be able to interact with complex objects in a more intuitive way.
As well had I ever been able to get it working exactly how I envisioned it. I had hoped that it would then let the naysayers see exactly what we’ve all been begging for all this time now. (which I think is close to five years or more I think at this point) And hopefully would inspire someone to do it the right. For my endeavor, it was just about getting the proof of concept out there and also improving my own workflow in the process.
1 Like
The problem I always see is nobody every considers the ability for 1 object to be a member of multiple collections. We need a way to formally say “this collection is mutually exclusive and does not allow its members to also exist in other collections” in order for collections to actually be used as “groups”. I would prefer if collections stay the same and we add an official “group” concept.
Yes it will be 90% identical to collections initially but as we add more needed things around groups we won’t have to waste time figuring out what to do about collections default ability to have the same object in infinite different collections. – groups, group visibility, group renderability, group instances, origin point of group and group instances, etc – Basically, once we have real groups, nobody should be using collections for anything except its ability to have an object exist in multiple collections for organizational / search-find-ability.
For example in a scene with 2 houses I have a collection with all plants of the first house, a collection with all plants of the 2nd house, a collection with all plants of both houses, a collection with all back yard plants (per house, per back or front yard, and in total), a collection with all plants that use a leaf material with sub surface scattering and another collection for those that don’t (per house, per back or front yard, and in total), all trees, all bushes, etc etc etc. It makes finding the exact sets of objects I want in the outliner very very convenient, almost like doing a database sql query.
However I doubt many people even make use of this ability of Collections. I don’t think we need to shove grouping into that. Grouping should be its own thing. I say actually achieve the functionality and UI goals originally planned for collections to 100% (it honestly feels like they have been ignored since launch of 2.80) and then close that door and lock it and start working on groups that behave like whatever software has the best grouping system, probably 3dsmax or sketchup based on conversations I’ve seen elsewhere.
2 Likes
And have groups apply modifiers, materials etc. 
2 Likes
@thinsoldier @William-Hurst @Dragosh
Real good discussion everyone!
I think we’re all on the same page now.
Add groups for true hierarchy, selection, local pivot points, instancing, materials, modifiers etc.
Keep collections, enhance them, and narrow their focus to render and scene management only. When we ask about the grouping features we want the response should be “we have groups for that, and collections for scene management.” Their ability and to have objects and groups exist in multiple collections will be extremely useful for render and scene management (for compositing, and handling visibility etc.). If there are ways we can enchanted this focus I’m definitely into that as well.
Y’all down with that!?
2 Likes
To be honest, if you think about it, collection instance is almost exactly what most of us would expect from a group. Something you can treat as a single object, but which contains multiple objects.
The giant drawbacks of collection instances are that you first need to have an original collection to instance, and that it’s difficult to transform collection instance’s origin.
Instead of adding a new group feature to Blender, and dealing with complexity of having groups and collections side by side, with partially overlapping features, why not just use the existing collections concept, and expand it:
-
Add a new “collection object” (WIP name) to collections. This would make collection to appear as a physical object (empty) in the viewport, which would allow us to set the transform of the collection.
-
Collections set to be objects (as opposed to default, non object collections) could be opened and closed.
-
When closed, any objects inside them would be treated as one object, with the origin/pivot being the collection object helper)
-
When opened, you could interact with the object within the collection individually
An example workflow - You have a robot arm made out of 50 pieces you want to group:
- Select all the arm objects, and add them to a new collection, call it “Arm”
- Right click on the Arm collection, and click “Switch to Collection Object”
- A helper object appears in the viewport. Move and rotate it into the position where the robot arm shoulder joint is placed.
- Right click on the Arm collection, and click “Close Collection Object”. Now the entire arm collection is treated as one object when selecting.
- To edit the contents of the Arm group, right click the Arm collections and click “Open Collection Object” - now you are free to select the individual objects as you wish.
- To “ungroup” the arm, just right click the Arm collection and select “Switch to Collection”.
Yes, that’s the most logical way
Restructuring a existing data type (collections) to serve a different need would create more issues than just creating a new data type (hierarchy - group).
Keep collections as they are and ± expand on features exclusively to collections, that will lessen the chance of thing breaking compatibility (as opposed to turning collections in to something different).
Creating a new data type would be a “clean start”, it wouldn’t be compatible backwards but you will have more stability and control over it’s changes (groups).
At least that’s how i see it
[i hope i used the term Data Type correctly 
]
1 Like
I think that conceptually, creating a new “collection object” as you describe it is basically the same of creating a new “group object”, just with a different name. One still have to design and implement a new “kinda object type”.
I don’t know at coding/implementation level what’s the best.
Anyways good points and examples, as I probably already said in this thread, That’s exactly how I would like groups to behave, just replace the words “collection object” with “group object”. Plus the possibility to hinerit visibility/renderability toggles from parent to children.
A problem comes to my mind by the way, if collection are used to obtain the behavior you describe. What happens if an object A belongs to multiple collections , and they are all marked as " collection object" ? Does The object get Instanced multiple times? (One per every collection object?). You still have to deal with complexity, I’m not sure it’s the best solution.
I think I agree that it’s better have the behavior that you describe, but using a new object type, that is not a specialization of a collection. Just an “empty on steroids” that gets automatically created when you select object and press Ctrl+g. With all the “open / close” features ecc.
1 Like
Agreed with you and @Dragosh.
@LudvikKoutny While I think reworking collections to behave like groups could be a thing, I think it would lead to more complexity in implementation and confusion on the end user’s side. I think it could be simpler and more powerful given two different data types with two different objectives that could be used together.
It could be a new data type internally, if it’s simple from a programming standpoint. But from a UX standpoint, IMHO it’s much better to reuse the existing concept instead of adding a new one.
1 Like
This also ties in with the “new user” (and existing user) experience,
People have been asking for groups (including myself) for a long time, so what happens is that people expect that when it get’s implemented it will be called “Group/s” (for the existing users).
This makes sense as “Collections” have established themselves as a viewport/scene/rendering organisation tool more than anything else.
Now if you go about it with the reuse route, then you start to create user problems, on one hand you have a familiarity with collections as a concept that grouping is based of off (loosely) but you also open the door to create confusion.
There is also another matter to consider.
Blender as a whole has a issue, it does certain things differently for the sake of doing it differently, naming convention is part of it. I want us to move away from that and move in the direction of “industry standard” or at least a standard of “established naming conventions”.
I have nothing against naming certain advanced functions in a “blenderly” way but i have a issue naming them for basic operations.
New users will search for the function Groups, if by any chance you name them differently ( eg. Collection grouping or anything similar) you will create unnecessarily confusion for the first time user, which will push the user to either trial and error this function as he isn’t sure what it exactly does or it will push the user to go to the Blender wiki and read on what it actually does, or even worse god forbid, have them go to either stack exchange/dev forum/blender artist and inquire about this weird thing called “Collection grouping” which would be kind of bad.
However if you name it “Group/s”, a name that already got established in almost all software to date (with few exceptions) you will lessen the user confusion as you’re using a established word/meaning in software use.
Hence why i insist that we call it Groups. Gotta keep it Industry standardised
2 Likes
Mic drop. Damn that was well explained!
1 Like
I agree that Blender often does things differently just for the sake of being different. And it mostly harms them. The reasoning I used is that Collections instances in Blender are pretty much what users expect from groups. They are just limited. So the direction I was coming from was to have sort of collection instances but without a need to have the original collection you need to reference when instancing. If this was the case, then any further improvements to collections would benefit group collections too, and vice versa.
In other words, if I could just “lock” a collection into a collection instance, instead of having to hide it first and then add its instance, effectively having it in the scene twice, just one of them being hidden, and if I was able to offset/transform the pivot of the collection instance, I’d have pretty much a group. So if there’s already something so close to groups in Blender, my idea was “why not just take those two more steps”.
Other thought is that some other software out there has groups, but has nothing like collection instances. Essentially ability to instance groups, so that if you modify transforms of the object in one, all of them get modified. Since collection instances can already do that, if groups were just collections, that functionality would remain.
I am fine with groups being groups too. I don’t have strong opinion here.