Child Object jumps away with changing the parent bone #80490

New Issue

Reiner Prokein · 2020-09-05T11:02:04+02:00

Reiner Prokein commented

2020-09-05 11:02:04 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.48

Blender Version
Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-04 21:32, hash: cf0ba59e31

Short description of error
When i parent an object to a bone, and change the parent in the object properties in the relations panel, then the child object jumps around. And switching back to the original object does not reposition the child object at the original position.

Exact steps for others to reproduce the error

Create a armature with at least two bones. Parent the default cube to the armature with method bones.
In the relations panel switch the parent bone to the second bone. The cube will jump away.
Switch back to the original bone. The cube will jump even further away. And will not go back to the original position.

Blend file is attached.

bonejumping.blend

bonejumping.mp4

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1060 6GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 451.48 **Blender Version** Broken: version: 2.91.0 Alpha, branch: master, commit date: 2020-09-04 21:32, hash: `cf0ba59e31` **Short description of error** When i parent an object to a bone, and change the parent in the object properties in the relations panel, then the child object jumps around. And switching back to the original object does not reposition the child object at the original position. **Exact steps for others to reproduce the error** Create a armature with at least two bones. Parent the default cube to the armature with method bones. In the relations panel switch the parent bone to the second bone. The cube will jump away. Switch back to the original bone. The cube will jump even further away. And will not go back to the original position. Blend file is attached. [bonejumping.blend](https://archive.blender.org/developer/F8843556/bonejumping.blend) [bonejumping.mp4](https://archive.blender.org/developer/F8843557/bonejumping.mp4)

Reiner Prokein commented

2020-09-05 11:02:04 +02:00

Added subscriber: @tiles

Philipp Oeser commented

2020-09-05 11:33:47 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-09-05 11:33:47 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2020-09-05 11:33:47 +02:00

This might have its reasons (afaict, it has always been like that).
Clearing parent inverse does not help.

Note: 2894e75121 was in that area (not even sure if that 'hack' is needed anymore)

This might have its reasons (afaict, it has always been like that). Clearing parent inverse does not help. Note: 2894e75121 was in that area (not even sure if that 'hack' is needed anymore)

Sybren A. Stüvel self-assigned this 2020-09-07 14:21:26 +02:00

Sybren A. Stüvel commented

2020-09-08 10:36:06 +02:00

I had to do some digging, but apparently this is intended behaviour. The underlying issue is that the {Key Ctrl P} operator performs a different action than just selecting the parent. Selecting the parent from the properties panel always resets the parent inverse matrix; it's also an issue that this matrix is invisible for users, and even the fact that it's set is not visible. You thus also can't see that this matrix has been cleared.

Changing the parent via the properties panel always clears the parent inverse matrix (see #41950), which is what causes the jump.

I had to do some digging, but apparently this is intended behaviour. The underlying issue is that the {Key Ctrl P} operator performs a different action than just selecting the parent. Selecting the parent from the properties panel always resets the parent inverse matrix; it's also an issue that this matrix is invisible for users, and even the fact that it's set is not visible. You thus also can't see that this matrix has been cleared. Changing the parent via the properties panel always clears the parent inverse matrix (see #41950), which is what causes the jump.

Sybren A. Stüvel commented

2020-09-08 10:45:06 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Sybren A. Stüvel closed this issue

2020-09-08 10:45:06 +02:00

Sybren A. Stüvel commented

2020-09-08 10:45:06 +02:00

Resolved by describing this behaviour in the Blender Manual. It'll appear at https://docs.blender.org/manual/en/dev/scene_layout/object/editing/parent.html#parent-inverse when the online manual gets updated.

Reiner Prokein commented

2020-09-08 12:40:51 +02:00

I have really big problems to understand the decision. How can a behaviour that kills a parent relationship be an expected and welcome behaviour?

Sybren A. Stüvel commented

2020-09-08 13:28:50 +02:00

The behaviour is working as designed, which means that this is not a bug in Blender's current implementation. I do agree that things are confusing, which I hope to have cleared up at least to some extent by explaining things better in the manual.

I think that describing Blender's behaviour as "killing" a parent relationship is a tad over-dramatic. Selecting a different parent from the menu resets the Parent Inverse matrix, and this has been the case since Blender 2.73. That's all that's happening. You can see this by, in your example, simply selecting Bone.002 as parent (it already was the parent, just re-select it as the parent by opening the drop-down and clicking on Bone.002), you will see the cube jump. Now switching back and forth between Bone.001 and Bone.002 will move the cube predictably.

The even-older behaviour of Blender was exactly what you're asking for: to keep the Parent Inverse matrix as-is when changing the parent. You can read in the description of #41950 that this was also confusing for people.

What we could do is to add an indicator of some kind to the Relations panel, indicating whether there is a Parent Inverse matrix set. That way it is at least visible that something changed in that regard, which would explain the jump.

The behaviour is working as designed, which means that this is not a bug in Blender's current implementation. I do agree that things are confusing, which I hope to have cleared up at least to some extent by explaining things better in the manual. I think that describing Blender's behaviour as "killing" a parent relationship is a tad over-dramatic. Selecting a different parent from the menu resets the Parent Inverse matrix, and this has been the case since Blender 2.73. That's all that's happening. You can see this by, in your example, simply selecting Bone.002 as parent (it already was the parent, just re-select it as the parent by opening the drop-down and clicking on Bone.002), you will see the cube jump. Now switching back and forth between Bone.001 and Bone.002 will move the cube predictably. The even-older behaviour of Blender was exactly what you're asking for: to keep the Parent Inverse matrix as-is when changing the parent. You can read in the description of #41950 that this was also confusing for people. What we could do is to add an indicator of some kind to the Relations panel, indicating whether there is a Parent Inverse matrix set. That way it is at least visible that something changed in that regard, which would explain the jump.

Reiner Prokein commented

2020-09-08 15:08:44 +02:00

Thanks for explanation. I don't doubt that it works as designed. I doubt the design. As told, i am in trouble to understand that breaking a relationship is wanted behaviour :)

Sorry when you find the term killed over dramatic. It was not my intention to introduce drama here. We can also use the term broken or destroyed. Fact is, as a user i have to unparent and to reparent the object. There is no fix. This relationship is broken now. And i don't think that documenting the breakage is a valid fix here. We would imho need something in the scope of a update matrix button or checkbox. User sees the object jump away, clicks the button, and object goes back to the location where it was and should be.

In the end i can just report it. It's of course your decision if you fix it. Thanks for listening and having a look.

Thanks for explanation. I don't doubt that it works as designed. I doubt the design. As told, i am in trouble to understand that breaking a relationship is wanted behaviour :) Sorry when you find the term killed over dramatic. It was not my intention to introduce drama here. We can also use the term broken or destroyed. Fact is, as a user i have to unparent and to reparent the object. There is no fix. This relationship is broken now. And i don't think that documenting the breakage is a valid fix here. We would imho need something in the scope of a update matrix button or checkbox. User sees the object jump away, clicks the button, and object goes back to the location where it was and should be. In the end i can just report it. It's of course your decision if you fix it. Thanks for listening and having a look.

Sybren A. Stüvel commented

2020-09-08 15:55:00 +02:00

I don't doubt that it works as designed. I doubt the design.

That's fair enough. I don't think this design deserves any beauty price, either.

Fact is, as a user i have to unparent and to reparent the object.

There are other approaches available to you. You can just select the bone (in the 3D viewport) you want as parent, and use Ctrl+P again to reparent the cube, just like you created the parent relation to begin with. Granted, this is a bit more cumbersome than just selecting the bone from a drop-down, but it's far from broken beyond repair. In short: there are two ways in which you can change an object's parent, one works the way you expect and the other doesn't.

This relationship is broken now.

It is not broken. Move the bone, and the child object will move along with it. The relation is fine, the child object is just in a place that you don't want. Move it to the place you do want, and you're done.

In your video, it looks like the cube jumps further and further away, every time you change the parent. This is not what is happening. The first time you change the parent like that, it resets some hidden matrix, and as a result the cube jumps. Every subsequent change of the parent is totally predictable. You change the parent to a bone that's positioned higher, the cube will move higher. You change it to a bone that's lower, the cube will move lower. It keeps the same position relative to the parent, whichever bone you select as the parent.

User sees the object jump away, clicks the button, and object goes back to the location where it was and should be.

Shift+S, Snap Cursor to Selection, change the parent, Shift+S, Snap Selection to Cursor.

> I don't doubt that it works as designed. I doubt the design. That's fair enough. I don't think this design deserves any beauty price, either. > Fact is, as a user i have to unparent and to reparent the object. There are other approaches available to you. You can just select the bone (in the 3D viewport) you want as parent, and use Ctrl+P again to reparent the cube, just like you created the parent relation to begin with. Granted, this is a bit more cumbersome than just selecting the bone from a drop-down, but it's far from broken beyond repair. In short: there are two ways in which you can change an object's parent, one works the way you expect and the other doesn't. > This relationship is broken now. It is not broken. Move the bone, and the child object will move along with it. The relation is fine, the child object is just in a place that you don't want. Move it to the place you do want, and you're done. In your video, it looks like the cube jumps further and further away, every time you change the parent. This is not what is happening. The first time you change the parent like that, it resets some hidden matrix, and as a result the cube jumps. Every subsequent change of the parent is totally predictable. You change the parent to a bone that's positioned higher, the cube will move higher. You change it to a bone that's lower, the cube will move lower. It keeps the same position relative to the parent, whichever bone you select as the parent. > User sees the object jump away, clicks the button, and object goes back to the location where it was and should be. Shift+S, Snap Cursor to Selection, change the parent, Shift+S, Snap Selection to Cursor.

Sybren A. Stüvel commented

2020-09-08 15:56:25 +02:00

Changed status from 'Resolved' to: 'Confirmed'

Sybren A. Stüvel reopened this issue

2020-09-08 15:56:25 +02:00

Sybren A. Stüvel commented

2020-09-08 15:56:25 +02:00

I've reopened this task as a To Do, as I do think it would be nice to have a way to change the parent from the Relations panel without resetting the Parent Inverse matrix. That'll require some UI design work as well.

Sybren A. Stüvel removed their assignment 2020-09-08 15:56:47 +02:00

Sybren A. Stüvel commented

2020-09-08 15:56:47 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2020-11-16 15:53:38 +01:00

Reclassifying this task from TODO to Design, as the task is not concrete enough to actually start implementation.
See the 2020-11-12 module meeting notes for more information.

Reclassifying this task from TODO to Design, as the task is not concrete enough to actually start implementation. See the [2020-11-12 module meeting notes](https://devtalk.blender.org/t/2020-11-12-animation-rigging-module-meeting/16092) for more information.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Child Object jumps away with changing the parent bone #80490