Personally I think the current system makes a lot of sense, but I agree it's not very intuitive and until you have a good grasp of how it works, it's hard to understand.
Why there is global_transform, transform, ...
Instead of explaining the difference between transform and global_transform, which can be a little complicated to explain since transform and global_transform have a lot of data in them, let's instead go through the difference between two slightly easier properties: position and global_position.
For example, say you have a node called one at position (4, 0, 0) and another node who is a child of one called two. In the editor, you set two's position to (0, 2, 0) so that it's two units higher than one. In the editor, two will be just two units higher than one, at the same position on the X axis. If you print two.position, you'll get (0, 2, 0, which is two's local position ( the position relative to it's parent node). If you print two.global_position, you'll get (4, 2, 0) because this is two's position in world/global space (the position relative to the origin of the world).
The same applies to global_transform and transform. global_transform is the transform in world space, which is exactly where it is in the world, while transform is it's transform relative to it's parent.
Why there is ..., ..., global_transform.origin, global_transform.basis, transform.origin, transform.basis ?
transform.origin (and global_transform.origin) is the position of the node. transform.origin will get you the Spatial's local position(the position relative to it's parent node), while global_transform.origin will get you the Spatial's world/global position of the node (the position relative to origin).
transform.basis and global_transform.basis are slightly different. Basis is the rotation and scale of a node, stored into one (rather strange) data object. I've yet to find a good way to extract the scale from a Basis object, but the rotation is fairly straight forward if you convert to and from euler angles.
Similarly to transform.origin, transform.basis is the local rotation and scale of a node relative to it's parent. global_transform.basis is the world/global rotation and scale of a node, relative to the origin.
If a parent's node has a scale of (1, 2, 1) and a rotation of (40, 40, 40), and the child node has a scale of (1, 1, 2) and rotation of (0, 20, 0), then child.transform.basis will have a rotation of (0, 20, 0) and a scale of (1, 1, 2), while child.global_transform.basis will have a rotation of (40, 60, 40) and a scale of (1, 2, 2).
(Hopefully the explanations make sense. My head is hurting a bit, so it's harder to think/explain)
Could it be simplified this way ?
transform
transform_local
Maybe, but I think transform and global_transform makes more sense, in my opinion. That said, it would be more in line with other game engines, which would make transitioning between game engines smoother.
For example local forward axis is
transform_local.forward
transform_local.right
This would be great! I'd love if there was a transform.forward. It looks way more readable than transform.basis.z.normalized()
About 3D Api axis Godot is more complicated than some other 3D engines :/
It needs simplification.
Agreed, though I'm not sure how the best way to simplify would be. I certainly think adding things like transform.forward and transform.right would help a lot! I think adding transform.scale and transform.euler_rotation would also be big improvements in ease of use.
