empty objects cannot have modifiers #44150
Short description of error
One of the recommended uses for empty objects is as a parent for a group of other objects:
"An Empty can be parented to any number of other objects -- This gives the user the ability to control a group of objects easily, and without affecting a render."
If this is done, it would then be very useful to be able to use the Array Modifier (and possibly others) to make multiple copies of the compound object. However, it appears that this is not currently possible; the Properties pane for empty objects does not offer a Modifiers tab.
Is there any rational reason for this restriction?
A related question would be, why is there no way that an empty object can be used to control the visibility of its children?
Thanks for the report, but that kind of discussion/request has nothing to do on our tracker, please rather use ML, IRC or forums.
That said, modifiers do not affect objects, they affect geometries (i.e. object’s data). Since empties have no data/geometry, they cannot have modifiers…
(as for visibility, pretty sure this is easily doable with drivers).
Apparently, even for non-empty objects, the Array modifier (and others?) is NOT applied to its child objects. This seems to make it much less useful than it would otherwise be, if it's not functional for compound objects.
Is there a reason why this should be so? Can recursive application at least be made an option?
Perhaps this bug should be retitled "modifiers are not applied to child objects". Until that becomes possible, there is obviously no reason why it would be useful for empty objects to have modifiers.
The two attached files are intended as examples of WHY it is desirable that modifiers be applicable to child objects, even of empty parents. Discussion to follow, if anybody's interested.
why is there no way that an empty object can be used to control the visibility of its children?
Apparently this is incorrect. The key recursively applies the visibility change to the child objects (why can't modifiers do that?).
But this is still the wrong algorithm. It means that if you have explicitly turned off visibility for some object, and then recursively turn visibility off and then on again for one of its ancestors, the object which you thought you had made invisible is now visible again, almost certainly against your wishes.
Compare to Inkscape: there the actual visibility status of an object is the logical AND of its own explicit visibility setting with that of all of its ancestors. If an object is set to invisible, turning one of its ancestors off and then on again will not make it visible. It's pretty hard to imagine a situation in which what Blender does would be preferable to this.
However, the situations are not exactly comparable, because in Inkscape, a parent object ("group") must necessarily be empty. Since it can't have any content of its own, its visibility setting only matters in relation to its descendents; there is no distinction to be made between recursive and non-recursive visibility.
In Blender, a parent object can have its own content; it is quite possible that you would want to have that visible, but not the children, or the other way around. Presumably this is what the recursive/non-recursive visibility controls are intended to address. But for the reasons given above, this is inadequate. What is really needed is that parent objects have two visibility controls (and two render controls?), one for their own content, and one for their descendents, which would function as a mask, as it does in Inkscape.
modifiers do not affect objects, they affect geometries (i.e. object’s data). Since empties have no data/geometry, they cannot have modifiers...
Their descendent objects presumably have both data and geometry; this is what the modifier would be applied to. I thought I had made this clear by quoting from the manual, about empty objects being used as parents.
I've just uploaded an example which seems impossible to accomplish in any other way. There would be a trivial solution, if modifiers were applied to child objects.
No due date set.
No dependencies set.
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?