Grouping should not override modifiers at least not by default, when i group things i expect them to keep their modifiers with the potential to add a modifier to the group itself as a whole
As for potential errors, you can either let blender give you an error when adding a modifier that does not support all group members which then aborts the operation or work only on the ones that support it.
i think you guys lack ambition. Please, no more abstract data structures to understand.
When I first heard about collections I sort of assumed that anywhere I could select an object (including modifiers and constraints) I should be able to enter the name of a collection and it should just work as if everything in the collection was one object. I should be able to parent collections in the same way as objects. Having both collections AND object parenting makes the outliner incredibly confusing.
In fact in the longer term I would go further and say the same for constraints/objects and modifiers/vertex groups: why do I have all these pesky hooks everywhere? why do we have solid object physics AND softbody/cloth?
I would also like to add to @RiccardoBancone 's comment regarding Collection/groups,
I do agree that Grouping and Collections should be kept apart as Collections have a totally different use case as opposed to a Specialised Grouping system as you cant modify a collection with modifiers.(and a object can be in multiple collections etc.)
Heck yeah dude! Glad you like what I’ve put out there so far!
We’re on the same page. Absolutely.
Should I start a new thread so that I can have the first post be a place to have the most updated definition of what I’m working on?
In regards to these ideas:
I think this is the direction it should eventually head. It would allow for a clear definition of a group in the outliner and could afford some flexible customized behavior.
For sure. So far I think that the implementation will loop through the first layer of children and check to see what kind of object they are, reference the RNA (think this is possible) to see what modifiers are compatible with them, and then only apply the modifiers from the group to immediate children that can handle them. This brings up something I’ve also been thinking about which is how deep are those modifiers applied. I think so far it make sense for it to have some sort of toggle per modifier to enable the depth and whether or not to apply them to groups. By default only immediate children, including groups. That way if you have other groups in there, they could have the modifier added to them, and then that group could add that modifier to it’s children etc. Or perhaps with groups excluded by default. Both of those could have defaults set in the preferences.
In terms of adding modifiers to children that already have modifiers, this is what I’m thinking so far:
Modifiers that are from the groups are all appended and have a namespace, or some sort of ID that ensures that when looking at the object, that you can see the modifiers that have been added automatically by the group, and what is specific to the object. You could also have an option per modifier on the group to either append, or replace the modifier. So that you could override the child modifier if you wanted to with the group modifier. This gets a lot more complex, but if we were to have this as an option, I would think it wouldn’t want to be the default behavior, but instead an option that could be enabled for the entire group, or on a per modifier basis. If overriding were a thing, perhaps instead of actually overriding the modifier, it would just disable the modifiers that are of the same type, and then apply the group modifiers. So that it would be non destructive, and be able to re-enable the ones it turned off if those objects were taken out of the group again.
Basically ultimately in terms of overall group behavior I would want them to be non-destructive. So you put an object that you’ve got a lot of time into setting up the materials / modifiers etc. into a group: you should be able to take that object out of the group and restore it to its original state. Basically putting an object in a group and then taking it out shouldn’t f**k it up. Hahaha.
Bounding Box Update:
Ok so interesting… In order to have an option that displays a calculated and accurate bounding box for the group, I’m going to have to either figure out how to draw a custom box in the viewport, or create some sort of shadow mesh geometry that can’t be seen in the outliner.
Let me elaborate.
I had thought this may be an issue, and have confirmed it is.
So my first option for creating a bounding box for the group was to use a simple cube mesh for the group object. However, this is problematic for two reasons:
Sooo… I’m going to have to custom draw a bounding box. Unless there is a way to harness the default drawing of regular bounding boxes? Anyone know? Otherwise I think I’ll have to use gpu or something to draw a BB.
Sooo… I’m goin to stop fiddling around with bounding boxes, and get back to the more base level grouping code. Even though, a dynamic responsive bounding box for the group is fun to work on and looks dope AF. hahahaha. Ok just for fun I’m going to finish this little mock up of what it will look like using a cube mesh just so I can have a reference of how it should work when I have to write this custom bud.
Yup! I think that’s right on the money.
In terms of adding modifiers to objects that don’t support them, I think it would just skip adding those modifiers and not throw an error. And then perhaps in the group itself have a list of objects with modifiers that were skipped for UX. Aka being able to see, “Oh I applied a subsurf modifier to the group, how come it didn’t get applied to this curve.” Check the group see, “Oh curve.001 doesn’t support the SUBSURF modifier” etc. What do you think about that for feedback?
Yup agreed. Collections work well currently for what they’re intended for. And that groups should be a separate concept.
If I were waving a magic want and could rewrite the whole thing without any repercussions and headache I’d probably just have one concept of an entity that could be put inside other entities etc. Basically everything could be a component. Lololol. But as it is I think leaving collections as is and adding groups would be the cleanest and easiest way. In terms of function I think it makes sense having them be two different concepts as well, one for render / view layer management, and one for modeling providing structural organization. 
Hi @lichen , in general I would set priorities and then proceed by steps. But I have no experience in blender developent, and very little in blender python
Development. So I could be wrong
In my opinion the priorities for a first python prototype iterarion should be roughly:
1-Implementation of auto generation and parenting of group object behaviour (whether it’s implemented with empty or mesh object)
2-implementation of inherit visibility proprerties (and other properties)
3-Implementation of "lock/unlock group feature
4-Implementation of “prompt on group delete” feature
5-Implementation of a bounding box drawing
I would leave all the modifier stack and material stuff for a second prototype iteration.
BUT that being said, your playful approach of experimenting with hacks to simulate the final behavior , even on avanced features like modifiers can be productive to spot potential problems and can help raise design questions. So my priority list is just an advice from an outsider, and I don’t mean to descourage you to continue experimenting. So keep going an let’s see if it works!!
Infact I have an idea about this:
What if you put a grometry nodes modifier at the end of the group’s object modifier stack that takes all the children objects as input, join them with a join node and then pass them through a “bounding box” node?
You could use a collection to quickly feed the object to the modifier but this would clutter the outliner, so, for the prototype purpose, I guess is better to iterate on selected objects, add them to the group object’s geonodes group input, join them and feed to the bounding box node.
Don’t forget that even If we get to have group objects, the possibilty to parent objects to any other object still exists. Maybe with groups it should be descouraged in favor of using only groups as parent, but the possibility is still there and should not be removed.
If the default is to only apply modifiers to the immediate children, the third generation children parented to , say , a mesh (and not a group), won’t get the parent modifier. So , as you imagined, the “modifier inheritance” and its “depth” management has to be designed carefully.
To me, the default behaviour should still be one that applies in any way, the modifier to the whole hierarchy , and if the user wants to control the depth it should be an option.
Totally agree on this, UX/UI wise, this should be well communicated to the user.
It sounds good. But the subsurf example you made comes handy. If I’m not wrong , subsurf is supported by both mesh objects and curve objecs. What if I have a bunch of curves that I use as path for curve arrays and a bunch of meshes in the group, and I want to just subdivide the meshes but not the curves?
I think so, especially as the current thread title no longer reflects the current discussion.
Maybe we could ask a moderator to split this discussion starting from @Lichen first post to avoid losing the comments so far? Or better start from scratch with a recap in the first post?
Thanks Riccardo and @EAW for confirming we should either move or split this. Do you know who to holler at to split this off into another thread?
Haha! You’re totally spot on with the priority of development. That’s bang on with my strategy for the order of what to tackle. I like to also mess around with future stuff and try and rough concepts out before diving too deep into the real deal. I think I’ve got a pretty good taste for what lies ahead so I’m going to start crushing that list out.
Interesting idea! I am very curious about how joining geometry works, in terms of having the group have the ability to optionally merge its children and thereby be able to treat its children as a single entity with modifiers. I think my current potential methodology of cycling through the children and getting their bounding box values may be pretty expedient. Once we get there I’ll explore your suggestion and any others to see which one works best. BTW I was able to get a simple example working with the GPU module and so I think that may be the path for when an actual BB is needed to be drawn.
Agreed. Definitely careful design is needed here. In order cater to flexibility and be able to apply certain modifiers to exactly what group items you want.
I could totally help, but given this thread was never reported for bad behavior nor is it a subject close to my heart I’m somewhat lost what needs to be done, I really don’t want to catch up on a 100+ posts thread, if someone could link where I should split the topic (upper right corner of a post gets you a direct link) and what the new title should be, i’ll make it happen.
Thank you!
Could you please split it here: Can we expect at some point a true hierarchy system with groups for Blender? - #47 by Lichen
With that post and following posts in the new thread. I’m assuming I’ll be able to edit that first post since I posted it right?
And name the new thread: Groups in Blender
Thanks a bunch dude!
Thank you! Much appreciated 
A single object can exist in infinite different collections which makes your imaginings somewhere between extremely difficult and impossible and totally incompatible with parenting in 3d space. A separate concept of groups is necessary.
What Maya calls layers and is similar to collections has its own layers management window. Typically I advise people to setup 2 Outliners in Blender and configure one to be similar to layers in Maya and the other to be similar to the Outliner in Maya.
I can think of four or five different ways I can use collections in blender. From an object oriented coder’s viewpoint using the same thing for all these purposes is cool but it sure as hell confuses hobbyist users like me. I like your idea of using different outliners - is the problem really one of the presentation in the outliner? Should this be the feature we tweak?
I’m getting increasingly frustrated with blender as I try to build more complicated projects and I wonder if I’m using a swiss army knife to construct a house. I come from an aircraft design background and although we used CATIA to build and display models we used a separate product data manager application to track all the parts and do version control. What do professional studios do?
“the problem” is almost totally solved using collections and collection instances, but in several different ways, by several different add-ons, and some of those solutions balance precariously on top of existing blender features (maybe even misusing a side effect of a feature) or are implemented from scratch with a lot of custom code that could break in the next update and would likely never be considered for integration with the core of blender because nobody on the small blender dev team has the time to learn what the code does thoroughly and become its official maintainer.
I’m just a hobbyist user also. The only other program I have experience with is Maya and back when I last really used Maya all “grouping” did was to create an Empty (that had no visual representation in the viewport) and make the selected objects the children of that Empty. Grouping was on Ctrl+G.
To manage visibility and renderability of numerous objects at the same time Maya used “Layers”.
So when a Blender file gets too complex and I start wanting to think of it like in Maya, I set one Outliner to not show collections and set the other to only show collections.
One of the add-ons that ships with Blender has a “Parent to Empty” operator that I set to Ctrl+G.
