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. 
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.
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.
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.
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.
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.
