Groups in Blender

I see your point @LudvikKoutny , and it kinda makes sense to me.

Though I think that the “two more steps” approach that you suggest is still valid, and (maybe?) even
mor straightforward if you apply that with parenting system instead of collections.

If you add the “close group” feature to the empty parent of a hierarchy, you basically have the desired group behavior.

Maybe instance duplication of a group would be a little bit more tricky to design ( how do you keep object transforms in sync among group instences?)
But in that case, maybe we can still use collection instancing as it is now.

The reason I’m more towards real groups object is more or less the same explained by @Dragosh , and plus, coming from Maya, I can tell that I missed a collection system to organize the scene without affecting the hierarchy.
( Maya had sets and layers for that, but I really wanted something easy and powerful like blender collections back in the Day).

Also 3DS max has groups, and it has “open/close” feature, and other non 3d software has hierarchical groups (illustrator, affinity designer, various cad software) , so any user coming from any object based software would expect that.

Anyways, I think your solution can be valid.
Just thinking out loud:

Maybe an alternative solution would be special collections, simply called “Groups” , basically the same as you suggested, but UX wise, they are called Groups for familiarity with new users, and they are not originally standard collections, but you have to create them from scratch as “Groups”.

They could have:

the “open/close” option, exclusive membership of it’s children (objects can belong only to a group, and groups can be nested), they have a pivot point that can be freely transformed.

That being said, I don’t know if this proposal is less complicated than just enhancing parenting to empties.

Let me know your thoughts!

1 Like

I get the feeling Blender devs like to show off how clever they are, which is fine, but it often makes life difficult for the less clever people who have to use the software.
Coders would just like to have less data structures/object classes to maintain. Most users want groups. Making “groups” a subset of the collection functionality and calling them groups when this is enabled seems to me to be the way to go.
Collections already have a “position” attribute hidden away inside them. Is this part of a hidden full position/rotation/scale transform?

1 Like

I have the feeling it’s much simpler than that.

Blender devs are rather busy. There’s so much to do and so few people to do it. For the people in this topic Groups are apparently priority number one. For other people the new hair system, simulation nodes, geometry nodes or one of the many many other things that are currently in the works are more important.

1 Like

Honestly I don’t think so…

That’s not a negligible detail, keeping code easy to mantain is important, and that’s not to show off how clever a dev is.

2 Likes

I absolutely agree with you. As I said before everything I was saying was about my limited ability to impliment the functionality. Solely because no one was doing it, and every time I see it brought up the person has gotten instantly shut down for even suggesting it. Also at this point, I just don’t care how it gets done. Just that it does, lol.

Also, I think the devs developing with as little outside influence from any other software is a smart move. That kind of thinking promotes real innovation. However this only works to a point. There are some things that are so ubiquitous that this kind of design philosophy allows those things to be overlooked. I’d offer up left-click select and right-click context menus are a prime example of that. The point is it’s not as much about industry standards as it is about intuitive design and functionality. “Groups” is even heavily rooted in language. I like using a Bicycle as an example. When you hear or read the word you envision a Bicycle, but in reality that is just a construct used to describe a predictable group of parts. Just like car, plane, or house. Groups are a large part of how we think. It’s how we construct, and quantify the world around us, and it’s a huge part of who we are as animals. So, I applaud them for keeping it different. It has a lot to do with what makes Blender so great. However, they have been far too strict with that and it has caused things that are just expected to be ignored or left out.

My idea of changing how we interact with Collections is how I went about things with my own plugin. Because it was easy enough for my weak skills. But here it should be forgotten. Because a new data type is, as far as I know, the proper way to go about doing it, and thusly how it should be done. As well calling it “Groups” despite what Pablo has said in Blender Today before. Calling it groups will not confuse people because of the old Blender naming conventions, which as far as I know was just parenting. That is something I would actually say is a perfect example of getting in line with industry standards. Either name fits the function, but parenting is what everyone else uses.

As far as the other features that are taking up all the dev’s time. I mean, I get it. However, I really think Blender could use a solid usability pass. Not to make it more like any other software, but to make sure that it is intuitive. A great example of that is flipping face normals. That should be in the right-click context menu. But instead, it’s buried in the viewport menu. Just like we have groups in the shader editor, but not for objects and any time groups have been brought up in the past it’s been met with dismissal. ¯_(ツ)_/¯

I want all the neat stuff they are working on. Personally, I don’t really care about everything nodes. But it’s neat nonetheless and I want it. But what I really want is for Blender to not be a program I have to fight with to get the thing done.

3 Likes

that could be true in some cases, but the opposite is can also be correct in other cases. There are serveral concepts, that grow for many years to almost perfection and hundreds of smart people refined them over time.
Then to say: “we can do better” is a strange mindset in my opinion, and even: “we can do different” is also strage, bcause some concepts are developed over time to just the most time-efficient ones.

The other things you point out, I just can support.

3 Likes

It’s not. It just has undiscoverable ui and is unrepresented in the viewport.

My headache is where to put the original collection and/or hide it from rendering while not hiding the 400 instances of it from rendering. My solution was typically to just put original collection below the floor grid, which is why I put so much effort into finding out that I could change the origin point used by instances: Is there anything else you should know about collection instances? - Tutorials, Tips and Tricks - Blender Artists Community

Select all the arm objects, and add them to a new collection, call it “Arm”

I have 13 objects that make Arm Type A.
I have 5 objects PLUS the 7 of the 13 objects from Arm Type A that are used to make Arm Type B.
I want all robots in the background to not use subdiv modifier. I want 2 robots in the foreground to use subdiv modifier. I don’t see how that’s going to work.

Now if Arm Type A is a group and Arm Type B is a group (not sharing any of the objects from Arm Type A). Then I could see a subdiv modifier applied to the Group Instances used in the foreground robots…

I’m not sure my example above makes complete sense. It might be totally off… but that’s the complications of trying to reuse collections when I think of giving it a group sub mode and a non group mode. Actually part of my problem in the stuff I wrote above could be partially solved by allowing subdiv modifiers to be added directly to collection/group instances… which is sort of something I’ve been doing with geometry nodes already.

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.

Surprisingly, Maya users prefer to not have to see and empty for each group all of the time. It seems to be a real pain point of using Blender for them even though, as far as I can remember, “ctrl+g groups” in Maya were just parenting the objects to an invisible empty, same as in Blender.

I still highly doubt 90% of daily blender users even know about the “objects in multiple collections” feature. If I’m right, collections should have never been created in the first place and they should have just made regular old “groups”. … I just checked and in 2.79 you could “Link object to Group”, again reinforcing my belief that “Collections” today are just the same thing as the horribly mislabeled “Groups” from 2.79.

A lot of Maya users would be happy if ctrl+g just parented to empty by default and the move/select tool had modes where clicking a child object automatically selected its direct parent or oldest ancestor or all siblings or all siblings and first cousins. They would also want the ability to hide the parent empty object or at least have more options for what empties could look like.

As in, any instance, anywhere, can be edited in place as if it’s the original collection? There are already add-ons that do this quite successfully it seems. But like i said, collections seem to have not been touched since 2.80 and it fries my brain that they don’t see the benefit of adding this natively. In 2.79, Collections (wrongly called Groups) only existed in the bowels of the Blender File. Perhaps the same should happen with a collection when converted to an in-place instance?

and if I was able to offset/transform the pivot of the collection instance

You can.

coming from Maya, I can tell that I missed a collection system to organize the scene without affecting the hierarchy.

I have one outliner set to only show collections (Maya Display Layers) and another set to not show collections at all (Maya Outliner). Hierarchy in one. Organization in the other.

Maybe an alternative solution would be special collections, simply called “Groups”

The “special” is an object being in multiple collections. While it has been really useful for me a handful of times… if hardly anyone really uses it very often… I’m all in favor of just removing that ability entirely and turning Collections into Groups. Change the name, add ctrl+g default hotkey, implement UI around showing/changing the group origin. Job’s finished.
Nice to have: Close/Lock a group to turn it into an instance in-place. Edit any group instance in-place as if it was the original.

Later we can add back in “collections” as a way to categorize objects with all the flexibility of “hashtags” as in a single social media post can have infinite “hashtags” also known as a single object can be in infinite collections.

Calling it groups will not confuse people because of the old Blender naming conventions, which as far as I know was just parenting.

Download 2.79 and try it. Select 2 objects. Ctrl+G. ??? NOTHING HAPPENS that you can see. It created a “group” elsewhere in the “blender file”. Shift + a > Group Instance You can add an instance of the group you created.

Make 10 objects. Randomly assign 2 objects at a time to 100 groups. Yes you can have 1 object in infinite groups simultaneously. “groups” in 2.79 are literally Collections but without the render visibility toggles.

Then to say: “we can do better” is a strange mindset in my opinion

perfect is the enemy of good

2 Likes

That’s exactly why I said difficult, not impossible. Undiscoverable and unrepresented is what I’d consider difficult, especially for someone new.

1 Like

Not only new people. I’ve used blender for many years now, over the last 3 as my main 3D program but even before that for longer periods of time. I still discover new things or hear features mentioned in a video or stream and write them down immediately because I would have never found them.
My favorite example is the Shift-R remesh grid preview in sculpt mode. One of the most awesome features but nowhere to be found in any menu only as a numeric value where it’s really unintuitive to figure out what is the desired scale. I’s not mentioned in the Voxel Size Tooltip and it can’t be found via F3 search, either.

Undiscoverable is terrible design and a weak point of every software. Every blind spot like this needs to be addressed or at least logged as design task ASAP.

2 Likes

I probably misunderstand what you’re saying, but you can just exclude it from the view layer. Or hide it??

You can instance hidden collections just fine.

Most of my projects have an ‘assets’ collection, int which lots of subcollections reside for instancing. The asset collection has the ‘include in view layer’ checkbox ticked off so it takes hardly any space in the outliner and doesn’t show up in renders.

1 Like

When things are not yet finalized I might have more image hidden objects than visible. Turning the Exclude From View Layer checkbox off and on resets every eyeball. It is the single most infuriating thing to me in Blender. It does this for sub-collections as well! :angry:

Most of my projects have an ‘assets’ collection, int which lots of subcollections reside for instancing. The asset collection has the ‘include in view layer’ checkbox ticked off so it takes hardly any space in the outliner and doesn’t show up in renders.

I try to remember to do it this way but I often feel the need to keep certain things in other places in the organization, especially when I first create an asset in place and much later decide I want to instance it in more places. I never get around to going back and replacing the original with an instance. To do that I would have to organize and clean the collection contents and sometimes I’m just not sure I want to delete an alternate version of an object just yet and I’m not in the mood for the annoying exclude from view layer foolishness.

1 Like

I agree that’s extremely annoying.

For that reason I often just hide the collection (in both viewport and render) and fold it. That leaves the visibility of it contents as-is.

1 Like

Oh for real though this has bothered me so much learning Blender. I know it’s a side track but it’s related in the broader usability issues of Blender.

There is sooooo much of the functionality of the program that isn’t in the top / right click menus. It boggles my mind that all the functionality isn’t in a menu. It access, discoverability, and sometimes functionality, a huge pain in the A.

I feel like there is a massive part of the user base that doesn’t know everything Blender can do because there isn’t a menu item associated with every function. Instead it relies on buried hot keys, that are different depending on what view / context you’re in, if there’s a hot key for it at all.

Furthermore, what also makes the usability a struggle IMO, is that there are conversely a number of things that should have UI buttons, which only have a menu entry. The first thing that stood out to me was rendering. How come there isn’t a render image / and render animation button in the render view?! So simple, so useful, yet there is only a menu item and a hot key. Mind you once you know the hot key, you’ll probably only use that, but the fact that there isn’t a button boggles my mind, since from a new user’s perspective it’s pretty confusing to open the render view and not see a start render button.

But I should probably start another thread just to discuss UI updates in general… hahaha

2 Likes

Heh… :smiley:
https://developer.blender.org/T89922
I actually reported it. Not an issue for them, of course :slight_smile:

Do you realize that if you always talk about people as ‘the adversary’, the people start to feel that way about you as well?

It is very true that a lot of stuff doesn’t get the attention it needs, but maybe you could accept that it’s not malice? Stuff is not ignored on purpose. The way blender is distributed (for free! people seem to forget that sometimes) leads to a system where there just are not enough core programmers to fix everything and keep up with the latest developments in the field. All open source programs have the same problem more or less: when people code unpaid for a hobby they prefer the interesting problems. And that’s OK, you can’t force people to do something without hiring them. In my experience Blender is way above average in fixing the mundane stuff.

You can get annoyed that something is still not fixed even though it was reported, I understand that. But as soon as you start to call the developers ‘them’ and frame them as the opposition, they’re probably going to consider you as ‘not one of us’ as well. Which doesn’t really help your case when you’re dealing with mainly unpaid volunteers.

4 Likes

One major limitation of collection instances is that you can’t edit stuff in place. Context where it’s used is often very important, and it’s always a bit awkward to work with this disconnection.

I don’t care how this is feature is called - I just think it would ease the workflow considerably.

I also see no issue about adding an extra type for managing scene data - as the collection right now is a bit of a mixed bag functionality wise, which might have been better split…

Anyhow, I don’t think there will be any movement on this, as every engineer is already loaded with tasks - and I just don’t see the shift of current priorities happening.

And to be fair the current system also kinda works good enough for many things…

4 Likes

Yeah I often do the same, I don’t know if I didn’t explain myself well and I was misunderstood. But I meant back in the day when I used to use Maya, layers and sets weren’t as powerful as Blender’s collections, and I wish I had something like that in Maya. So, I basically agree with you.

That makes sense, I agree with you about collection being basically Tags.
I also don’t use the ability of objects to belong to multiple collections that often, but sometimes it’s useful expecially when managing render layers.

I still think that on a practical point of view (I may be wrong) It would be better to enhance hierarchy/parenting system instead of removing a feature from collections. Because:

Removing the ability to have objects in multiple collections is a regression and I think it would break a lot of Render Layers relatet workflows. So It’s probably a lot of design + coding work to fix what that regression broke.

Enhancing Parenting to empties instead, would just be an upgrade to an existing system. And I suspect that, design wise, it would be probably as “simple” as the process you described applied to collections, but without the downside of breaking Render Layers Management:

  • CTRL+G automatically creates an empty and parent all selected objects to it
  • Add the “Inherit Render/View Visibility” Toggle to children objects or conversely “Propagate Render/View Visibility” toggle to the parent
  • Add a new type of Empty Display, as a comprehensive bounding box of the children
  • Add open/close group
  • Deleting the parent deletes the whole hierarchy by default
2 Likes

I’ve always thought of this as the most logical next step. In the other cases: How can Parenting and Groups exist next to each other?

I mean that a Group is just an empty with the extra settings/features and the shortcut to create and parent selected objects to it. A good example is Maya, a group is just an empty transform (in maya a transform is more or less what an object is in blender) with children objects. Basically:

Grouping just means quickly parenting objects to an empty object with a bunch of extra options (open/close, inherit visibility, deleting parent deletes the whole hierarchy by default) .

Edit: Sorry, maybe I misunderstood your question? What do you mean with other cases?