Models face backwards when upgrading from version 4.0 to 4.1 making some issues with path following 3d

[adriano-sudario]

Godot version

4.1

System information

Godot v4.1.1.stable - Windows 10.0.19045 - Vulkan (Compatibility) - NVIDIA GeForce GTX 960M (NVIDIA; 31.0.15.2225) - Intel(R) Core(TM) i5-6300HQ CPU @ 2.30GHz (4 Threads)

Issue description

When upgrading from version 4.0 to 4.1 models start facing backwards which causes some strange behaviors, specially if you're using path following 3d.
Reading version 4.1 release note, there's a section which probably describes a workaround related to this issue.
I understand it can be fixed with the 'Use Model Front' checkbox on PathFollow3D node, but it can still be a problem with larger projects, and also with the editor - which will still be showing the model facing backwards.
Also, it's a workaround for an specific issue that wasn't showing up before the upgrade, it shouldn't be forced to apply.

Steps to reproduce

• Clone the reproduction project from github
• Open it with godot's 4.0 release
• Play it without any issue
• Close the project, and open it again with godot's 4.1+ release
• A popup will show up asking to change the project to godot's 4.1 version
• Click 'OK' to open and modify the project
• First thing you'll notice it's that the model will now be facing backwards and if you play it, the path following will also be running backwards
• Also, if you check git's diff after hitting the play button, you'll notice some changes on Transform3D in the main scene (which uses the path follow)

Minimal reproduction project

https://github.com/adriano-sudario/Godot3DPathIssue

[YuriSizov]

Also, it's a workaround for an specific issue that wasn't showing up before the upgrade, it shouldn't be forced to apply.

Unfortunately, this was a required breaking change, so you do have to make the changes in your project if you plan to upgrade to 4.1+.

Though the model should appear correctly in the editor, if you follow standard conventions when modeling it. It may appear incorrectly if previously you had to adapt to Godot's own convention. But that is a part of the breaking change.

[scarletquasar]

Also, it's a workaround for an specific issue that wasn't showing up before the upgrade, it shouldn't be forced to apply.

Unfortunately, this was a required breaking change, so you do have to make the changes in your project if you plan to upgrade to 4.1+.

Though the model should appear correctly in the editor, if you follow standard conventions when modeling it. It may appear incorrectly if previously you had to adapt to Godot's own convention. But that is a part of the breaking change.

A minor version with a breaking change? Seriously? This is far from semver standard and broke all the professional reliability that Godot had.

[akien-mga]

Godot doesn't follow semver (it's inspired by it, but doesn't claim to be strict semver). No game engine does nor can, it's an unreasonable expectation for something with such a wide API surface.

You can see the version number as "generation.major.minor". A 4.x release may have minor compat breakage, but nothing that prevents from porting projects over.

[adriano-sudario]

Thanks for the response!

Though the model should appear correctly in the editor, if you follow standard conventions when modeling it. It may appear incorrectly if previously you had to adapt to Godot's own convention. But that is a part of the breaking change.

I just took the model from here and imported the way it is, without changing anything. I can't model myself, but tested with other models too and it gets the same behavior. Do you know where can I find a proper model to reproduce the same steps to test it?

[scarletquasar]

Godot doesn't follow semver (it's inspired by it, but doesn't claim to be strict semver). No game engine does nor can, it's an unreasonable expectation for something with such a wide API surface.

You can see the version number as "generation.major.minor". A 4.x release may have minor compat breakage, but nothing that prevents from porting projects over.

I disagree

[adriano-sudario]

ok, maybe i'm missing something out here, but to me it still looks like an unexpected behavior..

i just copied the gobot model scene and placed it out of path3d inheritance.
here's how it looks on version 4.0:

then i upgraded to 4.1, and here's how it looks:

if there's something wrong with the model, why is it only forcing the PathFollow3d child model to face backwards?

[capnm]

if there's something wrong with the model, why is it only forcing the PathFollow3d child model to face backwards?

As you said yourself, it works as expected when you enable the use_model_front, I don`t know or remember why this was not set as default. Probably for some other (camera as root node) compatibility reason.

If [param use_model_front] is [code]true[/code], the +Z axis (asset front)
is treated as forward (implies +X is left)
and points toward the [param target] position.
By default, the -Z axis (camera forward) is treated as forward (implies +X is right).

The model was created in Blender and shows you the model's front face:

Don't trust anyone and check the gobot.glb file here or here to see if the model author got it right (every glTF viewer I know follows the specs)

[aaronfranke]

The PathFollow3D compat breakage was intentional, done in this PR: #72842

The Basis.looking_at function's parameter for use_model_front is false by default, which matches the behavior in 4.0. However, you may find that you need to enable it in order to make it match with the PathFollow3D changes.

The screenshots posted by both @adriano-sudario and @capnm show the correct behavior. This model follows the correct specification that +Z is model front (-Y in Blender) (as opposed to -Z camera forward).

Breaking compatibility in PathFollow3D in 4.1 was unfortunate, but this is expected and there is no bug here. Closing.