Add is_z_forward option to looking_at() & look_at() and some constants for glTF space

[TokageItLab]

By convention in OpenGL, objects are often imported facing the camera. This convention has been brought to glTF, so Godot imports glTF assets with +Z as forward.

In environments where this convention exists, there should be two look_at()s, one for the camera and one for the asset.

However, since Godot considers all coordinate systems to be unified by the camera space, so the look_at() and the Vector3 orientation constants are correct for the camera, but not for the glTF asset.

This PR adds some options that assume an imported glTF with +Z as forward. Those should be methods that users have already implemented as the workarounds, it is just not supported by Godot in the core.

In fact, this option is only needed for those that use look_at() and have the forward axis hard-coded, so most methods and classes do not need it and core compatibility is fully preserved.

The only change is regarding PathFollow3D, as the default direction should be the opposite.

[QbieShay]

I don't think this is the right solution, like mentioned yesterday we need to discuss and come to a consensus before implementing this.

[TokageItLab]

It may not be right for you, but it is not unusual in terms of OpenGL conventions. Yes, there is no consensus yet, so it is still a 4.x milestone, just same as #72753 PR.

[lyuma]

To be clear, is_gltf would be set for FBX and blend files as well, since those are converted through gltf.

Does this affect OBJ and DAE? What cases is the is_gltf option intended to cover?

Also, the description mentions cameras, but cameras can be imported from gltf as well.

[TokageItLab]

Indeed, since the imported glTF camera will be a Godot camera, is_gltf may be not good. So is_z_forward seems to be common and better.

[aaronfranke]

I am in favor of the looking_at changes, but not these. Perhaps this should be a separate PR? I think if we had a PR just for the looking_at changes this would be easier to approve.

[TokageItLab]

I suppose this is necessary as a basis/reasoning for the is_z_forward option. The documentation also describes glTF forward (+Z).

The +Z concept remains when it comes to importing/exporting assets. For example, it feels strange to specify BACK if you want the model to face forward for retargeting/exporting glTF.

[aaronfranke]

I disagree, it's not tied to glTF. Here's a PR with just the look_at changes: #75875

You could have +Z forward when importing an FBX or Collada file for example. Or you could have -Z forward in glTF if you are controlling a glTF camera which has its forward pointing -Z.

[TokageItLab]

Or you could have -Z forward in glTF if you are controlling a glTF camera which has its forward pointing -Z.

Well, even if the enum GLTF_FORWARD is an exaggeration, it is a SPECIFICATION that all of the assets as a GLTF are +Z FORWARD. A GLTF with a -Z FORWARD is not a GLTF. It is what is called a FAKE GLTF. GLTF cameras are out of scope here. The term "asset" may include the camera, but let's assume here that it generally refers to the object that the camera is shooting at. In other words, it means that the camera takes a picture of the camera.

There may be a better enum (e.g. ASSET_FORWARD), but even if we can't find it, we must document somewhere that as long as Godot uses the GLTF importer for all formats and has a GLTF exporter, the asset must be +Z faced. Even if the word "FORWARD" is not used, it must be made clear that they are to be faced to +Z. (Root motion is also needed that document.)

If you want to argue that assets should be -Z FORWARD in Godot, then the Godot importer and exporter must correctly convert the +Z FORWARD GLTF as -Z FORWARD, but unfortunately this is not accomplished in Godot 4.x was.

[TokageItLab]

Separated the fix for PathFollow. It should be merged by 4.0.

And this PR will need to be merged after reaching consensus after 4.0.

[TokageItLab]

Superseded by #76060

Bugsquad edit: Which was superseded by #76082