Reevaluating Worldspace and Localspace Treatment (need some dev triage)

Hi
I’m trying to understand blender parenting transformations.

If I parent two cubes using Ctrl+P (Object), the child cube transform isn’t changed to reflect the current parent, and still references the “world” coordinate system. If I reset its transform to (0,0,0), instead of centering in its new parent, it centers in the world. I don’t see any delta transform here that makes this transform possible.
I know that I can use the “Parent Object without inverse”, That way I have a correct transform coordinate, but the object will change the child position to the parent center.

Why blender keeps the world coordinate in the child node?

ps. this is my first post!! :partying_face:

thank you and all the best!!

7 Likes

I am glad that someone has mentioned this, as I have always find it extremely annoying! I do seem to remember someone writing a script to alleviate this, but I can’t find it now.

I just tend to only parent child objects when the parent is at world origin, but that is a poor workaround. When having to animate objects that should have a clean transform value, Blender’s behaviour on this issue is a real pita! Would be good if a dev could chime in on this one :smiley:

2 Likes

This is bizarre guys. Please someone tell me that there’s a solution to this.

Or maybe it’s a bug?

I just found this on RCS:

And yes, to me it looks like a bug.

1 Like

@ivan_stephan Yes some property doesn’t get updated properly after adding the child object.
You can force it to update by going to Object Properties -> Relations and set the Parent Type to “Object” once again. (in the child object)

If you did this the coordinate system of the child is treated correct as relative to its parent.

And if you call Clear Parent it will be positioned as if its local coordinates were worldspace coordinates.
Use the second option in Clear Parent to transform its coordinates to worldspace
( that way it will keep its position, but values change)

But yeah some fix is needed here

Edit: @billrey. Could you have a short look and confirm if its a known bug?

Hm, there’s something wrong here

2019-09-24_22-19-16

:thinking:

2 Likes

Are you talking about that jump? Before parenting the values were relative to the origin ( worldcoords) and now they are relative to the parent. The childs location and rotation values don’t get transformed.

But now try it with a shift+drag in the outliner

and then like you said:

So, same thing?

This system seems broken to me.

Yes principally the same thing.It’s not finished or buggy. Hard to tell what part was intentional and what not. But in the end a good solution would transform the values and keep the object in place visually. At least by default. Optional solutions may differ.

Here’s real parent/child situation:

2019-09-24_22-59-00

No weird movements, and when you zero out the child coordinates it jumps to the parent’s location.

Seriously, how can stuff like this be unnoticed, or is there an obscure setting we don’t know about?

Someone fill a bug report please.

4 Likes

Yes I am pretty sure they will get there. But right now its not consistent and broken

Yes I hope @billrey will do that if he reads it.
It’s really late on my side of the screen. :wink:

This issue has been there as long as I can remember (well over 10 years), so it is probably technically not considered a bug! It does really need to be addressed though.

@jamez Could you please explain more what you are referring to? Are you talking of that case below, or are the coordinates never transformed while getting a child? If the latter is the case and is what you mean I am fully with you then it definitely needs to be updated to be more 2019. Right now I can’t identify a usage that really does it handle well, right now it’s broken.

Here’s a video of what I mean. For me that is definitely a bug.
I don’t think there’s room left for other interpretations.

bug

  • The upper cube0 and cube1 and cube2 and cube3 get both put into a hierarchical structure with different methods.
  • The both cubes to the right have location x = 7
  • The both cubes to the left have location x = -2
  • After parenting both have still a local x position of 7
  • But they have different x positions in space
  • And its no missing screen refresh or stuff like that
  • It stays like that while rotating.
  • I don’t see how that should be no bug
1 Like

@Debuk, you are totally correct in that it shouldn’t work like this at all, and there is no logical reason for this behaviour. I thought this was going to be addressed with the changes in the dependency graph, but clearly not.

Blender has had this odd behavior for such a long time, and I have pointed it out to several people over the years, and no one could explain why it works like this. It could be one of those things that is deeply entrenched in Blender’s code and could break backward compatibility…who knows?

Would be great if one the Blender dev’s could chime in on this thread!

:astonished: Can’t believe that. That’s linear algebra, how can this be treated to be correct if a calculation carried out 2 times with the same values leads to two different results?

I will file a bug report on this and hope some dev will correct it.

My concern is that any correction in blender transform system could impact the transform data in scenes created before this patch.

The devteam archived my bug report and sent me this link

https://docs.blender.org/manual/en/dev/scene_layout/object/properties/relations/parents.html#parent-inverse

It’s a bit odd to to have a “hidden matrix” to control the transformation, or unnecessary extra steps to do a simple child transform.

1 Like

This can only be a joke, right?
If there’s a way to parent properly, then is should be the primary way of doing it.
And more, shift+ctrl+p does nothing here.

Also, when you clear parent inverse, the object jumps to another location.

There’s something weird happening here.

The hotkey for Make Parent without inverse is old, actually it doesn’t have any shortcut and it don’t have a menu entry, at least I didn’t see it. Could be a good papercut @billrey

What did you report? Was it just about that child coordinates being still world coords or did you also report anything about the inconsistency that I demoed in the gif animation?

Can I take a look at that bug report somewhere?