Page MenuHome

Proposal: Parenting and Object Hierarchy Changes
Closed, InvalidPublicDESIGN

Description

Currently in Blender, there is a need for having groups of objects that behave as a single 'cohesive' object from the users perspective. The following operations when applied to one of these object groups should apply to every object in the group treating the entire hierarchy as if it was a single object.

  • Transformations
  • Copy/Paste/Duplicate/Delete
  • Applying Modifiers
  • Linking
  • Assigning to Collections
  • Setting scene visibility

Existing Solutions:

Collections:

Collections currently seem to be the most similar at face value to this concept of cohesive groups of objects but they solve a different problem of render and scene visibility and don't treat their children as a cohesive 'group' of objects from the standpoint of the above operations. Additionally, the same object can exist in multiple collections which would create issues with the above operations.

Parenting:

Similar to collections, object parenting (by default) treats all of its children as separate unrelated objects with the exception of Transformations. Some of the above operators (such as delete and duplicate) have alternative operators for applying them to the whole hierarchy, but these are not always entirely intuitive and discoverable. Others such as linking and applying modifiers simply have no suitable workflow available with parenting objects as it stands currently.


Proposal:

As the parenting use case of propagating transformations from one object to another is already satisfied by constraints in a much more clear, explicit, and controllable manner. Therefore I propose changing the default behaviour of objects in a parent / child relationship to treat that hierarchy as a first class citizen from the standpoint of all operations in Blender where it makes intuitive sense.

  • Transforming a parent object will also transform all of its lower hierarchy of objects. [No change from current behaviour]
  • "Copy / Paste / Duplicate / Delete" of a parent object will also apply to the entire hierarchy by default. [Change from current behaviour]
  • Changing the collection of a parent object (by dragging / dropping or Shift+M) will also impact the entire hierarchy of the selected object. [Change from current behaviour]
  • By default clicking the visibility icons in the outliner and using the hide or isolate operators will hide the whole hierarchy. Shift+Click could still be repurposed to hide just the single object without affecting the hierarchy in the outliner.[Change from current behaviour]
  • Applying modifiers to a parent object will also apply them to all children in the hierarchy. See sub-section on hierarchical modifiers for additional details.[Change from current behaviour]
  • Linking a parent object (both locally and file linking) will also link its entire hierarchy. See sub-section on hierarchical linking for additional details.[Change from current behaviour]

Hierarchical Modifiers:
Modifiers applied to a parent object will also impact all of its children. Note that this does NOT mean that applying a modifier to a parent will apply a separate copy of the modifier to the children in the hierarchy. This is an important distinction as changes to the modifier on the parent should immediately be reflected on all the children as well. In addition to that if you remove a child from the group, it should no longer have the parents modifiers applied to it. Therefore the modifier stack will have to be modified to apply to all children without actually being added to each child.

Hierarchical Linking:
Linking objects should also link all of their children as well as the hierarchy. Take a simple object hierarchy with a parent object "Parent" and a child object "Child" for example. If I link "Parent", any changes to "Child" should also be propagated to all linked instances. In addition, if I add a second child "Child2" then this should also be replicated in all linked instances of parent. Likewise, if I delete a child from the hierarchy, then it should also be removed from all linked instances.

Hierarchical Library File Linking:
There is the additional use case of linking in groups of objects from other .blend files. Doing this should also maintain the hierarchy as defined in the separate .blend file. Adding / Removing objects from the linked hierarchy in the Library .blend file should also automatically be propagated over to the "Master" file. In addition to this, adding "Library Overrides" to the parent object in the "Master" blend file should still maintain the whole object hierarchy and cause all child objects in the hierarchy to maintain their parent relationship to the overridden object.

Additional Operators:
A pass should be done on all existing operators to determine which other ones should operate on full object hierarchies, and which should just operate on individual objects.

Old BehaviourNew Behaviour
Modifiers
Collections
Duplicate
Delete
Linking
Library Override

Old Scene Migration:

Naturally, people who are using object linking, modifiers, and library overrides in previous versions of blender will probably not want their object hierarchies to behave this way by default upon opening their scenes in a newer version of blender, so care will have to be taken to provide a reliable upgrade path. I propose that when opening scenes saved on a version of blender before these changes that all existing objects that would be impacted by this change (objects with modifiers on them that also have children, or linked objects with children) are automatically converted to have their object hierarchies replaced with child constraints.

Event Timeline

Hello, I am a software engineer in the Vancouver, BC area interested in contributing to Blender. This is a proposal I had for how I feel object parenting and hierarchies should work in Blender. I would like to get some feedback on whether a change like this would be considered for Blender before I jump in and start coding it up. I would be fully willing to implement these changes (or some agreed upon variation of them) as well as help with maintenance (time permitted).

Hello @Morgan Davidson (modavi),

Thank you for the very well formatted and thorough design proposal. Unfortunately, this isn't the correct forum for such proposals.

The best place for this would be https://devtalk.blender.org, especially now that the tracker curfew is in effect.


Triager Note: Leaving this open as per @Nathan Letwory (jesterking)'s instructions on blender.chat

At a high level, the ability to treat multiple objects as if they were one object is a much needed missing feature in Blender, and would be useful in countless situations. However, I don't think I agree with this particular method.

In my opinion, parent/child hierarchies are something different, unrelated to this idea.

Instead, I think we should do one of two things:

  • Make improvements to Collection Instances

Blender already has the concept of many objects behaving as one - it's called a Collection Instance.
The problem is A, they are a hassle to set up and manage. B, you can't edit them in-place. And C, you can't apply things like modifiers to them.

We could address each of these issues, and we'd end up with a powerful grouping system that works nicely with Collections and also supports instancing, which is a major benefit.

  • Add a new object type container called Group

We could also add a new concept called 'group' next to Collections to do this kind of thing. IMO there isn't much benefit to this, since a few improvements to Collection Instances will give us the same result without having to introduce a new data type.

If you would like to discuss this in more detail, jump over to blender.chat

I actually agree with proposed design I am new blender user
And even though there are some improvements in 2.81 to the outliner

  • # I couldn't get my head around why deleting a Parent object does not Delete the child object
  • # Why hiding a Parent object doesn't hide the child objects
  • # If you hide a collection all the child objects are hidden
  • # But if You hide a parent object or mesh only that object is hidden

This is a very contradictory design and extremely annoying for new users like me

Especially when all the other softwares do things more logically

Hiding a Group/Collection hides all the childs, holding a parent mesh hides the child meshes etc

I believe blender should implement this proposed design

Deleting or modifying parent should modify the child
If you only want to affect the parent and not the child it can be added in the right click options

Plz add this proposal to rightclickseletct.com RightClickSelect and DevTalk

I also like what is proposed here. And I disagree to treat collection as a replacement or substitute for object hierarchies, they aren't really the same. Sure collections can be used for instancing and offer partially comparable things for scenemanagment as eg. empties, but as collections themselves have no editable transform, they are per definition no real substitute for object hierachies and I hope collections are seen as an additional tool for scene management but not as a way to remove object hierarchies with transforms as almost any other software out there has and throw it away and solve it once again somehow but differently. Empties and object hierachies are common, they are a simple and efficient solution for many usecases.

So even if I agree usage features like this could or should be applied to collections too, I just don't see why object hierarchies should be degraded to second class citizens in terms of usability or even get removed. The outliner should be able to handle it's hierachies well for object hierachies aswell as collections and instances.

Both concepts exist in blender, we have empties and hierachies next to collections and both of them should stay and get improved.

Both have usecases where they appeal more and I'd not want to see one go for the other.

So as AcidRain0 said could you please bring this to devtalk and Rightclickselect to discuss about it.

Oskar (Oskar) added a subscriber: Oskar (Oskar).

I appreciate the comments, and apologize for submitting this proposal in what appears to be the wrong venue. If this is not the right venue for such a discussion then I welcome the closure of this task and I can re-raise the discussion in the forums mentioned above.

I did have a productive discussion about this with William Reynish on chat a couple days ago and he raised some reasonable proposals that could be done to Collection Instances which I agree would be very beneficial and would help provide some of this functionality to Blender. I do however still believe that the way Blender views parenting as merely an secondary limited constraint type, and not actually as a proper object hierarchy is quite unintuitive for people coming from other software packages with more traditional hierarchy models in them. I do respect that Blender may have a different way of viewing objects and that there may be certain workflows or use cases that I'm not aware of which could take issue with such a change. As such I would defer to the people who know the workflows and the "Blender way" better than I do as to whether a change to parenting really does make sense or not.

I will bring this up for discussion in the above mentioned forums, so as mentioned, please feel free to do what you will with this task if this is not the correct forum to engage in such a discussion.

Campbell Barton (campbellbarton) closed this task as Invalid.EditedJan 2 2020, 7:57 AM

Design tasks are only meant to be created by module team members & active committers, closing.