glTF coordinate conversion issues related to node conversion

[greeble-dev]

Bevy version and features

bf4f0e5

Background

The glTF coordinate conversion assumes that nodes within the scene are following glTF scene semantics (+Z forward) and should be converted to Bevy semantics (-Z forward).

To make things more fun, glTF cameras and lights have different semantics - the conversion has to apply a special case correction:

bevy/crates/bevy_gltf/src/loader/gltf_ext/scene.rs

Lines 48 to 52 in d07a20a

	if node.camera().is_some() || node.light().is_some() {
	transform.convert_camera_coordinates()
	} else {
	transform.convert_coordinates()
	}

Problems

1. Animated camera and light transforms are broken.
   • The special case is not applied to animation tracks, so animated cameras and lights face the wrong direction.
   • This is likely to affect some users.
2. Child nodes of cameras and lights are broken.
   • The special case is inherited by child nodes, so non-camera/light child nodes face the wrong direction.
     • (This is a bit speculative - I haven't tested it)
   • Is this a niche case? Maybe relevant for a first person game that wants to attach a mesh to the camera?
3. A node can't be both a mesh and a camera and/or light.
   • Meshes are converted differently from cameras/lights, and Bevy can't represent this.
   • Probably extremely niche to non-existent in practice - most DCCs and engines (inc. Godot and Unreal) can't represent this either.
4. Scene conversion depends on node+mesh conversion.
   • Some users may want the scene as a whole to be converted, but without touching node transforms and mesh assets.
   • Hard to tell how many users would want this. Unreal only supports node conversion.

Solutions

Some of these issues could be fixed by adding more logic:

• 1 and 2 are probably doable by adding more special cases and tracking parent transforms.
• 3 can be worked around, e.g. by splitting the node into separate entities. But it's probably such a niche case that the complexity isn't worth it - better to report an error.

There's also some alternatives:

1. PR Alternative glTF coordinate conversion #20394 technically fixes all these issues, but at the cost of removing node conversion entirely.
   • It's unclear how many users would consider this a problem.
2. The "forward flag" proposal (WIP: Fix glTF model forward direction #20135) may fix all or some of these issues.
   • But the details haven't been worked out.
3. The camera/light issues could be fixed by not putting the Bevy camera/light components on the node entity.
   • Instead the loader would create a child of the node entity with a corrective transform, and put the camera/light components on the child entity.
   • This dodges the issues since the corrective transforms are not in the node hierarchy and don't get animated.
   • But it would be surprising for new and existing users who expect the components to be on the node entity.

[janhohenheim]

IMO let's move this to 0.18 to be addressed by #20394
The current implementation is good enough for now even with the issues above, and they can all be reasonably solved by the PR I linked.

Or we merge that PR in 0.17, that's fine for me too :)

[janhohenheim]

Since the linked PR was pushed to 0.18, this issue should be as well