Groups and Collections

Blender already has that to some degree - group instances. The group instance is treated as a single object and has all the benefits one would expect. The drawback is that you need to have broken down duplicate of it in some different layer or hidden.

I think what we need is kind of extended functionality of Blender’s current group system, where you can choose to treat newly created group as a single object. You could also choose if newly created groups are treated as a single object or as multiple objects (the current way).

What I am really worried about is if we’d end up with two different grouping system with two different names. The current one, and another one that is completely disconnected. That would be quite bad situation. So I am in favor of extending current group system in Blender with the ability of treating groups as single object (while preserving all the benefits current system has).

1 Like

With some tweaks the existing parenting system could be added to, in order to do it. I think this is more or less what Romanji and ThinkingPolygons were getting at.

Add a new object type, something like “group origin”, which is essentially an empty, except it can have modifiers.

when you make a group and pick ‘merge’, one of these gets made, placed at probably the cursor, and anything at the top of the parent chain (i.e. that has no parent, or whose parent is not in the new group) gets its parent set to the new ‘group origin’ object.

Then just have the ‘group origin’ object keep a copy of its modifiers on the modifier stacks of its children. Some modifiers might need an extra button, such as if you wanted to support array with relative spacing using the size of the group as a whole, rather than each individual object. But on the whole, you’d get what you’re after - and you can use stuff like constant offset and object origins (on modifiers like screw) to do that.

The main thing that wouldn’t work is stuff like physics and particle systems, if you were to expect it to treat all the objects’ meshes as one - but that’d require some system that merges objdata dynamically and non-destructively which is probably a tall order. You might be able to write a modifier to do it, but there’s no telling how fast or slow it’d be

Maybe the first click on any of the group objects selects the ‘group origin’, which also highlights the group, but the second selects the object inside the group. Or maybe the ‘group origin’ has an edit mode that works like pose mode in that it sticks, and lets you select other things, and while its in edit mode you can select the grouped objects.

That would use the existing collections system and parenting heirarchy to achieve the results it sounds like are asked for, for the most part. The main thing is getting an object to copy & update its modifiers to its children (and thusly keeping track of which modifiers on an object came from a parent), and some exrta selection logic.

It’s possible you could do this without groups or even a new object, but rather just an object setting for grouping any objects’ children together (select the empty that everything is a child of, click a little checkbox that says ‘group children’ or something and viola. You can still have a menu option that automatically creates an empty, sets it as parent, and ticks this option, too), but then empties don’t have modifiers so that might be weird. Ideally if empties can be made to house modifiers though that is optimal and again is what I think Romanji and ThinkingPolygons were trying to suggest.

You can even separate the options, separate settings for ‘copy modifiers to children’ and ‘group children’

just rambling ideas.


I am all for object groups, as far as i know there is an addon which does exactly this.

But i fail to see why objects that share an modifier need to be glued together of treated as if they where one objects.
That’s not what i need.
Lets say i model an robot and in the modelling process it is made up of a hundred pieces.
I want to mirror all of them to the other side since its symmetrical. But i still want to move and edit all the pieces. I don’t care for an object group at this point, i just don’t want to use a hundred mirror modifiers. That’s it.


I’m really curious what you guy mean when you say, “Proper groups”?

I’ve use most 3D programs and most of them have some kind of mechanism for grouping. Max’s groups are really weird and no one that I know uses them (I work in a Max/Maya studio and no one is actually allowed to use them). Modo’s always seem like an extra step and more of an extra organizational feature outside of the hierarchy.

Then there’s Maya. In Maya when you group something, all you are really doing under the hood is creating a transform node at 0,0,0 and parenting the item to it. So, it’s strictly a hierarchy mechanism. In my mind this is the most useful but also the most useless. I mean, I can just do that by hand if I need to, :wink: This kind of grouping is what I usually do in all 3D programs. Organize by hierarchy.

Modo actually has that same feature but some time ago they introduced the new “Groups”. They are, for all intents and purposes, the same thing as collections. In fact, Modo’s groups are even used for the exact same things. But, in Modo they hide this by renaming them based on the operation. So, render layers are just groups but you don’t know this because they just call them render layers. :wink:

And really, if you are looking for groups, you should probably be using collections… If collections are missing some feature that you can get with other programs, then I suggest that you make a proposal to add those features.

…Unless of course, I’m missing something. :wink:

If you can convince the devs to implement this, I’ll hug you. I’ve been asking for this since 2003, but there’s always some strange and convoluted reason why it can’t be done.

That said, Collection instances aren’t that far off from this. All we need is
a) the capability to edit the collection’s origin,
b) the ability to “close” the original set of objects to protect it from accidental edits, and
c) the ability to edit a Collection instance in place.


This! :point_up_2:

1 Like

I like your idea: groups remain as they are now with just one more feature: a single switch to set them to be treated as a single object!
A nice thing would be if modifiers could be “added”. I mean if you set a modifier to the (object-like)group, every object inside it will have its own modifier plus the group one.
A cool way to select objects inside the group could be just double click (as in many adobe applications)

I think what we are all talking about here is usually called “Inherited properties”. You basically pass down properties from the parent. That would definitely be great.

As has been suggested here, another way to get to the same goal is to make improvements to Collection instances. One could add the ability to override the settings of them, add modifiers to them, edit them in place, convert any Collection in your scene to one etc. There are several routes and implementations possible to get essentially the same functionality.

I think that’s a great idea. A little un-intuitive but at least it offers some way to do it. If there was a quick way to make a collection into an instance and use that with overrides, right in the scene, then that would be better.

1 Like

Are the 2.7x style groups fully replaced by collections now?

I think refactoring groups/collections to allow the ‘nodegroup’ style grouping would be ideal. having to tuck away the originals on some hidden collection, then needing to switch over to where those are when you want to make a change is a hassle. Much like I can edit any instance of a mesh in place, without needing to locate the original mesh.

I just realized that dynamic overrides should be exactly that.

Right, exactly. The current workflow is clumsy if you just want to group some objects together to act as one. There are several ways in which it could be improved, depending on the route chosen.

As for Collections, they essentially are the groups from 2.7x, but more powerful and flexible, also replacing the old layers. Basically 2.7 Groups and Layers had a baby which is Collections.

This potentially frees up the name ‘group’ to mean something different from a 2.7x group.


I find this merge quite neat, one thing bother me still :
In a animation workflow, where you create many assets and link them, you have to differentiate by yourself what collections are meant to be linked (groups) , and what belong to the actual asset’s .blend for organizational purpose (layers).

This is can be an issue when working with several people, where people need to know easily what is what without needing to ask.
It’s also an issue if you want to automatically scan the .blend for asset management purpose.

The only way I found to work around this is using naming conventions (when working with several people) or using a custom property to tell if a collection is intended to act as a group or a layer (in the case of an asset manager) .

As you’ve worked in the blender animation studio during the code quest, does this issue as been raised ? will there be a built-in way to handle this , or it’s up to users to set naming conventions or custom props ?

What ever happens to groups/collections being expanded upon it 2.8 can it be seen to regard the users with 100’s/1000’s of existing 2.7 assets which make use of the 2.7 groups and instancing system :hugs:

I feel like 2.7 groups do not equate “layers” and given the translation of those to collections(layers?) in 2.8 this seems overkill for what could be simply a set of 3 mesh objects. At the same time a bit demeaning of the old layer based scenes.

One thing that confuses me about collections: when you make a new collection, why isn’t that collection visible in the Scene tab in the outliner? They are after all in your scene, so they should be there? You have to go chasing it in other tabs. That’s extremely impractical compared to the old Group and layer Behavior.

Also, when an object is in a collection within a collection, the “Collections” tab in Object properties fails to tell you this extremely pertinent information, it just shows the immediate parent.

Yes. It looks like Collection creation is limited to nested collections in outliner. Which is probably to avoid to create a collection at same level than global Scene Collection.
If I select Scene Collection line and press button In View Layer view, there is no problem.
A right click on Scene Collection line in Scenes View opens a Collection menu but clicking on New have no effect.
If I do that on Collection line, a nested collection is created like in View Layer view.
So, there is no way to create directly a new collection at lower level in Scene view.

As well, collections panel in object properties is old group panel updated to retake collection names.
But collections that should allow overrides are probably not handled the same way by depsgraph.
I think problem is there since a while but the priority was to have something practical in outliner, first.

That makes no sense to me.

1 Like

It has been requested many times through the years but has always been shot down by Ton because he had a vision of how he wanted groups to work. I assume it’s close to how collections work currently.

Anyway I have used “GroupPro” and “Smart Join” addons for a couple of years now. They work exactly how groups work in Max and is in my opinion the ‘right’ way. I wish that 2.8 would have this natively but it doesn’t seem like that is what Ton wants.

1 Like

Standard groups are extremely important for repetitive element modelling. And it is quite a delicate topic in terms of what groups / layers should be and how new collections fit into that.

A group should be easily made, selectable in viewport with one click on any of the members of the group (no pinpointing on empties), with key+modifier accessible members which can be groups themselves, with shared properties, ALL commands apply to all of the members with one click, with the possibility of ALT+D linking where any of the group instances is accessible and editable in it’s place, no naming required, no listing as layers, behaving COMPLETELY as a single object, easily disolvable to members or to lowest category elements.


A couple of blender related articles that i was a part of over time:

BA thread with what in my opinion groups should be

A crucial discussion of why groups and layers are not the same thing and why it will probably be very hard to implement both functions in the new Collections. Check all the posts in the discussion if you have the time.

Right-ClickSelect proposal 1, support it if you feel the same way

Older Right-ClickSelect proposal by me and @ejnaren, with a lot of specific issues tackled in the comments

Not sure, but most probably, a new group system will be required to do this task efficiently.
@William thanks for taking this under a consideration. It has been way too long.

1 Like