Config option to forward direction as Z positive

[Anyeos]

Describe the project you are working on:
FPS 3D example

Describe the problem or limitation you are having in your project:
Forward direction is not natural when you code a value that decreases. If you need to advance in real life you expect to increase meters not decrease.

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I need some order to my workflow. It is some confusing and unnecessary lost of time having internally a forward direction of negative Z.
When i shoot a bullet the forward direction is obtained from global_transform.basis.z.normalized(). And the result is a normalized vector with points to positive Z as forward direction.
But the function look_at returns an inverted Z pointing to origin that it look at.
And I need to turn 180 the camera to look at positive values too.
If I can choose to have a positive Z value as forward I can improve productivity.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
Forward direction is better being Z positive as I already stated.
But the FPS Starter example is pointing backward if you consider the forward direction as Z negative. The camera is rotated 180 degree and the player just forward in positive values.
If I have an option to change the forward direction of my proyect It will be less confusing for situations like that.

If this enhancement will not be used often, can it be worked around with a few lines of script?:
Actually I must "hack" (turn 180 degree) to get the the same forward direction from look_at that from the rest of functions on the FPS game.
After look_at:
rotate_object_local(Vector3(0,1,0), PI)
Or I need to convert to negative value the returning of global_transform.basis.z.normalized()
But the problem does not end there, I need all the 3D objects rotated accordly. If not I must export all already rotated.
So, defining from the start what value of Z is forward will be better.

Is there a reason why this should be core and not an add-on in the asset library?:
Because it can be included on the proyect settings.

[Calinou]

I don't think this is a good idea for the reasons described in godotengine/godot#31066 and godotengine/godot#8946. Those issues are about selecting the vertical axis, but the problems raised by "coordinate system agility" remain identical.

My opinion is that there's no true standard when it comes to 3D coordinates, so there are no "good" or "bad" coordinate systems to speak of.

[aaronfranke]

Forward direction is not natural when you code a value that decreases.

Counter-argument: If you have a game where the camera is aligned with the XY plane (like a fighting game), it is most natural for an increasing Z to place items closer, in the foreground.

I am assuming you are coming at this from a Unity perspective, since it has +Z as forward. You are welcome to rotate your own objects by 180 degrees, but also note that Godot uses a right-handed coordinate system, which is mirrored/flipped compared to Unity's left-handed system - so if you just rotate by 180 degrees, you won't get the same coordinate system as Unity (now the X axis will point the opposite direction).

The standard rotation for Y-is-up right-handed coordinate systems is that +X is right and +Z is back. If you rotate by 180 degrees, then +X is left and +Z is forward. If what you want is equivalence with Unity's +X is right and +Z is forward, this can't be done with a rotation - you'd need to change the handedness of the coordinate system, which would be a hugely complex change and will never happen, especially because right-handed coordinate systems are the standard in math and physics and in pretty much all software that isn't Unity, Unreal, or DirectX.

Godot's Y-is-up right-handed coordinate system is shared by many programs including Minecraft, Maya, and GLTF. Using the same coordinate system as GLTF is an advantage by itself, IMO.

While this won't happen either, it would be more realistic to switch to a Z-is-up, +Y is forward system like in Blender/Source/CryEngine/Max, since that uses the same handedness (and just involves a rotation of 90 degrees).

I'm closing this, because this will never happen, and also because even if the Godot developers would be willing to make this change, this isn't a desirable change because Godot's current coordinate system is already a very good one (same handedness as in math/physics and most software, and same coordinate system as the GLTF standard).

[Thaina]

most natural for an increasing Z to place items closer, in the foreground.

Counter-Counter argument. This is so wrong in many level. In any situation if you look directly front. Your eye is always zero point. And anything would be farther away. Anything closer in the foreground would be "nearer" which is smaller number. Even in fighting game we think of it as

What are you describing is for 2D game that you try to pile up things from the scene so Z would be increase. But that was actually a table coordinate. And it became industry standard because industry was working with paper on the table

[Zireael07]

This issue is closed and moot anyway

[Thaina]

@Zireael07 This issue always become endpoint of every similar issue as I had been try to investigate. The contributor always close another issue while point to here