Two ways of creating the same scene result in different values for the objects transforms. #55103

New Issue

k · 2018-05-16T20:06:30+02:00

k commented

2018-05-16 20:06:30 +02:00

System Information
Void Linux, Nvidia Titan
Also tested on Windows.

Blender Version
2.79b

Short description of error
The following two ways of creating the (seemingly) same scene result in different values for the objects transforms.

Exact steps for others to reproduce the error
Init:

create 3 cubes (Object mode -> add -> mesh -> cube )
In my description I will call those cube a, cube b, and cube c.

steps towards what I consider the bugged result bugged.blend:

select cube b and change its transform y to 2
select cube c and change its transform y to 4
leave cube a at origin
parent cube c to cube b
parent cube b to cube a
to demonstrate the real weirdness, now set the transform z of cube b to 2

this results in these transform values for the respective cubes:
cube a:
x: 0
y: 0
z: 0
cube b:
x: 0
y: 2
z: 2
cube c:
x: 0
y: 4
z: 0

which is completely puzzling.
In which coordinate system is the transform of cube c supposed to be?
It's not in a global coordinate system, although one could expect it from y being 4.
But z is 0, while one can see by its actual position that in global coordinates it should be 2 (just like its parent b)
It is not in coordinates relative to its parent either, since then y should be 2, not 4.
This makes no sense at all, and I consider it buggy.

Even worse is that you can create the same scene in a different way with the result being exactly what I expect.
Just reorder the operations.

steps towards expected result expected.blend:

parent cube c to cube b
parent cube b to cube a
select cube b and change its transform y to 2 and its z to 2
select cube c and change its transform y to 2

this results in these transform values for the respective cubes:
cube a:
x: 0
y: 0
z: 0
cube b:
x: 0
y: 2
z: 2
cube c:
x: 0
y: 2
z: 0

Which is what I would expect.
The transforms are relative to their parent.

How could I know from an exported file ( for example I use gltf ), where the nodes are supposed to be positioned?
It's impossible as long as the first way results in nonsensical values for the transform (which get exported 1-to-1 into the gltf file)

The way I think it should be (and how it is in game engines and the like) is that every node should have global and local (meaning relative to its parent) transforms exposed.
It would be simple and require no magical numbers.

**System Information** Void Linux, Nvidia Titan Also tested on Windows. **Blender Version** 2.79b **Short description of error** The following two ways of creating the (seemingly) same scene result in different values for the objects transforms. **Exact steps for others to reproduce the error** Init: - create 3 cubes (Object mode -> add -> mesh -> cube ) In my description I will call those cube a, cube b, and cube c. steps towards what I consider the bugged result [bugged.blend](https://archive.blender.org/developer/F3376461/bugged.blend): - select cube b and change its transform y to 2 - select cube c and change its transform y to 4 - leave cube a at origin - parent cube c to cube b - parent cube b to cube a - to demonstrate the real weirdness, now set the transform z of cube b to 2 this results in these transform values for the respective cubes: cube a: x: 0 y: 0 z: 0 cube b: x: 0 y: 2 z: 2 cube c: x: 0 y: 4 z: 0 which is completely puzzling. In which coordinate system is the transform of cube c supposed to be? It's not in a global coordinate system, although one could expect it from y being 4. But z is 0, while one can see by its actual position that in global coordinates it should be 2 (just like its parent b) It is not in coordinates relative to its parent either, since then y should be 2, not 4. This makes no sense at all, and I consider it buggy. Even worse is that you can create the same scene in a different way with the result being exactly what I expect. Just reorder the operations. steps towards expected result [expected.blend](https://archive.blender.org/developer/F3376462/expected.blend): - parent cube c to cube b - parent cube b to cube a - select cube b and change its transform y to 2 and its z to 2 - select cube c and change its transform y to 2 this results in these transform values for the respective cubes: cube a: x: 0 y: 0 z: 0 cube b: x: 0 y: 2 z: 2 cube c: x: 0 y: 2 z: 0 Which is what I would expect. The transforms are relative to their parent. How could I know from an exported file ( for example I use gltf ), where the nodes are supposed to be positioned? It's impossible as long as the first way results in nonsensical values for the transform (which get exported 1-to-1 into the gltf file) The way I think it should be (and how it is in game engines and the like) is that every node should have global and local (meaning relative to its parent) transforms exposed. It would be simple and require no magical numbers.

k commented

2018-05-16 20:06:30 +02:00

Added subscriber: @KevinMichalev

k commented

2018-05-16 20:42:06 +02:00

Actually, after some testing, it seems like exporting to gltf does seem to export the transforms relative to their parent.
So everything is fine in that regard.
Still it seems to be confusing for the values in blender to be different just by reordering the actions a bit.

Actually, after some testing, it seems like exporting to gltf does seem to export the transforms relative to their parent. So everything is fine in that regard. Still it seems to be confusing for the values in blender to be different just by reordering the actions a bit.

Philipp Oeser commented

2018-05-17 13:01:57 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-05-17 13:01:57 +02:00

Changed status from 'Open' to: 'Archived'

Philipp Oeser closed this issue

2018-05-17 13:01:57 +02:00

Philipp Oeser self-assigned this 2018-05-17 13:01:57 +02:00

Philipp Oeser commented

2018-05-17 13:01:57 +02:00

This is because of whats called the Parent Inverse.
This might not be how this is done in many other applications (but it does its job)

There is some explanation to it in the manual .
Please also refer there to set parenting up without Parent Inverse (or how to clear it later)
This document also explains it nicely, and there is probably more information on the internet.

So as you say it's not in global coords, it's not in parent's coords either, it's

matrix_basis = object transform coordinates
matrix_parent_inverse = object correcting matrix
matrix_local = matrix_parent_inverse x matrix_basis
matrix_world = parent's matrix_world (or global origin) x matrix_local

Note that to my knowledge there is no builtin method to clear it without affecting a childs global transform, but you can do it with a script:
https://blender.stackexchange.com/questions/28896/how-to-clear-parent-inverse-without-actually-moving-the-object

Hope this clarifies it? Dont think this can be considered a bug though...

This is because of whats called the `Parent Inverse`. This might not be how this is done in many other applications (but it does its job) There is some explanation to it in [the manual ](https://docs.blender.org/manual/en/dev/editors/3dview/object/properties/relations/parents.html). Please also refer there to set parenting up **without** `Parent Inverse` (or how to clear it later) [This document ](https://wiki.blender.org/index.php/User:Pepribal/Ref/Appendices/ParentInverse) also explains it nicely, and there is probably more information on the internet. So as you say it's not in global coords, it's not in parent's coords either, it's - matrix_basis = object transform coordinates - matrix_parent_inverse = object correcting matrix - matrix_local = matrix_parent_inverse x matrix_basis - matrix_world = parent's matrix_world (or global origin) x matrix_local Note that to my knowledge there is no builtin method to clear it without affecting a childs global transform, but you can do it with a script: https://blender.stackexchange.com/questions/28896/how-to-clear-parent-inverse-without-actually-moving-the-object Hope this clarifies it? Dont think this can be considered a bug though...

Germano Cavalcante referenced this issue

2024-01-01 14:17:52 +01:00

Transforms don't show Parent Inverse information #116689

Germano Cavalcante referenced this issue

2024-01-01 17:15:30 +01:00

Transforms don't show Parent Inverse information #116689

Sign in to join this conversation.