Groups and Collections

(Thinking Polygons) #21

This! :point_up_2:

(Lsscpp) #22

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)

(Indy_logic) #23

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.

(William) #24

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.

(Indy_logic) #25

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.

(SterlingRoth) #26

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.

(Indy_logic) #27

I just realized that dynamic overrides should be exactly that.

(William) #28

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.

(sozap) #29

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 ?

(Rhys) #30

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.

(Piotr Adamowicz) #31

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.

(zeauro) #32

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.

(Piotr Adamowicz) #33

That makes no sense to me.

(NinthJake) #34

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.

(Okavango) #35

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.