Reevaluating Worldspace and Localspace Treatment (need some dev triage)

Somehow, but no not directly. The truth is that they try do make it all worldspace yes. But it’s a mixed reality. You don’t know it your current values of a child are worldspace or localspace. It’s not about having a toggle as you said, there’s a hidden matrix of what you can’t say how its currently setup. And what is also missing are all kind of comfort features during conversions from one system to the other. Because of that there are so many people complaining “hey my object jumps from here to there if I call this or that parenting or unparenting function”

And it seems not to be a conversion just at the user frontend, but is instead incorporated into the internal tree structure at least the documentation reads like that. This design is really completely off designed to how it would normally be done.

We need signs. " You broke my localspace, Give it back to me" - Big signs. :slightly_smiling_face:


It would be a shame to see this issue fall off the radar, especially with big projects like everything nodes and animation 2020 coming up that could be impacted by this.

Would be great to get some input from some core devs such as @brecht and @ideasman42


It is an easy problem to solve:
The command already exists: “set parent / object without inverse”.
Just add the child’s translation and rotation compensation.
Don’t tell me it’s hard to program.
We’d all stop going crazy !!
This is how it works in all 3d software (Softimage, Maya, 3D Max, Modo, Unity, etc.)


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)


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?


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.


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).


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.


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…


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:

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


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.


Wow, still unsolved?

1 Like