Groups in Blender

Archive User Feedback
21

Yup! They should be able to have anything that can be added to an object added to them.

I think I’m terms of actual implementation, we could use an object that has all of its display / render properties turned off. I’ve played around with this concept recently and empties that have been suggested for this purpose have the problem of not having the ability to assign materials and modifiers etc. to them. Whereas an object has all of those abilities already. I’ll start fleshing a prototype out this coming week!

3 Likes
22

I would like to add some input if i may,

From the standpoint of the user ie. Me, how i would use the grouping system or at least what i expect from it’s behaviour (like i expect in every other program with a grouping system).

I want to group multiple objects, (what i find lacking is ATM if i joing the geometry selecting overlapping geometry that is free floating is a problem, especially if the model is complex, and parenting to a empty is just a hassle that’s unintuitive and is time consuming) i would select X number of objects and eg. press ctrl + G to group them together, that would create a new object that is a container comprised of the other objects i selected and initiated the grouping command.

Editing such a grouped object would make my life easier, architecture modeling would be many steps more organised as you could have 1 object that contains all the walls from X location.
To exit individual objects in the group i would just eg. double click the grouped object, it would enter the group and let me select any individual object in said group (imagine it like switching between objects in the sculpt mode that has been demoed when sculpting multiple objects)

I would also want to apply any modifier to said group or a material; these are some basic functions that i would want from a grouping system as they would make my production more organised and more efficient, i really hate joining objects but i want them to be part of a group without the burden of parenting them to a visible empty or something more time consuming and cumbersome.

:slight_smile:

2 Likes
23

Ok great. Thanks for the input. I think that is very inline with what has been talked about and what I’m going to prototype out.

I think the select a single object and it selects the group, and double clicking the single object selects the single object behavior should be a toggled mode. That way if there is a lot of individual manipulation needed, people can select individual objects, or groups inside the group without having to double click in and out of them. But then if you’re doing a lot of group manipulation you could turn that mode on which would allow you to select groups with a single click by clicking any of their constituents. Another helpful feature for this mode may be traversing your selection through the hierarchy of what is selected. So let’s say you click on an object that is inside a group, inside another group, you could traverse your selection from the object, to the group that it is inside, to the group that that group is inside with the bracket keys or something.

2 Likes
24

The toggle button is an excellent idea, very flexible and everyone will benefit from it, fast and efficient :smiley:

I also think the “scroll through” for all object part of a group is also and excellent idea, small note - bracket keys are quite unwieldy, they are quite far out on the keyboard when you have to use the Translation and rotation shortcuts in quick succession, is there any option to consider “CTRL + Mouse scroll” as a more practical keymap ?
Looking at the object viewport i dont see any other function using that keymap :slight_smile:

25

Schermafbeelding 2022-02-19 om 23.06.06
Schermafbeelding 2022-02-19 om 23.06.06932×238 35.8 KB

I already know of a great location for that toggle: next to the X-ray toggle in the header.

I think it will become very important to clearly define the roles of all eventual systems. Collections for visibility management, groups for easy transforms and application of child data, parenting for ?..

There’s also a whole bunch of design challenges when introducing this new system. How will it interact with parenting for example? Can I group some children of object A and some children of object B together? What happens exactly when I transform object A? Maybe the parenting system needs to be redesigned with a grouping system in mind?

26

For sure! I was just throwing that combo out there. CTRL + Scroll would be very easy to access, though maybe not as precise. Whatever key combo it uses could also be used for traversing child parent setups too.

27

Yeah somewhere up there in that bar would be a good location indeed!

Yeah I think it will be very important to define how it would interact with collections and parenting. I think that’ll become easier to do once I’ve started prototyping it out and seeing how it could be implemented and operate. Thanks for bringing that up!

28

no you cannot this can be would be done with constrians (is parenting constian or is it special condition ?)

29

How do you differentiate between a collection only used to organize the scene and a collection intended for re-use as Collection Instances?

How do you differentiate between a node group only used to make the node tree easier to read versus a node group intended for re-use in other node trees?

Too many things in Blender pull double duty. At the moment I think I’d prefer a new group type object separate from collections.

30

yop and as mantion up we dont realy need to add new type null object is already there we just need to cahnge how perenting works

31

This is another topic by itself. We can open a new thread regarding “subscenes” and talk about it there in more details if possible.

When something should be an ‘instance’ shared among many ways. And when a copy that is used only for giving the template, but allowing unique modifications.

If you have looked in the godot engine in general. There is the concept of a scene. However it has a twist in it, that everything is a scene and there is no other distinction of objects. Thus you compose a composite hierarchy of scenes made of other scenes. As for example the player game object is actually a scene that contains a cube mesh and a script. The enemy game object is a scene in the same way. In that regard the Level1 scene, contains these two scenes as game objects.

Though for example Unity, had a ‘scene’ (standard scene with all game objects) and a ‘game object’ (initialized object in the scene) and an ‘prefab’ (a packed and assetized game object). After a long time ago, they eventually added the subscenes but now there is a conceptual conflict between ‘prefab’ and ‘scene’.

Godot developers were thinking ahead of time and limited all of their options to only having scenes. Which simplifies the software design by a magnitude.

32

Yup. I’m definitely going to be experimenting using parenting as a method for grouping. I’ll also see what’s possible using non-parenting methods too for cross group grouping (definitely will be more complicated but flexible). I don’t know much about constraints so I’ll have to see how that impacts things too.

33

@thinsoldier @cconst Do y’all know if collections are the only way to instance things? Aka I’m not seeing any way to instance an object without placing it inside a collection …

34

I use linked duplicates mostly (Alt-D) because I want to be able to get into edit mode of objects instantly. However is the old way of doing things, I don’t know if as of now it would be recommended anymore.

Looks like since Collections is the new deal, they should have been designed from the ground up to be highly efficient.

35

Maybe this? Might not be entirely useful. Requires the instanced object to be parented to the instancing object.

image

36

Cool! Thanks. I’ll play around with that. Instancing on a per object or group basis, in addition to collections would be dope. Honestly I don’t know why collections would have instancing, but objects wouldn’t. But maybe it’s a technical challenge that wasn’t tackled.

37

Starting to prototype this out!
I haven’t gotten much into the coding side. Just trying to figure out the mechanisms by which I’ll be able to build the functionality out in the python prototype. In the eventual version some of it may be written in C and a new type will be added to the core.

Get ready for a wall of text below

So far:

  • I’m playing around with parenting objects to an object with a mesh that has no vertices. This allows the group to have modifiers and materials applied to it. As well as move the origin of the group without affecting the children’s position.

  • Materials should be added to the group in object mode, so that they can be added and removed dynamically to the group elements and kept in sync with them. This way if an object is added to the group, the materials that are already on the group can be added to the new group item, and removed if it is taken out of the group, without affecting any linked duplicates of that object that are outside of the group. If the materials were added in mesh mode, then those objects added to the group, would also change any meshes linked elsewhere to other objects outside of the group. How does that sound?

  • Modifiers also look like they’ll be able to be added / removed from group elements. So far I don’t see a way of linking them explicitly. If you know how to do that, holler at me. Aka if a modifier can be added to the group, and then that modifier could be added to the group items as a link that would be ideal. However at this point, it appears I’ll have to add new modifiers to the group items with the group’s namespace, and then loop through each modifier’s properties and add drivers that connect them with the group’s modifiers. This seems like a good solution so far, in that settings changed on the group modifiers will automatically be updated on group items’ group modifiers without having to programmatically update their values etc.

  • Speaking a bit more to modifiers, I am curious how their behavior will work with group items and whether it will align with user expectations. As an example, the array modifier in relative offset mode, creates copies (not instances mind you) of the mesh that are relative to the dimensions of the bounding box of the mesh. So if you have an offset of one on a cube, the cubes in the array will all be right next to each other. If I were to add this modifier to a group, in the relative mode, I would initially expect that the whole group to be relatively offset by the bounding box of the group (speaking of bounding boxes check out below). However in the current proposed method of adding group modifiers to the children, the relative offset is something that is calculated on a per child basis. So if you had a large cube and a small cube, the relative offset wouldn’t relatively offset the whole group, but the group-items. With the small cube having a small offset vs the large cube having a large offset.
    This could be worked around by having the constant offset used on the group items if the relative offset is used on the group, with the value calculated by the size of the group itself. So basically it could definitely work as a relative offset of the group, but there would have to be some more calculations involved there. So it wouldn’t be as simple as replicating all the values from the group to the group items per property per modifier. Which brings me to another question: What if modifiers on the group had a setting something along the lines of “Operate on group” for things like this with some extra math, you could replicate the behavior of the modifier operating on the group and not on the children? However this adds a lot of work in terms of ensuring that any setting like that relative offset would have some sort of work around for how it is applied to the group items, and I’m not in the know about all the modifiers enough to know if that would even be possible. Which brings me to think that it would be cool to have features like join mesh on the group…

  • Constraints… How would you expect those to work on groups and their group items? I haven’t really thought much about this yet.

  • Visibility, hold out settings etc. would want to be stored so that turning off those settings in a group could turn them off on the group items, but then when turned back on, would restore those settings as they were previously. So you could click on a group, turn off it’s visibility, and all the group items could be turned off as well.

  • Bounding boxes… Currently I’ve got some prototype code working that walks through the group items, get’s their bounding box sizes and locations, and then checks if they’re within the group bounding box, and if not, expands it to fit. This will be very useful in terms of being able to turn the group display to bounding box, and have a single bounding box represent the group items, while still having them renderable. Think very dense groups with lots of geometry, that with one click you could hide, but still see where they are in the scene. This setting could optionally be replicated down to the group items, so you could also see their position within the group itself.

Other semi related things I’m thinking about as I work on this:

  • Local stored pivots, whose position can be animated, and which provide transform options that can be animated per pivot. This could be on objects, groups, and instances. Think about the possibilities that could unlock…
  • Instances in general. How come we don’t have easy object instances? You currently have to add them to a collection first and instance that, or use things like instance on vertex or face, which is great for what it is, but not for just creating an instance and moving it around freely. Linked duplicates are dope and are strong in their own right, but don’t replicate the pure behavior of an instance, where all of the object level settings are kept in sync. So that’s something I want to tackle in the future.

Let me know what you think! I should have some videos / visual representations soon of the concepts talked about above which will make it easier to visualize, once I get some of it coded out.

Cheers!

1 Like
38

I could be wrong, but maybe something like what’s available in the free bagapie addon could help you figure out how to go about grouping/instancing ?

https://static.wixstatic.com/media/b68b45_f37591bfebdd413ea28289d8086f2f04~mv2.gif(image larger than 6144KB)

39

Nice! Yeah I’m envisioning something very similar to what’s demonstrated there in that GIF. I’ll download and install the add-on to check out how they handle them.

So playing around with the BagaPie implementation. Here’s what I’ve noticed so far about it:

  • New group items in that implementation get moved out of their current hierarchy and placed inside collections, and also inside a parent object that serves as the bounding box. (We’ll use a single parent object and no collections)
  • The box remains the same size as it was initially and doesn’t update when moving or resizing group items (We’ll auto update our bounding box)
  • Group items are not selectable by default, and you have to select the edges of the bounding box of the group (Selecting groups / group items could have a toggle mode per 3D viewport. Default behavior could be select the group items you can do everything as you normally would, select the group itself and all group items are selected. With group selection enabled, as I covered above, when group items are selected, it would select the next closest group that that item belongs to. You could walk your way through the group hierarchy with hotkeys)

Machin3tools also has a group feature, which seems more user-friendly than the BagaPie groups. I’ll check that out further as well.

Though I do like the instance accessibility of BagaPie groups, though since they’re instanced collections they fall prey to the issues that those cary with them (namely using world coordinates for instance positioning, which means you can’t move the original without also moving the position of the instanced geometry). Hence why I’m thinking about instances and stored local pivot points more as I work through grouping. Aka having a true locally stored pivot point per object / group would allow one to be able to move that around, base animations and transformations off of that, while leaving the origin in place so as to not affect the position of linked meshes (make a couple linked duplicates, and then move the origin on one of them so as to get a different place to animate a rotation from, and you’ll see what I mean. Slash I’ll film a quick video to illustrate it :wink: )

1 Like
40

Hey @Lichen I read your answer on Right-Click Select and came here to see what’s going on and… WTF! I think I practically agree on every single thing you mentioned before (I could have missed something tho).

To be sure, I’ll just recap here how I think a grouping system should work:

To me, the main purpose of groups should be:

  • quick grouping objects together for transformations as a whole: select objects, CTRL+G groups objects together. Basically the same thing that you do parenting objects to an empty. But with one shortcut and not using a simple empty as a parent.

  • quick selection of objects as a whole: select any of the children selects the group. This should be an option. I agree with you that It should be a toggle, IMHO possibly per object (like “open/close group” or “lock/unlock group”), but as @Claus suggested, it could be a global option. I’m not sure what’s the best solution.

  • visibility toggle inheritance: hiding the groups hides children as well, right now, animating visibility of dozens of objects must be done one by one (afaik).

  • bulk deletion of children: By default, deleting the group, should delete the whole hierarchy. There are cases when you don’t wont that, and it could be just resolved with a prompt on delete (Delete Hierarchy - Delete Only Parent ?). Right now you can do that by rightclicking on parent in the outliner (Delete hierarchy).

Now, my Ideas on how It can be implemented:

I think that collections are a completely different system than groups and made for different purposes and they work great right now. I think groups should be a completely separated concept and should not be a funcitonality extension/option for collections. I’m pretty sure that It’s possible for Groups as described so far can live together collections without any conflicts.

Even if you see groups like tags, if you limit just one tag per object, I suspect that they are still strictly hierarchical (in terms of logical organization), like folders. Any way In my opinion groups should be hierarchical (as opposed to collections) both in logical sense and also regarding transformation hierarchy. So that’s cool!

My first Idea was to make things very simple and not involving a new type of object, but rather create a couple of new empty display modes: “None” to just display nothing, and “Bounding Box”, which is basically the same thing you want implement with an empty mesh for the python prototype.
All the rest is about using the existing parenting logic and extending it a bit with all the functions mentioned before : automatically creating the empty and parent the objects with CTRL+G, adding all the functionalities to the empty like make children inherit visibility and every other useful property, adding the “open/close group” functionality ecc.

To me this is the bare minimum to give a great boost to blender usability and grouping with “minimal” design revolutions, and probably (I assume, but I may be completely wrong) with higher chances of not being rejected.

Of course I thought about the functionality of assigning modifiers, materials to the whole group at once, but that has a serious shift in design complexity, and it certainly can’t use empties as a parent object, at least not as they are.

It probably needs a new “group” object type that supports modifiers and material assignment, but still, this is huge and hides dozens of design questions.

Some examples:

  • what happens if you group different type of objects and then try to add a modifier to the group that is not supported by one of the group members? (eg. group of a curve object and a mesh object, and you add a displace modifier)
  • what happens if you group objects that already have modifiers and add a modifier on the group? Do the children modifier get overridden? Does group modifier stacks on top of the children ones? It needs a design regarding the stacking rules
2 Likes