Add is_z_forward option to 3D viewport

[TokageItLab]

Relates to #75875 and #72842. This PR add is_z_forward option to 3D viewport same as those.

It provide DCC-like operation for a designer friendly viewport. Demand is already visualized in godotengine/godot-proposals#6198 (comment), #73742 and more.

But this is optional since some developers prefer to use a workflow like #72753.

Considerable matters:

• Maybe there is more suitable option name to emphasize that it only affects the front/back/left/right View of the Viewport
• The default is false for now, but I feel personally that default is true is more user-friendly since I am also a designer

---

This PR, #75875, #72842, and some additional documentation to be added later, we have to finish the arguments as to which is the way forward in Godot 4.x.

And let's strive to develop more consistent asset pipeline I/O so that like this arguments does not happen in Godot 5.

[Zireael07]

Re the naming: "View is +Z Forward"?

[TokageItLab]

View is +Z Forward

Thanks, adopt tentatively.

[Calinou]

I'd rename the option to make it sound more natural:

Suggested change

	view_menu->get_popup()->add_check_item(TTR("View is +Z Forward"), VIEW_IS_Z_FORWARD);
	view_menu->get_popup()->add_check_item(TTR("+Z Is Forward"), VIEW_IS_Z_FORWARD);

Also, is this metadata stored for the current scene? If so, I'd add a tooltip to mention that the override only affects the current scene, not other scenes in the project.

[venilark]

Just to understand how this works. Once this is merged, if I import a model from blender will this solve the problem of having to rotate it manually so it faces -Z, because now +Z will be considered forward for this scene only and this will not break look_at() (which now should use +Z), animations or anything else?

[TokageItLab]

It is always -Z for the forward of the Godot coordinate system. This option only affects the some operation (Look Front/Rear/Left/Right) of the View, not the scene.

For look_at() and PathFollow, we are going to add an option by #75875 and #72842, so you need to set that option to true if necessary.

For externally imported animations, assets and etc., the glTF format specification require that the forward always be +Z, but this will be documented later in the pipeline-documentation.

[venilark]

It is always -Z for the forward of the Godot coordinate system. This option only affects the some operation (Look Front/Rear/Left/Right) of the View, not the scene.

For look_at() and PathFollow, we are going to add an option by #75875 and #72842, so you need to set that option to true if necessary.

For externally imported animations, assets and etc., the glTF format specification require that the forward always be +Z, but this will be documented later in the pipeline-documentation.

#72753
wouldn't this one be the "perfect" solution if it's merged?
if the glTF gets automatically rotated and we see 0 degrees as if nothing ever happened that would solve this huge headache, only thing needed is documentation so a newcomer understands why -Z is forward and why it's a great idea to simply click on that checkbox when importing their models
having to rotate manually and then most likely having to add more code to fight that is the opposite of user friendly

[Zireael07]

wouldn't this one be the "perfect" solution if it's merged?

Not perfect solution according to some devs, who believe the specs should be perfectly adhered to. (This is why this only changes the view)

[venilark]

wouldn't this one be the "perfect" solution if it's merged?

Not perfect solution according to some devs, who believe the specs should be perfectly adhered to. (This is why this only changes the view)

then those devs would be ok with a car going backwards when I accelerate, because the imported model is facing +Z but forward is -Z...
by automatically rotating the mesh in Godot, you don't have to model differently in Blender and the model ends up facing Godot's forward
it's either this optional feature, breaking Blender conventions or manual rotation + hacky code

[Zireael07]

then those devs would be ok with a car going backwards when I accelerate

The dev in question seems to expect ALL models ALWAYS adhere to the spec... and doesn't really consider those that don't.

You don't have to model differently in Blender, just put an empty spatial above the model and use it to correct the facing.

(Some models I downloaded face +Z, some face -Z, hence the need for this trick)

[TokageItLab]

I will summarize this in the documentation at some point, but here goes:

---

In the OpenGL coordinate system, -Z is forward, and the camera is considered to be in the same space as the coordinate system, so it is oriented with -Z as its front. And that is generally the default view. If the front of the object to be taken is -Z, then the object will have its rear facing the camera.

Most designers create the object from the front when they start working in the default view. Then the object will be facing +Z, which means it will be facing the opposite direction from the coordinate system.

This is a designer's major "convention" (and that is also a restriction of the right-hand coordinate system). However, the problem with an object facing +Z is that the same look_at function as the camera cannot be used.

• Those who dislike the "convention" have tried to create the object with -Z as the front
• Conversely, a system that adapted to convention might have two look_at's (one for the camera and one for the object)

And, since that was the "convention", so the 3D model data did not define which was front.

However, glTF has defined as a "specification" what it used to be a "convention" that the front of the object be +Z and front of the camera be -Z, which is almost synonymous with facing the default camera.

This allows developers to work under the assumption that the glTF object is facing +Z.

---

Now let's talk about Godot.

Until now Godot has only had one look_at. In other words, it was not adopted to convention.

In this case, the +Z glTF data should have been converted as -Z Godot data. In other words, the "vertex", "animation data" and some data should have been transformed to rotate.

However, this was not implemented. This became a source of controversy. It still would be.

the +Z glTF data should have been converted as -Z Godot data

Yes, the fundamental solution is to do this, but it is too late to do this with Godot 4. Considering the compatibility and the amount of work involved, it is no longer possible to do this now.

(...But, this is like reproducing a left-handed coordinate system with the z-axis inverted, so if anyone want to support this, it would be correct way to propose that making Godot 5 be a left-handed coordinate system.)

---

Therefore, two approaches are proposed to handle them in Godot 4.

1. Rotate parent nodes

#72753 rotates the "parent Node" of the vertices and animation data, it doesn't convert the "vertices" and "animation data".

This is because Godot 4 importers and exporters process data under the assumption that glTF data is +Z forward, so it is impossible to make the MeshInstance or animation data itself -Z forward, considering the pipeline.

Why I say it looks like a hack in that is because it is a compromise solution that was created because it did not address the fundamental issues that should have been resolved. Also, it will always require more than two parent nodes to the imported meaningful object (such as Skeleton, MeshInstance, or it may be an invisible Node which has transform) and always require a 180 degree rotation to be left on one of the parent nodes.

Of course, it does not mean that it will never work. It certainly enables the look_at method to be shared by the camera and the object. It can be used for most cases quickly, if you don't consider exporting objects or creating animation data.

2. Have two look_at methods (implement the is_z_forward option)

#75875 and #72842 and this PR aims to make the View and Import/Export processes more designer friendly by adding an option to look_at to adapt to conventions. This ensures that designers creating models and animations just need to think only about following the glTF specification of +Z Forward at all times.

This is also a straightforward solution that some systems have, as explained above. However, it seems there are some people who dislike that there are two look_at's and the convention (camera and object having opposite forwards).

I personally believe that in the Godot 4 system it makes more sense to create the assets in Godot as +Z Forward (i.e. BACK facing in the coordinate system), in particular taking into account sharing animations and exporting objects processes. So I have created these PRs.

---

We all hope that a fundamental solution will be found in Godot 5, but what needs to be done now is to stabilize Godot 4, so we would like to have these workflows and make sure that users understand the pipeline with some documents.

[fracteed]

@TokageItLab thanks for adding this, it is a welcome addition. I also agree that it should be on as default. It actually was like this in the early 3.x days.

I put together a quick comparison test with Godot4 and 3 popular 3d packages to show that they all line up correctly with Godot (if it has new the new option turned on). This is just 2 cubes, with the smaller one in front (when seen from a top view). All of these packages have different co-ordinate systems, but they all have the same relative top/front/left/right viewport orientations. Cinema4d actually does have the same coordinate system as Godot.

These are screenshots from Blender, Cinema4d, Houdini:

This is what Godot looks like with the new option on, which is exactly what an artist would expect:

And what it currently looks like in Godot3 and 4:

[TokageItLab]

Superseded by #76052