Proposal: Object Parenting UX #112758

New Issue

Demeter Dzadik · 2023-09-23T01:30:26+02:00

Demeter Dzadik commented

2023-09-23 01:30:26 +02:00

This proposal aims to make object parenting operations in Blender easier to understand and to use.

General goals:

Easier to learn for new users (who want things to just work™)
Clarifying for existing users (who memorized which options to use in which situations, but couldn't tell you why)
Faster for advanced users (who think P is just too damn far from Ctrl)
Be more visually spacious and pleasant to use for everyone! :)

Specific goals:

Avoid technical terms like Inverse Matrix and Local Space in the UI. In tooltips they can be acceptable, but should be kept to a minimum.
Tooltips are so important and useful. Every option should have a well-worded tooltip. Clarity and detail is a priority over compactness.
Choose less confusing and more useful default behaviours.
Reduce number of UI elements by organizing options better and hiding options that aren't relevant in the current context.
If an operator would do nothing, gray it out and have the tooltip explain why it's grayed out.
Operators must report what they did, so that it's clear even if nothing changed in the viewport (which is common with these operators).
Use icons where possible to help communicate functionality.

You can simply open this .blend file and press P with a couple objects selected, to try the Python prototype.

Combine `Ctrl+P` and `Alt+P` into a pie menu on `P`.

Ctrl+P and Alt+P are outrageous shortcuts that are really hard to press. Pie menus are better than regular menus with <9 options, especially for frequent operations. We can reduce the number of options by moving a lot of complexity into an operator which provides advanced parenting settings. Now they can easily be combined into a single pie menu that can be bound to just P, which can be pressed without cramping your pinky.

Current Operators	Proposed Pie

Button labels and tooltips:

Set Parent: "Parent the selected objects to the active one, while preserving their position in space"
Set Parent (Advanced): "Parent the selected objects to the active one" (Pop-up panel with settings, see below.)
Clear Parent: "Clear the parent of selected objects, while preserving their position in space"
Clear Parent (Without Correction): "Clear the parent of selected objects, without affecting their Loc/Rot/Scale values. This may cause the now parentless children to change position"
Clear Offset Correction: "Preserve the parenting relationship, but clear the correction offset, such that when the child's transforms are reset, it will move to the same position as the parent"

Two "Set Parent" operators: one fast & one powerful

Currently, the Ctrl+P menu offers a huge range of choices in behaviour which are difficult to understand, are poorly labelled, and lack tooltips.
With the current list UI, this is impossible to fix, because the number of entries increases multiplicatively with different options; There are 3-5 parenting methods (depending on parent object type), 3 different ways to handle the transforms, that's already 10+ different ways to do parenting, and half of those are already missing from this menu. For example, you can't do Vertex parenting with the Keep Transforms option.

So I propose two entries in the aforementioned pie menu:

Set Parent; The most commonly desired behaviour: Child never moves. Its local transforms are never affected. You get no choices, no customization, no thinking, just a lightning fast workflow.
Set Parent (Advanced); The operator for when, you want to do something fancy. No worries, everything has tooltips that actually explain what they do, and the mental model is much easier to understand because each step of the parenting behaviour is a separate drop-down selector (max 3 visible at a time).
- Parent Method
  - Object (Default)
  - Constraint
  - Armature/Curve/Lattice Modifier (Only for Armature, Curve, Lattice)
  - Bone: {Bone name} (Only for Armature, uses Relative Parenting)
  - (Legacy) Follow Path (Only for Curve. Tooltip mentions what option should be used instead of this.)
  - Nearest Vertex (Only for Mesh, Curve, Lattice)
  - Nearest Triangle (Only for Mesh, Curve, Lattice)
- Initialize Groups (Only if parent.type=='ARMATURE' and parent_method=='MODIFIER'
  - None: Do not initialize vertex groups on the child meshes.
  - Empty Groups: On all child meshes, generate empty vertex groups for each deforming bone of the parent Armature.
  - Auto-Weights: On all child meshes, generate Vertex Groups for the parent Armature's deforming bones, based on the mesh surface's proximity to each bone.
  - Auto-Weights (From Envelopes): On all child meshes, generate vertex groups using the parent Armature's bone envelopes.
- Constraint Type (Only if parent_method=='CONSTRAINT)
  - Copy Transforms (Default)
  - Child Of
  - Armature (Only if there's an active pose bone)
  - Follow Path (Only if Parent is a Curve)
- Keep Transform (visible unless using ChildOf/CopyTrans constraint, or if the parent is un-transformed in world space)
  Tooltip: "This parent is transformed. This will result in the child moving by the same amount when the relationship is created"
  - None: Simply create the parenting relationship, even if it may cause the children to be moved
  - Normal (Default): After creating the relationship, snap the children back to their original positions. This will affect their Loc/Rot/Scale values
  - Magic Offset: The child will not move and its Loc/Rot/Scale values won't be affected, even if the parent is transformed. This is done by storing an internal parenting offset value

Current	Proposed

Make "Keep Transforms Without Inverse" operations the default

For new users, both for setting and clearing the parent, the "Keep Transforms" option is the most intuitive and predictable; Your relationship is created/cleared, and your object does not move.

While parenting using the inverse matrix is useful to preserve a child's Loc/Rot/Scale values while still not having them fly away, this should be an advanced functionality that users don't always need, and it just results in confusion, so by default, this correction should just be applied to the children's local transforms.

Account for auto-keying

When a parenting operation affects the child's local transforms which are already keyed, and auto-keying is turned on, keys need to be inserted. Otherwise, the children will fly away on frame change.

Make Modifier-based parenting options explicit

The old menus were already capable of all of the following:

Creating Lattice/Curve/Armature modifiers when parenting to the respective object type
Run an automatic weight assignment algorithm when parenting to an Armature

Previously, it wasn't clear that they were creating modifiers. In my proposed UI, this is very explicit.

Expand Constraint-based parenting options

The Ctrl+P menu has an option to create a Follow Path constraint when parenting to curves, but it lacks similar options for using parenting-like constraints like Armature, Child Of, and Copy Transforms. I think it makes sense to include these, it essentially feels like they're missing. The operator already offers so many options with modifiers, and at least this one Follow Path constraint option, so adding more constraint-based options doesn't feel out of place.

Fix "Keep Transforms Without Inverse" not working with Vertex/Triangle Parenting

Noticed that this doesn't work while working on this proposal, I think is a matter of a small fix. Regular "Keep Transforms" does work.

Deprecate non-"Relative Parenting" on bones

In current Blender, when you parent an object to a bone, the child's behaviour changes based on a setting of the parent bone; "Relative Parenting". This is an odd implementation because if this was implemented on the child's side, it would suddenly be a lot more flexible.

When this option is off (current default), the object follows the bone even through edit-mode changes, which is inconsistent with bone-to-bone parenting.

I propose making it on by default, but also marking it as deprecated/legacy, to be removed in near future. Once it is removed, if people want something to follow a bone through edit-mode changes, they should use the Copy Transforms constraint.

These final points don't strongly relate to the Python Prototype shown above.

Remove "Path Animation" on curves

I don't want to go into detail on this in this proposal, at least for now. Short story is that the way we make objects follow curves in Blender is abysmal. AFAIK, this is being looked into by the Modeling Module.
For now, I just preserve the exisitng options; With or Without Follow Path Constraint. Without is marked as Legacy, since it should really be avoided. The constraint version will likely be much easier/safer to version when the new Curve type arrives.

Expose Parent Inverse Matrix

The Parent Inverse Matrix should be exposed in the UI, although without confusing or distracting non-advanced users. It doesn't need to be super visible at all, but at least be somewhere. This affects Object Parenting, Child Of Constraint, and Hook Modifier.

I would propose a sub-panel under "Properties Editor->Relations->Parent Inverse Matrix" for parenting, and a sub-panel with the same name on ChildOf/Hook. All 3 only need to be visible when said matrix isn't an "empty" one.

The purpose of this is so that users can at least see when this value changes, even if the actual numbers in the value aren't really useful. It is very useful for a (more advanced) user to understand that when they perform certain actions, like selecting a new vertex group in the Hook modifier, an internal matrix gets stored.

Remove Legacy Parenting Types

There is an actual "Armature" and "Lattice" parenting type, which allow you to avoid using the respective modifier. These were nice to keep around for legacy reasons, but now with 4.0 allowing major backwards compatibility breaks, I would offer them up for anyone who wants to delete a few lines of code (and probably add versioning). AFAIK, these features are already considered deprecated/legacy for a really long time.

This proposal aims to make object parenting operations in Blender easier to understand and to use. ### General goals: - Easier to learn for new users (who want things to just work™) - Clarifying for existing users (who memorized which options to use in which situations, but couldn't tell you why) - Faster for advanced users (who think `P` is just too damn far from `Ctrl`) - Be more visually spacious and pleasant to use for everyone! :) ### Specific goals: - Avoid technical terms like `Inverse Matrix` and `Local Space` in the UI. In tooltips they can be acceptable, but should be kept to a minimum. - Tooltips are so important and useful. Every option should have a well-worded tooltip. Clarity and detail is a priority over compactness. - Choose less confusing and more useful default behaviours. - Reduce number of UI elements by organizing options better and hiding options that aren't relevant in the current context. - If an operator would do nothing, gray it out and have the tooltip explain why it's grayed out. - Operators must report what they did, so that it's clear even if nothing changed in the viewport (which is common with these operators). - Use icons where possible to help communicate functionality. --------------------------------- You can simply open [this .blend file](/attachments/8bf69f85-ccfc-4a8d-868b-36bd6ad57e11) and press P with a couple objects selected, to try the Python prototype. ### Combine `Ctrl+P` and `Alt+P` into a pie menu on `P`. Ctrl+P and Alt+P are outrageous shortcuts that are really hard to press. Pie menus are better than regular menus with <9 options, especially for frequent operations. We can reduce the number of options by moving a lot of complexity into an operator which provides advanced parenting settings. Now they can easily be combined into a single pie menu that can be bound to just `P`, which can be pressed without cramping your pinky. | Current Operators | Proposed Pie | | --- | --- | | ![image](/attachments/c5021bc1-d675-43b9-9bcc-c32da3b6b864)![image](/attachments/9c78d6f8-1eab-4418-a72b-3f66cf6c5ea0) | ![image](/attachments/c5b03839-752e-410d-9138-7b258548e833) | Button labels and tooltips: - Set Parent: "Parent the selected objects to the active one, while preserving their position in space" - Set Parent (Advanced): "Parent the selected objects to the active one" (Pop-up panel with settings, see below.) - Clear Parent: "Clear the parent of selected objects, while preserving their position in space" - Clear Parent (Without Correction): "Clear the parent of selected objects, without affecting their Loc/Rot/Scale values. This may cause the now parentless children to change position" - Clear Offset Correction: "Preserve the parenting relationship, but clear the correction offset, such that when the child's transforms are reset, it will move to the same position as the parent" ### Two "Set Parent" operators: one fast & one powerful Currently, the Ctrl+P menu offers a huge range of choices in behaviour which are difficult to understand, are poorly labelled, and lack tooltips. With the current list UI, this is impossible to fix, because the number of entries increases multiplicatively with different options; There are 3-5 parenting methods (depending on parent object type), 3 different ways to handle the transforms, that's already 10+ different ways to do parenting, and half of those are already missing from this menu. For example, you can't do Vertex parenting with the Keep Transforms option. So I propose two entries in the aforementioned pie menu: 1. Set Parent; The most commonly desired behaviour: Child never moves. Its local transforms are never affected. You get no choices, no customization, no thinking, just a lightning fast workflow. 2. Set Parent (Advanced); The operator for when, you want to do something fancy. No worries, everything has tooltips that actually explain what they do, and the mental model is much easier to understand because each step of the parenting behaviour is a separate drop-down selector (max 3 visible at a time). - **Parent Method** ![image](/attachments/1c01a90e-3e15-4c88-926e-5de6171544ca) - Object (Default) - Constraint - Armature/Curve/Lattice Modifier `(Only for Armature, Curve, Lattice)` - Bone: {Bone name} `(Only for Armature, uses Relative Parenting)` - (Legacy) Follow Path `(Only for Curve. Tooltip mentions what option should be used instead of this.)` - Nearest Vertex `(Only for Mesh, Curve, Lattice`) - Nearest Triangle `(Only for Mesh, Curve, Lattice)` - **Initialize Groups** (Only `if parent.type=='ARMATURE' and parent_method=='MODIFIER'` ![image](/attachments/a7ca0f51-beb4-4070-b4e1-48a4c844e2e4) - None: *Do not initialize vertex groups on the child meshes.* - Empty Groups: *On all child meshes, generate empty vertex groups for each deforming bone of the parent Armature.* - Auto-Weights: *On all child meshes, generate Vertex Groups for the parent Armature's deforming bones, based on the mesh surface's proximity to each bone.* - Auto-Weights (From Envelopes): *On all child meshes, generate vertex groups using the parent Armature's bone envelopes.* - **Constraint Type** (Only `if parent_method=='CONSTRAINT`) - Copy Transforms (Default) - Child Of - Armature `(Only if there's an active pose bone)` - Follow Path `(Only if Parent is a Curve)` - **Keep Transform** (visible unless using ChildOf/CopyTrans constraint, or if the parent is un-transformed in world space) Tooltip: "This parent is transformed. This will result in the child moving by the same amount when the relationship is created" ![image](/attachments/efb67d7e-0c67-4b71-813c-b6a40c354675) - None: *Simply create the parenting relationship, even if it may cause the children to be moved* - Normal (Default): *After creating the relationship, snap the children back to their original positions. This will affect their Loc/Rot/Scale values* - Magic Offset: *The child will not move and its Loc/Rot/Scale values won't be affected, even if the parent is transformed. This is done by storing an internal parenting offset value* ### Header menu cleanup: | Current | Proposed | | --- | --- | | ![image](/attachments/1405f903-66dd-4711-8413-c0f70039bf9b) | ![image](/attachments/9fccfb52-a892-4cb6-884f-f97ce043f383) | ### Make "Keep Transforms Without Inverse" operations the default For new users, both for setting and clearing the parent, the "Keep Transforms" option is the most intuitive and predictable; Your relationship is created/cleared, and your object does not move. While parenting using the inverse matrix is useful to preserve a child's Loc/Rot/Scale values while still not having them fly away, this should be an advanced functionality that users don't always need, and it just results in confusion, so by default, this correction should just be applied to the children's local transforms. ### Account for auto-keying When a parenting operation affects the child's local transforms which are already keyed, and auto-keying is turned on, keys need to be inserted. Otherwise, the children will fly away on frame change. ### Make Modifier-based parenting options explicit The old menus were already capable of all of the following: - Creating Lattice/Curve/Armature modifiers when parenting to the respective object type - Run an automatic weight assignment algorithm when parenting to an Armature Previously, it wasn't clear that they were creating modifiers. In my proposed UI, this is very explicit. ### Expand Constraint-based parenting options The Ctrl+P menu has an option to create a Follow Path constraint when parenting to curves, but it lacks similar options for using parenting-like constraints like Armature, Child Of, and Copy Transforms. I think it makes sense to include these, it essentially feels like they're missing. The operator already offers so many options with modifiers, and at least this one Follow Path constraint option, so adding more constraint-based options doesn't feel out of place. ### Fix "Keep Transforms Without Inverse" not working with Vertex/Triangle Parenting Noticed that this doesn't work while working on this proposal, I think is a matter of a small fix. Regular "Keep Transforms" does work. ### Deprecate non-"Relative Parenting" on bones In current Blender, when you parent an object to a bone, the child's behaviour changes based on a setting of the parent bone; "Relative Parenting". This is an odd implementation because if this was implemented on the child's side, it would suddenly be a lot more flexible. When this option is off (current default), the object follows the bone even through edit-mode changes, which is inconsistent with bone-to-bone parenting. I propose making it **on by default**, but also marking it as deprecated/legacy, to be removed in near future. Once it is removed, if people want something to follow a bone through edit-mode changes, they should use the Copy Transforms constraint. ------------------------------------ These final points don't strongly relate to the Python Prototype shown above. ### Remove "Path Animation" on curves I don't want to go into detail on this in this proposal, at least for now. Short story is that the way we make objects follow curves in Blender is abysmal. AFAIK, this is being looked into by the Modeling Module. For now, I just preserve the exisitng options; With or Without Follow Path Constraint. Without is marked as Legacy, since it should really be avoided. The constraint version will likely be much easier/safer to version when the new Curve type arrives. ### Expose Parent Inverse Matrix The Parent Inverse Matrix should be exposed in the UI, although without confusing or distracting non-advanced users. It doesn't need to be super visible at all, but at least be *somewhere*. This affects Object Parenting, Child Of Constraint, and Hook Modifier. I would propose a sub-panel under "Properties Editor->Relations->Parent Inverse Matrix" for parenting, and a sub-panel with the same name on ChildOf/Hook. All 3 only need to be visible when said matrix isn't an "empty" one. The purpose of this is so that users can at least see when this value changes, even if the actual numbers in the value aren't really useful. It is very useful for a (more advanced) user to understand that when they perform certain actions, like selecting a new vertex group in the Hook modifier, an internal matrix gets stored. ### Remove Legacy Parenting Types There is an actual "Armature" and "Lattice" parenting type, which allow you to avoid using the respective modifier. These were nice to keep around for legacy reasons, but now with 4.0 allowing major backwards compatibility breaks, I would offer them up for anyone who wants to delete a few lines of code (and probably add versioning). AFAIK, these features are already considered deprecated/legacy for a really long time.

image.png

21 KiB

image.png

18 KiB

image.png

29 KiB

image.png

17 KiB

image.png

7.3 KiB

image.png

24 KiB

image.png

67 KiB

parenting_ux.blend

903 KiB

image.png

25 KiB

👍 4 👀 1 ❤️ 2

Demeter Dzadik added the

Type

To Do

label 2023-09-23 01:30:26 +02:00

Demeter Dzadik changed title from ~~Proposal: Parenting UX~~ to Proposal: Parenting UX

2023-09-23 01:31:19 +02:00

Demeter Dzadik changed title from ~~Proposal: Parenting UX~~ to Proposal: Object Parenting UX

2023-09-23 01:32:43 +02:00

Demeter Dzadik referenced this issue

2023-09-23 01:52:53 +02:00

Proposal: Bone Parenting UX #112760

Nika Kutsniashvili commented

2023-09-23 02:54:40 +02:00

I like general direction of this proposal very much, but I think in some aspects you've overcomplicated it when it can be even simpler. I think you're looking at it from professional riggers perspective, but parenting is very basic operation that every user does regardless of their experience and task at hand.

This is how I would modify this:

Some naming changes you made are great. But some are too technical. Technical descriptions can be kept in tooltips, while title shows simpler description. For example:

Clear Parent (Preserve World Space) and Clear Parent (Inverse Matrix) sound much too scary for new user to touch, even experienced one in some cases, but they're very basic. I think current names are better.
Weights by Proximity - Scary! (also proximity to what?) Automatic Weights - Less job for me! People might refrain from using Bone Proximity because it looks like you need to understand lot of things to know what it does, when it's too simple.
Local Matrix - Scary! Keep Transform - Easy to guess

Parent (Keep Transform) is used too often to be buried in other menu. And since there is empty space in Pie menu on Parenting side, I think you can add it there as third option. Align Keep Transforms on top side for both Clear and Parent, and bottom can be Inverse and Advanced
Curve and Lattice modifiers are not technically parenting. I understand it would be quick way and can improve UX, but it can introduce confusion as to what exactly parenting is. They can have separate operator that simply does that. They're simply modifiers with object inputs. Also there might be conflict if either of modifiers is replaced by built in geonodes modifier in the future. Parenting Types can be = Object, Armature, Constraint (Follow Path should go there as a constraint), Bone (legacy), Vertex, and Triangle. That way it's easier to understand all your options

I agree with you that blurrying the line between parenting and constraints is a good thing. When I teach I say constraints are parenting with more options, its very easy to grasp. Also, if Ctrl P - Parent added Copy Transforms constraint and 'Relations' panel was removed alltogether, would anyone really mind?

I like general direction of this proposal very much, but I think in some aspects you've overcomplicated it when it can be even simpler. I think you're looking at it from professional riggers perspective, but parenting is very basic operation that every user does regardless of their experience and task at hand. This is how I would modify this: 1. Some naming changes you made are great. But some are too technical. Technical descriptions can be kept in tooltips, while title shows simpler description. For example: * Clear Parent (Preserve World Space) and Clear Parent (Inverse Matrix) sound much too scary for new user to touch, even experienced one in some cases, but they're very basic. I think current names are better. * Weights by Proximity - Scary! (also proximity to what?) Automatic Weights - Less job for me! People might refrain from using Bone Proximity because it looks like you need to understand lot of things to know what it does, when it's too simple. * Local Matrix - Scary! Keep Transform - Easy to guess 2. Parent (Keep Transform) is used too often to be buried in other menu. And since there is empty space in Pie menu on Parenting side, I think you can add it there as third option. Align Keep Transforms on top side for both Clear and Parent, and bottom can be Inverse and Advanced 3. Curve and Lattice modifiers are not technically parenting. I understand it would be quick way and can improve UX, but it can introduce confusion as to what exactly parenting is. They can have separate operator that simply does that. They're simply modifiers with object inputs. Also there might be conflict if either of modifiers is replaced by built in geonodes modifier in the future. Parenting Types can be = Object, Armature, Constraint (Follow Path should go there as a constraint), Bone (legacy), Vertex, and Triangle. That way it's easier to understand all your options I agree with you that blurrying the line between parenting and constraints is a good thing. When I teach I say constraints are parenting with more options, its very easy to grasp. Also, if Ctrl P - Parent added Copy Transforms constraint and 'Relations' panel was removed alltogether, would anyone really mind?

RedMser commented

2023-09-23 03:01:19 +02:00

Instead of having an advanced parenting operator that opens a modal, why not just have one parenting operator and allow configuring the parenting type in the "adjust last operation" panel? So regular object parent is still default behavior, but you can easily change the type to others without two operators.

Demeter Dzadik commented

2023-09-23 22:01:10 +02:00

Thanks a lot for the feedback! They really highlight the problems that I'm trying to solve here, since there is already a lot of incorrect assumptions about what Blender's current parenting operations actually do. I encourage everyone to try them out in Blender first, before trying to provide feedback, otherwise the thread will get quite derailed. But I don't mean to scold anyone, as I think you still do highlight things in the current proposal that remain confusing, and need to be simplified further, which is very useful.

you're looking at it from professional riggers perspective, but parenting is very basic operation that every user does regardless of their experience and task at hand.

I try not to! The point of providing a basic button where the behaviour is always consistent, intuitive, and predictable, is so new users can just use it without thinking about it.

Clear Parent (Inverse Matrix) sound much too scary for new user to touch

I don't agree that the behaviour of this button is basic, since it seems to be confusing you as well. This button does not clear the parent. It never has. It clears the inverse matrix... That said, I agree that this can be better.
How about this: "Clear Offset Correction", with the tooltip: "Preserve the parenting relationship, but clear the correction offset, such that when the child's transforms are reset, it will move to the same position as the parent"?

Clear Parent (Preserve World Space) sound much too scary for new user to touch

I agree with this too, and thought about it. In my current proposal, the "Set Parent" and "Clear Parent" options are a bit assymetrical: The child will never move when using "Set Parent", but that's not the case when using "Clear Parent".
How about this: Make these options symmetrical, by making them both use keep_transforms=True. Then, in the top-left of the pie, we could have "Clear Parent (Without Correction)", which will leave the child's local transforms untouched, and it says what it does without mentioning matrices or spaces.

People might refrain from using Bone Proximity because it looks like you need to understand lot of things to know what it does, when it's too simple

I agree that "Automatic Weights" is a super great name. There's only one problem: There are TWO Automatic Weights algorithms in Blender. One uses the proximity of the mesh to each bone's head and tail, while the other uses the boundaries of the bone envelopes. Both are equally automatic. Allowing the UI to imply that the difference between these two operations has to do with automation is not satisfactory imo.
How about this: "Automatic Weights" and "Automatic Weights (Bone Envelopes)" (latter is a bit long but maybe acceptable)

Local Matrix - Scary! Keep Transform - Easy to guess

Again, there are TWO behaviours that will EQUALLY preserve the world-space transformation of the child. You can either use the hidden Inverse Matrix, or you can modify the child's local matrix. In both cases, the transforms are kept, which is the confusion I'm trying to remedy here.
How about this: The drop-down menu itself is called "Keep Transforms Method" with the options "None", "Magic", and "Normal", and we default to "Normal". I'm serious about using the word Magic! The Inverse Matrix implementation is intended to be a magical solution that a user isn't really meant to understand. They parent a child to a transformed parent, and the child doesn't fly away, even though its local transforms aren't messed with. No word is more accurate and artist-friendly. The description can then say: "The child will not move and its Loc/Rot/Scale values won't be affected, even if the parent is transformed." Also, if the parent is not transformed, this button doesn't even need to be drawn.

Curve and Lattice modifiers are not technically parenting

I did not invent and add these options. These are in Blender's Ctrl+P menu today, and have been for a very long time. Just parent a mesh to a Curve/Lattice. They're also no more specific or arbitrary than the complex Armature parenting convenience features discussed above.

the "adjust last operation" panel

IMO reliance on this panel is not great UX since the panel may be closed and all the options are hidden so you won't know about them unless you know about them. It's undiscoverable, and shouldn't be a part of the core UX of any operator. That said, the Redo panel should of course still be usable with both operators, that's a good point.

I will try to update the proposal with these new ideas in the coming days. Thanks again for the feedback thus far!

Thanks a lot for the feedback! They really highlight the problems that I'm trying to solve here, since there is already a lot of incorrect assumptions about what Blender's current parenting operations actually do. I encourage everyone to try them out in Blender first, before trying to provide feedback, otherwise the thread will get quite derailed. But I don't mean to scold anyone, as I think you still do highlight things in the current proposal that remain confusing, and need to be simplified further, which is very useful. > you're looking at it from professional riggers perspective, but parenting is very basic operation that every user does regardless of their experience and task at hand. I try not to! The point of providing a basic button where the behaviour is always consistent, intuitive, and predictable, is so new users can just use it without thinking about it. > Clear Parent (Inverse Matrix) sound much too scary for new user to touch I don't agree that the behaviour of this button is basic, since it seems to be confusing you as well. This button **does not clear the parent**. It never has. It clears the inverse matrix... That said, I agree that this can be better. **How about this**: "Clear Offset Correction", with the tooltip: "Preserve the parenting relationship, but clear the correction offset, such that when the child's transforms are reset, it will move to the same position as the parent"? > Clear Parent (Preserve World Space) sound much too scary for new user to touch I agree with this too, and thought about it. In my current proposal, the "Set Parent" and "Clear Parent" options are a bit assymetrical: The child will never move when using "Set Parent", but that's not the case when using "Clear Parent". **How about this**: Make these options symmetrical, by making them both use `keep_transforms=True`. Then, in the top-left of the pie, we could have "Clear Parent (Without Correction)", which will leave the child's local transforms untouched, and it says what it does without mentioning matrices or spaces. > People might refrain from using Bone Proximity because it looks like you need to understand lot of things to know what it does, when it's too simple I agree that "Automatic Weights" is a super great name. There's only one problem: There are TWO Automatic Weights algorithms in Blender. One uses the proximity of the mesh to each bone's head and tail, while the other uses the boundaries of the bone envelopes. Both are equally automatic. Allowing the UI to imply that the difference between these two operations has to do with automation is not satisfactory imo. **How about this**: "Automatic Weights" and "Automatic Weights (Bone Envelopes)" (latter is a bit long but maybe acceptable) > Local Matrix - Scary! Keep Transform - Easy to guess Again, there are TWO behaviours that will EQUALLY preserve the world-space transformation of the child. You can either use the hidden Inverse Matrix, or you can modify the child's local matrix. In both cases, the transforms are kept, which is the confusion I'm trying to remedy here. **How about this**: The drop-down menu itself is called "Keep Transforms Method" with the options "None", "Magic", and "Normal", and we default to "Normal". I'm serious about using the word Magic! The Inverse Matrix implementation is intended to be a magical solution that a user isn't really meant to understand. They parent a child to a transformed parent, and the child doesn't fly away, even though its local transforms aren't messed with. No word is more accurate and artist-friendly. The description can then say: "The child will not move and its Loc/Rot/Scale values won't be affected, even if the parent is transformed." Also, if the parent is not transformed, this button doesn't even need to be drawn. > Curve and Lattice modifiers are not technically parenting I did not invent and add these options. These are in Blender's Ctrl+P menu today, and have been for a very long time. Just parent a mesh to a Curve/Lattice. They're also no more specific or arbitrary than the complex Armature parenting convenience features discussed above. > the "adjust last operation" panel IMO reliance on this panel is not great UX since the panel may be closed and all the options are hidden so you won't know about them unless you know about them. It's undiscoverable, and shouldn't be a part of the core UX of any operator. That said, the Redo panel should of course still be usable with both operators, that's a good point. ------------------------------- I will try to update the proposal with these new ideas in the coming days. Thanks again for the feedback thus far!

Nathan Vegdahl commented

2023-09-25 12:53:25 +02:00

I'm generally in favor of this proposal. We might want some further iteration on it, but the direction is really good. Thanks for putting this together @Mets!

Some more thoughts:

The Parent Inverse Matrix should be exposed in the UI

I super agree with this. I think this being hidden is a big part of what makes parenting so confusing. If we make it an obvious visible thing, then people can see what's going on and start to grasp how things work.

Additionally, there's IMO a weird redundancy between the parent inverse matrix and delta transforms. Delta transforms more-or-less serve the same purpose (basically giving a "rest pose" to object transforms), but aren't used for this. And yet, delta transforms are user-visible (albeit a bit buried and obscure). So we're in this weird situation where we have a user-exposed rest transform (delta transform) that's almost never used, and a user-hidden rest transform (parent inverse matrix) that's used all the time.

I would really like to see these two things unified in some way. And maybe this is a good time to do that.

(We've also had some discussions within the animation module about generalizing the concept of rest transforms/poses, to allow objects and armatures to have more than one. Then you could e.g. have a different rest pose for animation vs deformation. Not sure if that should be tackled at the same time, though.)

if that means blurring the line between Constraints and Parenting, perhaps that's a good thing, signalling that the complete unification of these two concepts into one is on the horizon.

I don't think we should blur the line between the two without actually unifying them into a single system. That said, I am in favor of actually unifying them at some point. But I also think that will require a lot of care to do well without introducing a lot of UX footguns, and is probably more of a long-term goal.

So for this, I think we should just focus on improving the menus and UI to make the existing behaviors clear.

Deprecate non-"Relative Parenting" on bones. I propose making it on by default, but also marking it as deprecated/legacy

Very much agree with this. This has bugged me for a while.

I'm generally in favor of this proposal. We might want some further iteration on it, but the direction is really good. Thanks for putting this together @Mets! Some more thoughts: > The Parent Inverse Matrix should be exposed in the UI I *super* agree with this. I think this being hidden is a big part of what makes parenting so confusing. If we make it an obvious visible thing, then people can see what's going on and start to grasp how things work. Additionally, there's IMO a weird redundancy between the parent inverse matrix and delta transforms. Delta transforms more-or-less serve the same purpose (basically giving a "rest pose" to object transforms), but aren't used for this. And yet, delta transforms *are* user-visible (albeit a bit buried and obscure). So we're in this weird situation where we have a user-exposed rest transform (delta transform) that's almost never used, and a user-hidden rest transform (parent inverse matrix) that's used all the time. I would really like to see these two things unified in some way. And maybe this is a good time to do that. (We've also had some discussions within the animation module about generalizing the concept of rest transforms/poses, to allow objects and armatures to have more than one. Then you could e.g. have a different rest pose for animation vs deformation. Not sure if that should be tackled at the same time, though.) > if that means blurring the line between Constraints and Parenting, perhaps that's a good thing, signalling that the complete unification of these two concepts into one is on the horizon. I don't think we should blur the line between the two without *actually* unifying them into a single system. That said, I am in favor of actually unifying them at some point. But I also think that will require a lot of care to do well without introducing a lot of UX footguns, and is probably more of a long-term goal. So for this, I think we should just focus on improving the menus and UI to make the existing behaviors clear. > Deprecate non-"Relative Parenting" on bones. I propose making it on by default, but also marking it as deprecated/legacy *Very much* agree with this. This has bugged me for a while.

Demeter Dzadik commented

2023-09-25 13:30:13 +02:00

I updated the proposal with some high-level goals in the beginning, my ideas based on Nika's feedback, and some more specifics about one idea for exposing the inverse matrix. This was before I read Nathan's comment, so that inverse matrix stuff is likely still going to change.

Delta transforms more-or-less serve the same purpose (basically giving a "rest pose" to object transforms)

That's a very interesting and good point. I wonder if we could then just deprecate the inverse matrix altogether (still keeping the internal struct for backwards comp), and having the "Keep Transforms" options use the Delta Transforms instead.

Would there be people who would be annoyed that now they don't have enough transform channels for their objects? Do we need an infinitely stackable number of transforms to satisfy everybody? :D Or just, exactly 3, and turn the Inverse Matrix into another one? (Perhaps read-only?)

I don't think we should blur the line between the two without actually unifying them into a single system.

Fair! But in this case, I'd like to use a different justification (my plan B!) for the inclusion of Armature/ChildOf/CopyTrans constraint in the parenting operation: Parenting in Blender was never as technically strict as two objects affecting each other's transforms. The operator always had options that created additional modifiers (Lattice, Armature, Curve), and in one case, to use a constraint instead of creating a parenting relationship (Path Constraint for curves).
Heck, the current operator will even go as far as generating weights on your meshes. It really feels like it wants to be a super powerful, almost add-on-like operator, which I don't think is such a bad thing, as long as it's well maintained.

So for that reason, the inclusion of these constraints feels more like filling up gaps rather than breaking new ground. I'll update the wording of the proposal to use this justification instead, lmk what you think.

I updated the proposal with some high-level goals in the beginning, my ideas based on Nika's feedback, and some more specifics about one idea for exposing the inverse matrix. This was before I read Nathan's comment, so that inverse matrix stuff is likely still going to change. > Delta transforms more-or-less serve the same purpose (basically giving a "rest pose" to object transforms) That's a very interesting and good point. I wonder if we could then just deprecate the inverse matrix altogether (still keeping the internal struct for backwards comp), and having the "Keep Transforms" options use the Delta Transforms instead. Would there be people who would be annoyed that now they don't have enough transform channels for their objects? Do we need an infinitely stackable number of transforms to satisfy everybody? :D Or just, exactly 3, and turn the Inverse Matrix into another one? (Perhaps read-only?) > I don't think we should blur the line between the two without actually unifying them into a single system. Fair! But in this case, I'd like to use a different justification (my plan B!) for the inclusion of Armature/ChildOf/CopyTrans constraint in the parenting operation: Parenting in Blender was never as technically strict as two objects affecting each other's transforms. The operator always had options that created additional modifiers (Lattice, Armature, Curve), and in one case, to use a constraint **instead of** creating a parenting relationship (Path Constraint for curves). Heck, the current operator will even go as far as generating weights on your meshes. It really feels like it wants to be a super powerful, almost add-on-like operator, which I don't think is such a bad thing, as long as it's well maintained. So for that reason, the inclusion of these constraints feels more like filling up gaps rather than breaking new ground. I'll update the wording of the proposal to use this justification instead, lmk what you think.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Proposal: Object Parenting UX #112758

General goals:

Specific goals:

Combine Ctrl+P and Alt+P into a pie menu on P.

Two "Set Parent" operators: one fast & one powerful

Header menu cleanup:

Make "Keep Transforms Without Inverse" operations the default

Account for auto-keying

Make Modifier-based parenting options explicit

Expand Constraint-based parenting options

Fix "Keep Transforms Without Inverse" not working with Vertex/Triangle Parenting

Deprecate non-"Relative Parenting" on bones

Remove "Path Animation" on curves

Expose Parent Inverse Matrix

Remove Legacy Parenting Types

Combine `Ctrl+P` and `Alt+P` into a pie menu on `P`.