While I’m probably going to be flamed for this, and also I’m very probably unaware of some arcane magicks that may alleviate some of my troubles, I’ve decided to voice my thoughts on improvements that could be made to scene management in Blender.
I’ve been working on an instance-heavy scene and selecting sets of tiny objects over and over is wearing on me. What I really wish Blender supported is real object groups that could be selected, transformed, instanced and maybe modified together. The common reply here seems to be to use parenting. And it works for relatively simple scenes. Not so when you have hundreds of objects in it.
Why parenting is not the answer:
a) Modifiers don’t affect children. No arrays. No bends. No curves. (While this would be great to have, I understand it might be difficult. Object groups would still be vary useful without this.)
b) You’re still trying to find the one object you’ve parented everything to. Sometimes it’s hard to find it, especially with selection lagging as it does.
c) You can’t easily make selections based on parenting. While Shift-G->Select children works if you only want one set of children, selecting the children of multiple parents is impossible. Which wouldn’t be so bad if not for:
d) Duplicate doesn’t duplicate children.
I’m not saying real groups are the only answer to these problems, I just can’t see a different one. And certainly, things like adding an ‘affect children’ option to Duplicate and/or the modifier stack would help.
So there. You’re free to flame me now if you like. At the very least endi will agree
My suggestion, so far is to merge the object, so that you’ll have working modifiers, instances, transformations and easy selection, all at once. If you need to split them again you should create unique vertex group for every object prior to merge, unless they have different materials. This way you can always un-merge them later when needed
If you do that you’re losing the modifier stacks of the objects you’re merging, so it’s inherently destructive. If you have multiple UV maps with different names on each object then you’re probably messing that up too. No animation and very time consuming to rebuild original objects with stacks. And you’re sacrificing some instancing.
You seem to have a clear idea of what “real groups” would be… apparently not what we already have. Can you explain what are your expectations more in detail, with examples ?
Certainly, I have no idea why I didn’t think to explain this in the initial post. Currently groups are little more than a saved selection, a list of objects. The kind of grouping I’m talking about would work like this:
Grouped objects are treated as one in the viewport. If you click on any member of the group, the entire group is selected. They would be transformed together much like if they were children objects of a parent.
In addition to grouping objects like you currently do, you could add objects to a group much like you currently Parrent objects, and you could edit the members of a group by entering a group edit mode, by pressing Tab on a group. This would nominally be a new editing mode, but it would behave exactly like Object mode, except any changes you make pertain to the group, and you couldn’t interact with objects outside it.
Groups could be instanced, so editing one instance would change all instances.
Groups would have its own modifier stack, and all modifiers in it would modify all members, with respect to the group object’s origin. You could for example make an array of group objects by using an array modifier on it. The group’s modifiers would only affect children when it makes sense - for example, the bevel modifier wouldn’t affect a curve object.
Objects inside the group would have their own modifier stacks which would remain unaffected by the grouping.
Groups could contain other groups or instances of groups (except of course an instance of itself), as well as instances of objects.
Objects inside groups could be animated just like normal. If you group two animated characters together and instance the group, the same animation will play in all instances.
Modifiers of objects inside a group could only reference other objects that are also inside it.
Groups could be assigned materials. If they are, the group’s material will override all member materials.
Groups could be assigned display properties (like wireframe display), which would override the member display properties just like with materials.
(bonus) Groups could be assigned a proxy mesh for improved viewport performance.
Of course, I have no idea about any problems implementing something like this would entail. It’s just a best case artist-perspective mental model.
If you click on any member of the group, the entire group is selected.
Because of the OpenGL lag in Blender I’ve got into the habit of selecting through the Outliner. It is possible to select all members of a group just by clicking on its name there.
They would be transformed together much like if they were children objects of a parent.
Transformation as a selection of objects offers many possibilities… do you have more in mind ?
In addition to grouping objects like you currently do, you could add objects to a group much like you currently Parrent objects
Presently we can select an object and then select another one or many, do Shift+Ctrl+G to add the first object(s) to the group(s) the active object belongs. Not Ctrl-P style exactly but not crippling either. Good enough ?
, and you could edit the members of a group by entering a group edit mode, by pressing Tab on a group. This would nominally be a new editing mode, but it would behave exactly like Object mode, except any changes you make pertain to the group, and you couldn’t interact with objects outside it.
This much is possible I think. I had to create a bit of script which makes it possible to edit many objects as one. We use it in-house. I’ve added conservation of the names, materials and vertex groups. Those three we needed but I guess that more could be added.
Groups could be instanced, so editing one instance would change all instances.
Not impossible.
Groups would have its own modifier stack, and all modifiers in it would modify all members, with respect to the group object’s origin. You could for example make an array of group objects by using an array modifier on it. The group’s modifiers would only affect children when it makes sense - for example, the bevel modifier wouldn’t affect a curve object.
Objects inside the group would have their own modifier stacks which would remain unaffected by the grouping.
There’s the challenge ! This can, for one thing, lead to a hierachy of modifier stacks… I can barely imagine it. Something to explore.
Groups could contain other groups or instances of groups (except of course an instance of itself), as well as instances of objects.
Don’t fear the spaghettis!
Of course, I have no idea about any problems implementing something like this would entail.
You don’t have to: there’s always a way. What you must do though is to prove that such grouping would enhance Blender, while not causing worse side effects than the problem it solves, enough to motivate a coder or scripter to undertake that considerable task.
It’s just a best case artist-perspective mental model.
Well, that isn’t a bad place to start although it rarely leads up the easiest path. One reporter asked Merleau-Ponty, a famed French philosopher in his time, why humanity sent people to the moon, a seemingly complex task, rather than solving the problem of hunger in the World? M-P’s answer was that we were able of the former and not the later. Technology forces our innovations more and better than our needs.
Well, I certainly don’t foresee any side effects, or I would have suggested something else. There might be some initial confusion for new users if they use too many instances within instances due to how unintuitive instancing in blender is, but that isn’t really due to any property of the grouping I outlined. It might be alleviated by something as simple as using a different color for objects that have multiple instances. Of course, I can’t prove there wouldn’t be side effects since you can’t prove a negative. All I can do is try to figure something out if someone does see a problem.
And as for proving it would be a benefit for blender, short of coding it myself and showing everyone I don’t really know how I would go about that either.
I think Lukas Tönne was already working on something similar to the modifier hierarchies that would be required to make this work with his modifier node implementation? At least I think it was Lukas Tönne. I can’t find the news post I saw, it was quite a while ago.
Transformation as a selection of objects offers many possibilities… do you have more in mind ?
I’m not sure what you mean here. What I meant here were the standard translate/rotate/scale transforms.
Sounds like you want a ‘Group’ object (aka container of other objects) instead of the simple list that the current groups currently are. This Group would act kind of like an Armature object except it would have other objects instead of bones as members and would behave as the current parenting does with changes to it’s scale/rotation/location being passed down to the children.
Wouldn’t be too terribly hard to implement (I’m guessing), the problem is finding someone to do the work. Could get tricky if one wanted to parent a child object to something outside the group (and you know peeps will complain if that don’t work) or parent the Group object to one bone and all the individual children to other bones (again, expect bug reports) so you’d have:
--> Bone --->
^ Object
Armature --> Bone --> Group -->
Which would be difficult to figure out who ‘wins’ to say the least. IDK, maybe I’m over thinking it?
In the mean time… stuff like a ‘Select all Children’, ‘Propagate Transforms to Selected Objects’, etc… operators would be pretty simple py-ops to write.
Indeed, it would be a container for other objects. The idea is to facilitate a less destructive workflow for modelling. Right now, like lsscpp rightly suggested, the solution is to merge objects down into one. And that isn’t really all that bad as long as you have nice large meshes to work with and you don’t expect to change anything once you’re done with something. But creativity doesn’t work like that, so you often want to go back in and change something, add a detail, fix a problem, etc.
Could get tricky if one wanted to parent a child object to something outside the group (and you know peeps will complain if that don’t work) or parent the Group object to one bone and all the individual children to other bones
Yeah, you’re right, it could lead to some unclear situations. I thought about that, so I wrote point 8. No references to objects outside groups. I didn’t mention parenting, but I guess it’d have to be excluded too. The idea is to make large scenes with lots and lots of small objects more manageable and easier to edit, using Groups in complex setups of bones is not really what I had in mind with this. Referencing outside objects would probably lead to bugs and make implementation difficult, not to mention the confusion. As far as bone setups go, there really isn’t anything groups could do that parenting, drivers, etc, couldn’t. Referencing outside objects would also probably lead to viewport performance problems, as instances of groups with their whole modifier hierarchies would have to be calculated separately, rather than calculating one derived mesh per unique group and passing it around all instances. But of course, if some sensible, well performing solution could be found for referencing outside objects, then why not.
And Select Children already exists, you just can’t extend the selection with it. Another (seemingly) simple thing that would make scene-building easier would be adding an “include children” option to the Duplicate and Linked Duplicate operators.
I would love to see Blender use grouping the way sketchup does. Not only would it be easier to control instanced objects it would make library management easier as well. I would love to make a group of objects each with different properties and modifiers, group them and then interact as though I had joined them all into one mesh.
Another cool benifit would be the ability to make groups of groups which would have low, medium, and top level modifiers.
Here is a video demonstrating the Sketchup style grouping.
+1 for having groups work like (almost) any other 3d/2d graphics app. Blender is the only one I am aware of that treats groups as a mere list of objects.
I may have contracted this habit back then but I’ve been using nVidias for some time already. For me, complex selections remain easier and faster using the Outliner though.
It is a perfectly valid request.
And, the biggest problem is the lack of instanced modifiers.
Deform Modifiers can use same reference object.
Then, one curve or empty can be considered as global gizmo of a selection in others softwares.
But values should be identical for all modifiers of all objects (which could be achieve by using drivers or keying sets).
Current workflow needs to copy modifiers from active and use of python for a lot of objects. It does not work for any kind of modifiers.
Only add-on and operators to copy modifiers is not really satisfying. Operators to delete modifiers are needed, too.
Lukas efforts to create a workflow with nodal modifiers seems to increase abilities.
But I don’t think it is really user-friendly to be forced to use node editor to add instanced modifiers and it was not an enough developed idea to be well integrated between modifiers of a standard modifier stack.
Groups were created for Elephant Dreams to facilitate linking and instancing. There was a time offset value that does not work anymore and was removed because of Animato(refactoring of 2.5 animation sytem).
Groups were initially thought as a final step of scene set-up and not as an helper for multi-object editing.
If it could replace “copy from selected” workflow; it would be great.
I think what we are talking about here are two different things. One is the object groups I suggested. I suggested it as a scene management tool - something that could be used for, say, an ornate chandelier with tens of individual parts, or a wall, modeled brick-by-brick. Using it merely as a helper to edit modifiers on multiple objects at a time would be awkward because you’d have to enter group edit mode each time merely to move the objects around with respect to each other.
The problem of editing properties on multiple objects is a separate one. One solution that I see is decoupling modifier stacks and sets of object properties from the actual objects and giving them their own datablocks, much like materials and node groups are handled now. It seems like a solution that would fit in well with the rest of Blender philosophy. However, care would have to be taken to make this as unobtrusive as possible from a UI standpoint since it could overcomplicate things for new users who don’t understand the datablock system. There are probably better solutions out there.
