Allow users to fix glTF coordinate system imports

[janhohenheim]

Objective

Fixes #5670 as an opt-in for now

glTF uses the following coordinate system:

• forward: Z
• up: Y
• right: -X

and Bevy uses:

• forward: -Z
• up: Y
• right: X

For the longest time, Bevy has simply ignored this distinction. That caused issues when working across programs, as most software respects the
glTF coordinate system when importing and exporting glTFs. Your scene might have looked correct in Blender, Maya, TrenchBroom, etc. but everything would be flipped when importing it into Bevy!

Solution

Add an option to the glTF loader to perform coordinate conversion. Note that this makes a distinction in the camera nodes, as glTF uses a different coordinate system for them.

Follow Ups

• Add global glTF loader settings, similar to the image loader, so that users can make third-party crates also load their glTFs with corrected coordinates
• Decide on a migration strategy to make this the future default
  • Create an issue
  • Get feedback from Patrick Walton and Cart (not pinging them here to not spam them)
  • Include this pic for reference of how Blender assumes -Y as forward:
    

Testing

I ran all glTF animation examples with the new setting enabled to validate that they look the same, just flipped.

Also got a nice test scene from Chris that includes a camera inside the glTF. Thanks @ChristopherBiscardi!

Blender (-Y forward):

Bevy (-Z forward, but the model looks the wrong way):

Bevy with convert_coordinates enabled (-Z forward):

Validation that the axes are correct with F3D's glTF viewer (+Z forward):

[github-actions]

You added a new feature but didn't update the readme. Please run cargo run -p build-templated-pages -- update features to update it, and commit the file change.

[janhohenheim]

Will fix the CI and expand the PR description in a few minutes :)

[mockersf]

• Will wait until porting the examples until this PR is merged

I would prefer them to be fixed in this PR. Introducing temporary changes in examples makes it harder to sort actual regressions

[janhohenheim]

Sure, can do :)
Edit: actually, this is not necessary. The flag is not enabled by default in this PR, so all examples look exactly the same.

[ChristopherBiscardi]

you can simply

We should remove the term "simply" entirely and make sure that phrasing is not used in the migration guide.

[janhohenheim]

@ChristopherBiscardi done.

Also, I fixed the CI and expanded the PR description. Right now I'm porting all examples, but that will take quite a while. This PR can be merged in the meantime without any issues, as the flag is not enabled by default yet

[ChristopherBiscardi]

Seems to do what it says on the tin re: rotation. I checked a few static assets from kenney and kaykit.

with camera:

    commands.spawn((
        Camera3d::default(),
        Transform::from_xyz(4., 5., 7.0)
            .looking_at(Vec3::new(0.0, 0.3, 0.0), Vec3::Y),
    ));

before:

after (with feature flag):

[github-actions]

It looks like your PR has been selected for a highlight in the next release blog post, but you didn't provide a release note.

Please review the instructions for writing release notes, then expand or revise the content in the release notes directory to showcase your changes.

[alice-i-cecile]

Now that this is opt-in and not breaking, I want a brief release note to gather feedback please.

[janhohenheim]

@alice-i-cecile done 👍
Will additionally expand the release notes when I'm adding global default glTF import settings in a followup PR