Reevaluating Worldspace and Localspace Treatment (need some dev triage)

The worst is that when you move the father, the children lose their reference to the center of the world. Try to put them at 0,0,0 they will end up at an indefinite point in space (center of the world with the addition of the father’s traslation).
There is no advantage for beginners, only disadvantages.
Everyone knows that the Earth is spherical but some claim that the earth is flat!

1 Like

The new parent system should be:

  1. Set parent / object (without inverse) + (keep transform)

The two that are already present as options:
2. Set parent / object (without inverse)
3. Set parent / object (keep transform)

4 Likes

I was hoping that a dev would recognize it and respond to this first. But then lets start directly collecting what could be done. Here are my thoughts on it.

@ivan_stephan: Could you please rename this thread to something like “Reevaluating Worldspace and Localspace Treatment (needs triage by developer) " or " Dont’t click this thread!!!” ;). Mainly please change it to something that raises some attention by the devs and makes sense for what this is about.

I’d propose renaming and redesigning things here and add new essential features.
I thinkt this will be the fastest way to get it done, but maybe even rethinking the tree structure would make sense.

First things first: The User doesn’t need to know anything about that parent inverse matrix. This (without inverse) is uncommon, misleading, generally it isn’t understood well and should be eliminated.

  1. What we need is:
  • Convert to Worldspace
  • Convert to Localspace
  • Treat Values As Worldspace
  • Treat Values as Localspace

or do the same thing and call it alternatively

  • To Worldspace (Convert Values)
  • To Localspace (Convert Values)
  • To Worldpsace (Keep Values)
  • To Localspace (Keep Values)
  1. The “convert values” options are the only ones that make sense as default. So every parenting option in the outliner, the sidebar etc should work that way.
    And a preference for if a user prefers localspace or worldspace additions would be welcome.

  2. We also need a

  • “Group Objects in Empty” (Parenting to Empty)
  • “Dissolve Empty” (Remove an Empty and place the childs at the hierarchical level of the deleted empty, also with “Keep Values” or Convert Values" options)
  • “Delete Object without Children” ( Same thing for Objects as Dissolve Empty )
  • These should be avaiable in especially in the outliner context menu.
  1. Things like the “To Localspace” command should work on multiple objects and should work in the 3dview as well as the outliner and perhaps also in the transform panel, via context menus and shortcuts

  2. We need an Icon or a desciptor, or a even a toggle, in the transform section to make clear if this is localspace or wordspace.

  3. The Outliner needs some visual differentiation for this too. May it be little icon additions like the counter for mesh objects on folded entries, or different colors for the whole main icon

Things like this would be suffficient and that without the need of touching the internal treestructure at all.

I listed some of the drawbacks of the current implementation further above :

@julianeisel: I am not sure if you are the right one to ask, but you seem to be involved in the ui programming. Could you have a look at this? Lot’s of people miss these features and that way it shouldn’t be that much work. What do you think?

3 Likes

I agree on everything, but maybe it’s too much.
For now, as I have already suggested, it would be enough to add translation compensation to “Parent without inverse”.
In this way the child would remain in his place without moving to the center of the father.
When parent objects in the outliner with drag and drop, this should be the default option.
I repeat it works like this in all 3D software, ALL !!!
They are not all idiots, they do it because it is logical, because it works better.
I don’t want to do 8 steps to do things that are done with a single click.
Does Blender want to become a software for professionals or an open source experiment?
I want to use Blender, but there seem to be some insurmountable ideological barriers.

3 Likes

Normally I’d agree that a small set of features is easier to sell than a larger one. But if you think about it, there are no larger things in this proposal, nothing depends programmatically much on other parts much. Nearly all things listed could be implemented in an arbitrary order. This is just renaming some existing functions. Add some functions for some additional basic matrix multiplications. Going over a set of existing function calls and check that they are acting the same way. Some subtree traversals have to be made. The most complex work here is to perhaps the new Icon thing listed under point 6, as it needs some programming to display based on if the inverse_parent is equal to the identity matrix or not.

Even things like the “Dissolve Empty” isnt more than taking the list of direct children and transform them with the inverse matrix into the parent space.
For children in worldspace they have to be marked dirty recursively along the subtree and recalculated in level order in a final step.

It has to be added to some context menus and then it’s to big parts already done.

If the tree would have to be redesigned, yes that might have impact on many parts of blender one does not directly think of.
That’s why I asked for some feedback from the devs before, what route should be taken.

But now what we are asking for here is just doing things right that are generally in there for a long time. So the basic concept must be valid across blender already. It’s just about doing it right in detail. The fun thing here is, that even nothing is taken away. People who love to work as before would have no problem to do so.

And last but not least this is a discussion of what should be done to make it work.

I just got this bug/feature and it left med utterly baffled:

But my old bug report T68190 can’t be the only one, right? Nobody has linked anything else in this thread.

Also, I see you can open “design” reports now, which I think this is (if it really works “correctly”)…

1 Like

Do I get this right, the Camerapath origin is at local, right? Are we in frame 0 and how large is the curve?

Yes, yes and very long. :slight_smile:

Hmm, maybe this intentional. Really not sure here. The cam position comes from the calculation of the splinepos and the transform here just seems to represent an possible offset. Not sure why this should be neccessary as we also have an additional Delta Transform. I’d have said it should be greyed out and show the real pos,

What I’m thinking about most here is how large the distance seems to be between the curve and the cam, why is the cam offsetted at all?

Edit:Oh boy, yes the remaining offset is the parent inverse again.:upside_down_face:

So two things. The location is treated as an additional offset. and the big distance comes from what is stored in the parent inverse. Use the clear parent inverse option to remove that part

Thanks for the tip. I snapped the camera to the curve origin to get rid of the problem (and the location populated itself with whatever numbers Blender is comfortable with).

Again, this feels sadly like yet another example of power-user complexity dumped on a new user who couldn’t care less about how Blender functions internally (and goes against industry standard).

2 Likes

Yes, the parent inverse should go. It’s a good example why it’s a bad idea to have it.

Strange enough that clearing the parent inverse is located in the Clear Parent menu. Terrible.

1 Like

Blender has a " hidden matrix" to store the missing information for this local transforms. It’s completely crazy to think that I can’t do anything on the interface to change or see that info! This is not against industry standard, its a broken concept.

5 Likes

We have commissioned an add-on. It was delivered within 24 hours. Parenting now works as in all other software.
Given the ease with which we have solved the problem, it seems even more strange that the problem is not solved in the official version of Blender. Perhaps they are really convinced that everyone is wrong and they are right. I do not understand…

6 Likes

Yes, the developers are definitly stuck in and outdated “right click select, screw what everyone else is using” mindset on this one.

They closed my bug report with no intention to fix:

https://developer.blender.org/T68190

Again, the way that Blender developers handle “design issues” is still very bad, unfortunately.

5 Likes

Is this a publically available addon, or a private addon for your own use?

I have to ask the developer if I can distribute it.

2 Likes

Wow, still unsolved?

2 Likes

Trying to rig a wheel that requires agnostic rotation values, but one forward one - with a bone moving in Y or X locally along a path, as an examples - is impossible, as drivers or constraints only detect it’s local position relative to parent and/or global. And local position doesn’t read local rotation direction.

The need to have local and global values exposed and useful in the UI and general architecture is very necessary for good easy rigging, animation and troubleshooting. Right now the transforms feedback is not clear which space we are in and what the transforms values are. Getting these spaces, that do exist in the API, exposed to the user in the drivers, animation editors and transform editors should be imperative.

1 Like

Hi everyone,

Sorry to necroposting but… I have to bump this since to me It’s one of the most basic aspect of blender that need to be fixed…

I remember @sybren answering on another topic (that I’m not able to find right now), mentioning the documentation explaining blender parenting and coordinates and that it’s intended. But still…as many have already mentioned, the current way of displaying coordinates after parenting are just pointless. This is an old topic, and I found a 2011 post on blender artists pointing out the issue… and I’m really surprised that It’s still not fixed!

Just to recap and double check if I understand correctly:

When you parent an object to another, the child objects coordinates displayed are the ones in the moment of parenting. After moving, rotating and scaling the parent, without touching the child, you still see the original world space transformations values the child had at the moment of parenting. Those values are meaningless and have zero usefulness to me:

7 Likes

Hey folks.

TL;DR: no, this is not a bug, it is intentional behaviour. As such, it cannot be “fixed”, because it is not considered “broken”.

The manual section on Parenting Objects explains how this works. In short, there is a matrix called the Parent Inverse matrix. It is this matrix that sits between the parent & child transforms, and it is what makes it possible to (un)parent a child without moving it. By using this matrix it’s possible to even parent an already-animated object, without having to update the animation data.

I agree that Parent Inverse is not the most descriptive name. The fact that this matrix is hidden in the user interface (apart from a few cryptic mentions in some menus) doesn’t help either. The functionality that it offers isn’t going away any time soon, though.

I hope this helps to shed some light on the situation,
Sybren

1 Like