The devteam archived my bug report and sent me this link
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?
I found some time to take a look at it in the meantime. And yes that parent-inverse is potentially part of the problem I described with the animated gif. But the math behind it may be intact. The bug is more an inconsistent and falsely triggered behaviour. But anyhow it has to get fixed. Both variants are just different triggers for the same simple parenting. step. So they should behave the same. Also setting the parent type to object should have no influence on the parent_inverse. But as it changes the position in space, so it obviously has. That’s definitely a bug
You don’t control it with that hidden matrix. You control the child still with the transform parameters location, rotation and scale in the the childs object properties. That hidden matrix itself is there to kills the influence of all transforms that are above the child in the hierarchy. So the parentinverse matrix changes the final values but is itself in most aspects out of your control. You can allow blender to set it while parenting, you can clear it, but I think you can’t even reactivate it once its cleared as far as I can see.
Yes that may happen. Thats no error. The problem here is that the values presented to the user are not the complete calculation as blender is doing it diffently than any other tool out there and partially hides the values of the calculation that is done internally. That is ridiculous
The truth is even worse. I’ve gone completely through the existing tools to influence the parent child relation and what is there won’t give you a chance to mimic other tools. I’ll try to explain it abit more in a separate post Sot sadly its not just about what should be the primary option. The secondary is just possible if you fix every transform MANUALLY! I The featureset to control it is incomplete and raw . The whole motivation seems old and the idea of everything should be in worldcoords doesn’t fit for a modern tool that is normally part of a complex toolchain of 3dtools, engines and alike… where none of them shares that idea.
1 Like
How are object hierarchies typically handled?
The object hierarchy in a 3d modeler or game engine normally consists of treelike structured “stacks” of matrices. As every object in a such a scene tree has such a matrix and everyone is interpreted to be relative to its parent, each matrix is operating in its parents space. We can multiply the matrices to get the final transform for calculating final positions for vertices of a child. Eg setting a child to position to 0,0,0 aligns its origin position with its parent, the same is alignments are possible for rotation and scale. It’s as easy as it sounds, its common among these tools, so its known by the people it’s transparent on what are the influences and the way its designed is aligned to the math behind it.
Now what does blender do?
First, it seems to have the ideology that its somehow benefitial to present everything in worldcoordinates.
When we create a parent child relationship, then Blender takes not just the parents matrix and the childs matrix and multiplies that. It puts a third one in between. The parent inverse matrix. That one is the inverse of all combination of all the transforms the parent would have used. Lets say we have tree levels a cube0 existing at the rootlevel of the scene. Then a cube1 that is a child of cube0 and a cube2 that is a child of cube1. So we have something like a grandfather, father and child. The parentinverse matrix of cube2 is then set to be the inverse of the multiplication of cube0 and cube1 matrices.
If this matrix called parentinverse is not “cleared” it makes all their transform changes undone. So the coordinates of the child (cube2) are now also treated as if they were world coords. So blender does not have to transform any values of that child transform. It’s finished here
One might think thats a good idea to have just world coords. But there are many bad consequences embedded in this solution and that is also the reason why so many people are confused about it.
- It’s invisible. I don’t know what state it has. How shall I work with that? Sometimes it has an influence sometimes not. There is no indicator if an object has been transformed to act in worldcoords. So I cant trust the values presented in the child object transform any longer. It could be anything.
- It’s different to a defacto standard out there. So why is it different?
We are all able to think in terms of parent and child coordinates. And those who are not need some minutes to get it explained but then it’s transparent to the user. - And there is no consistent usage of the parent inverse in blender itself. The eyedropper of the parent in relations is different to the effect in the outliner on the parentinverse.
- Blender isn’t used on its own. Many people use alot of accompanying tools to get their work done. Other modeling tools, sculpting tools, texturing tools, unwrappers and more. Many of these support hierarchies and blender should align with that.
- It’s uncommon and intransparent handled and so leads to confusion among the users.
- And why does a “change” from Relations->ParentType : Object to Object have an effect on the position?
When I use the context menu I don’t even get the three options and the dialog popping up the keep transforms seems to have no effect and does not include the three options in total.
What I find most frustrating with this, that if want to change that to local coordinates then (keep transform) is no longer a supported idea.
There are three optioninal ways for parenting ( Object, Object (Keep Transform) and Object(Without Inverse) ) And in the clear parent group theres a way to clear the parent inverse. But none of the combinations for adding a parentship allows us to get the values of the child set to local space (what is done by clearing the inverse_parent) AND update the childs transform in the form that the position that the child has in space stays intact. So if we decide to clear that parent inverse we are facing a solution that destroys positional information of our sceneobjects. Fixes have to be done manually. And that with every object that gets added again.
Maybe these things haven’t been that important for you in the past. But the new outliner, collections, drag and drop hierarchy creations etc and a big ecosystem of 3dtools that you are part of and I know no other tool that does handle coordintes this way, should make you reconsider this. Please simply let that worldcoord thing fade inside blenders hierarchy concept. Make it optional in the preferences. Embed a view mode to change the presentation between local and global. But don’t leave it like that.
Could one of the devs please confirm that this is seen by you too and will be addressed in the near future? Please don’t ignore us with this.
3 Likes
Does this thread have anything to do with this?
https://developer.blender.org/T68190
I must admit I haven’t given further feedback in my bug report because I think I’m failing to understand the entire situation, but I’m glad more users feel that something is “wrong” here…
Hi @eobet,
Yes it relates. Part of what you are experiencing there is, that there’s a hidden matrix in between. Do a “Clear Parent Inverse” on that child with the 0,0,0 ( Shift+P if you use the Industry Compatible Keymap) and you will be able to understand the math again, but then you have to move it back to where it belongs as the values are now simply treated as local space. Before that step the 0,0,0 is treated as worldspace, as if it would be no child of another object.
And Blender does a real bad job during these conversions. Wouldn’t it be nice if the coordinates get changed to something that ist not 0,0,0 and the object itself could stay in place? It puts no work into keeping your positions here intact.
So we’re floating between the realms of technical implementation and Ux here… while it might make sense from a developer perspective to implement it like this, it is confusing for the user who parents an object and then don’t see the transform that they expect?
From my perspective as a user, I’d rather not have to do a second operation in order to get the result I expected from the first (which seems to be in line with what you say in the second paragraph)…
1 Like
That does not make sense from a developers perspective. It’s extra code to maintain, its slower to calculate. It once perhaps had the initial idea to make coordinates easier to read for novice users. But they did not just change it, they hide the changing values. And now look to what that leads. Nobody gets it. The world we live in nowadays consists of users who think in local coordinates if they look at childobjects and can’t align themselves with that idea at all.
They don’t want you to do that second operation. They want you to treat all 3dtransforms as worldspace.
But yeah you’re right. In the context of the world we live in this UX is so wrong.
Wait, have I misunderstood things so gravely that the core issue is simply that Blender lacks a toggle button between relative and world coordinates?
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. 
3 Likes
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
4 Likes
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.)
3 Likes
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:
- 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.
- 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)
-
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. -
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.
-
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
-
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.
-
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