Can we expect at some point a true hierarchy system with groups for Blender?

single click them to move them around, edit them etc. Definitely something that can be worked up for sure!

Hmm. Any reason not to just use Collection instances for this? You could even make a collection of collection instances (“objects”) and make an instance of that collection (“group”). Then you could edit the “group” by moving the objects in the group-collection.
There are times when recursive selection could be nice, but all-in-all I think it’s an anti-feature that you should get used to not having (and not having to fight with). Recursive selection is confusing. The way Blender works is easy to understand. Well, nested collections and instances can be hard to understand, but they’re pretty simple. It’s the layers of complexity you can create that make them a little hard to understand. But that’s far better than being complex to begin with!

Anyhow when I get home I’ll see if I can mock something up.

Good point. I took a look again at how other 3D tools implement groups, and it seems like most of them have single clicks select the object, but you can use either keyboard shortcuts, modes, or menus to select the group itself.

After a bit more experimentation, the only downsides I’ve seen of parenting is that you can’t move the origin for adjusting where a transform happens without moving the children with it, since it seems that that is the point that they’re parented to. I’ve seen that you can set the pivot point to the 3D cursor so that’s a bit of a work around for one time transforms. Edit: Holy smokes you can enable affecting only the parent, so you can move the origin, without moving the children with it! I think parenting to a cube that either isn’t displayed or has it’s bounding box displayed would be very handy: since you could still move the origin. But since the parenting references that it doesn’t make it as attractive. I started working on a tool to allow for parenting to an empty, and then I realized you can’t move the origin of an empty. lol. Hell yes, I think parenting to a cube or non-empty object will work! Siiiiicccckkkk

Collection instances seem like a good option. However it makes it so that you have to have a duplicate (although for memory purposes it seems quite light). And you can’t select the individual objects in a collection instance, as far as I can tell (maybe you can?). Also you can’t change the origin point of a collection instance like you can an object, it seems to rely on the offset from the world origin. I have no clue why it’s set up like that; perhaps because a collection isn’t a concept that exists in a space in the viewport until it becomes an instance?

Seems like this is the functionality I’m visualizing for groups:

  • Select group elements individually and interact with them as if they were not grouped. They can all have their own origins / pivot points
  • Select the group with key command, mode, or menu and transform (move, rotate, scale) the elements of the group relative to the origin of the group (or pivot point, if that were something that could be stored per object)
  • Move the group origin (or stored pivot point) on demand, without affecting the position of the group elements
  • Long term: apply modifiers / settings to the group and have them affect the children

What are your thoughts?

Actually, you can change this.


Try changing ‘Instance offset’ and see how you like it :slight_smile:

And you can’t select the individual objects in a collection instance, as far as I can tell (maybe you can?)

This is correct. But that’s why I suggested you nest multiple collections and use collection instances of collections full of collection instances! :slight_smile: But that can be annoying since it, too, involves having duplicates of things.

My gut tells me this would be possible with clever use of drivers or handlers with the existing systems. I didn’t have a chance tonight to try it, though. Collection properties aren’t animatable, unfortunately, so it may be harder than it seems. Actually, on second thought, it would take some serious effort to make that happen in a user-friendly way. :thinking: I might not be able to do it if that’s what you’re hoping to be able to do. I could make a simple tool for parenting to an empty, or maybe an operator for ‘swapping’ the contents of a collection instance. I have my own addon I also need to work on.
Are you willing to get your own hands dirty with Python and matrix math? Maybe It’d be easier to try and do it yourself. I’d be happy to offer some guidance on the way to do it.

An empty is more or less an origin without further data, so I’d think there’s no difference between moving an empty or moving it’s origin?? If you have a hidden cube, what’s the difference with a (hidden empty)?

Moving the origin of a cube is just moving the cube and then moving the local vertex coordinates back, so why bother if you don’t want to display the vertex coordinates.

Thanks for all that! I’ll keep playing around with it.

Yeah, you bet! Sorry I didn’t clarify: I’ve started working on developing it with python right now, and if it’s dope then trying to get it added to the Blender core, and write anything that needs higher performance in C.

I really appreciate your support on this. It’s been very enlightening and helpful. :+1:

Hey!

My reasoning for a cube vs empty: I think it would be great to have the option to show a group bounding box, and also have the ability to select the bounding box and perform transforms to the group itself. If I use a cube empty for this, then the empty itself moves and I can’t constrain it to the group elements calculated joint bounding box, and have the origin anywhere but the center of it. By using a cube mesh I can get that flexibility.

In order to implement this I’ve so far figured out how to get the local bounding box of each of the group’s elements, and get the global location of those. And now I just have to figure out how to get the most extreme values of all those to derive the outer bounds of the group’s bounding box. Then set the cubes vertexes to those points. It should be pretty straight forward once I figure out how to work with the vectors that come out of the bound_box. Then I’ll need to set up some settings / mechanisms for when the bounding box should be automatically updated to the updated bounding boxes of it’s children elements. Also, having a bounding box for the group would be handy for very complex / dense groups in that the group elements themselves could be turned off for the viewport and just have a bounding box for the group etc.

Does that make sense?

You can make the Bounding Box a mesh in its own collection and use Collection Instancing on the empty if you want… I donno if that’s better.

Interesting! I’ll mess around with the different possibilities.

Do you know if you can change the icon of an object in the outliner? Or have it be a different custom type?

My money’s on “No”, but you should get it working before you start thinking about C code or pretty UI features. You can make it look nice after you get it working, because the process of figuring it out may be ugly and convoluted and difficult. It’s hard to be creative and solve difficult problems if you constrain yourself with pre-mature optimization.

Anyhow, Icons are something you can draw in operators, menu items, and such, so it isn’t inconceivable that you could do it in the Outliner. If you go to Preferences, you can enable Python Tooltips and Developer Extras. Turn 'em on and you’ll be able to right click stuff and ‘Edit Source’. This will open the Python source-code controlling the layout of whatever item you’re right-clicking on. Maybe you can hunt down a solution that way.

55 posts were split to a new topic: Groups in Blender

Actually, I do not like it at all.

I create a parent/child structure. Drag the parent, the children move. Fine. Put all of this into a collection, because we cannot instance a hierarchy group, because no Blender has no groups. Ok, fine.

COLLECTION
-PARENT
–CHILD
–CHILD

Let’s instance the collection. Drag this collection instance to where I want it in the scene, using the regular “MOVE” tool like an artist normally does. Drag the original collection to another position in the scene… and the instance moves.

So I’m meant to use “instance offset” to move these things around? No, no, no.

It is not just a matter of that. If I create a shortcut on my desktop of the blender application, and move the original folder - the shortcut does not also travel to the folder’s destination. If I move the shortcut, also - only the shortcut moves. Their location on the drive is completely independent, despite the fact that one is an ‘instance’ of the other.

No, the shortcut breaks. much better :stuck_out_tongue_winking_eye:

It certainly doesn’t break on my system. A few moments ago, moved the entire Blender install folder from C:\Program Files to desktop. Shortcut didn’t break, application launched from shortcut as expected.

Oh impressive. They fixed that! I must admit I hardly ever use windows these days.

Still, this is not so strange? If the instance would not move with the original objects, how would you move them if you wanted to?

If you need instances of a collection, use only instances in your scene. Don’t use the original as well. Stick the original in a hidden ‘assets’ collection or something. Using some collection which is visible in your scene as a source for instancing is asking for trouble imho. It will lead to all your objects within the instance having a weird far away origin. I think it’s better to always create your collections for instancing around the origin.

I would move the Instance itself… just as I do now.

I’m not suggesting Instances be unable to move - I’m saying I don’t want the master object it’s instancing to drag it around like a pet on a leash, when I move the master. The instance should have it’s own unique transform, not an interpolated/dependency transform of the master.

Well, yeah - that’s what I’m doing, which means after I use master object/collection for modeling, I now have to do lots of housekeeping (can’t use it, because transforms inherit).

And in order to maintain some sense of normality, every collection that I intend to instance (now, some other time when you’ve changed your plans, etc), has to be created at world 0/0/0, so that the instance also inherit the proper 0/0/0 origin.

Now I’ve countless collections of objects all stacked on each other at 0/0/0, which means I have to show/hide/solo most everything if i want to make an edit.

I make another collection to store them all in, hide THAT collection from rendering - awesome, now the instances don’t render either. So let’s put the “hide original objects” collection into ANOTHER collection, and hide THIS one from rendering. Thank heavens that trick works…

It’s simply poor workflow.

1 Like

Just always use the empty that is the parent of the objects as the instance offset value. I name my empties “Instance Offset Locator”. So if I have to move the original collection’s contents, I can just change the offset value to the new location of the parent empty “Instance Offset Locator”. That will fix all the instances used throughout the scene.

I stopped doing that once i realized I could do what I said above.

Activate the “include in view layer” checkbox in the outliner and use that to hide original collections without disabling them from rendering. However, it is annoying if you have various incomplete projects or helper objects that you always want to remain hidden (eyeball). Whenever you re-enable that checkbox it forces ALL objects within the collection to become visible again, so annoying.

Because of that problem and the annoyance of things overlapping at [0,0,0] I just make the things where I want them initially, parent them to an empty, and use the empty location as the instance offset value. Moving the collection contents is not a problem as long as I remember to change the instance offset value to wherever I moved the parent empty to.


or

What I’ve started doing lately is putting the collections I want to reuse into another scene named “assets”. Make a 2nd scene. Open 2 outliners set one to “Scenes” mode. Drag the original collection into the 2nd scene. Right click the collection in the main scene and “unlink” to unlink it from the main scene. Place a collection instance in the main scene.
If you have 2 monitors you can open 2 blender main windows [ Window > New Main Window ] and show the main scene in 1 window and the assets scene in another window. You can edit the asset in the 2nd window and see preview renders of the main scene in the 1st window.

Yes these are all annoying workarounds that should be formalized and named and documented. Whenever I go back to old projects it’s always a mystery as to what combination of the above workarounds I was using in that scene. Moving forward I’ve decided it’s best to annoyingly document such information in the blend file for the future.


If there was a way to tell the collection to automatically always have a relationship between the instance offset value and the empty I parented the collection contents to, it would save a lot of time.


The Blender Artists thread is informative and quite helpful. But, i believe it completely illustrates the problem in Blender with groups, collections, and instancing - which is: collections aren’t really groups, nor do they like to be treated as such. Make a collection of X, make an instance of C-X, make new collection Y, put C-X in Y, and along the way create several null objects (or not, depending) and reset lots of transform offets.

A far simpler approach: we stop trying to use collections for this. Let me select a Parent object, hit ALT+D, and have the entire parent/child chain duplicate linked (instanced). Many issues solved.

3 Likes

An upcoming issue is that the new light linking feature doesn’t seem to work with collection instances at all, only real geometry. Had to “make instances real” on every linked collection instance to use the feature.

That will be a significant problem; I have GN setups and shaders that absolutely do not work, when making instances real - they depend on the instances remaining an instance.