Description
What problem does this solve or what need does it fill?
glTF uses:
- forward: Z
- up: Y
- right: -X
and Bevy uses: - forward: -Z
- up: Y
- right: X
For most of Bevy's history, this fact was simply ignored, resulting in all models being flipped when working in a pipeline spanning multiple programs.
Here's some stuff that has failed for me personally in the past:
- Creating a level in TrenchBroom. All objects placed in the scene are flipped in Bevy
- Creating animations in Blender so that what I see in Blender is exactly what I see in Bevy. Again, the animation is flipped. In the case of 1st person animations, the result is that they're invisible, which is very frustrating to debug
- Downloading glTFs from the internet. Most software exports to glTF using the correct orientation, so when you import glTFs in Bevy and use
Transform::default().looking_at(some_point, Vec3::Y), it will not actually look atsome_point, but the exact opposite direction
To be extremely clear here: I do not want Bevy's coordinate system to change. I simply expect that a model that looks in a certain direction in glTF still looks that way when imported in Bevy. This is important for artist pipelines. Quote from another issue (#5670 (comment)):
The biggest pain points in game production for coordinate spaces in my experience (and anybody I've talked with in the industry) come from rigged assets, i.e. Root Motion, runtime bone attachment. I understand that there are whole swaths of games that won't have to deal with these problems, but transforms are typically easier to solve for in those cases. And since there's a pretty solid standard for rig coordinate spaces across film and games I'd like to see that standard get more direct support in Bevy.
What solution would you like?
#19633 and followups allow users to opt into correct coordinate conversion. While this is great, I believe it is important to have an asset pipeline that "speaks the same language" as other software by default. As such, I suggest switching the default to enabled coordinate conversion at some point. The timing here is sensitive:
- The later this is done, the more time people have to port their scenes.
- But also, the later this is done, the more scenes are broken by default.
In particular, I believe it is important to change defaults before the Bevy editor is able to place objects. I'd like the Bevy editor to work correctly by day one, and not come with the baggage of "Oh, our default for this new editor is actually legacy. Your scenes will need to be changed later, sorry". Especially since I expect more and more users to be incentivized to create 3D levels once we have an editor.
But at the same time, we have to be careful. This affects nearly every 3D user!
What alternative(s) have you considered?
Leave it to be opt-in forever
Additional context
This issue is not about a specific migration strategy I favor, but about finding out together which way we should take. I'll post some ideas in the first comment, but please take them as just a starting point :)
For reference, this is how opting in or out works after #19685:
Globally:
App::new()
.add_plugins(DefaultPlugins.set(GltfPlugin {
convert_coordinates: true,
..default()
}))
.run();per asset:
let handle = asset_server.load_with_settings(
"fox.gltf#Scene0",
|settings: &mut GltfLoaderSettings| {
settings.convert_coordinates = Some(true);
},
);