Why not use bevy::TransformSRT to implement bevy_transform::{GlobalTransform, Transform}?

[PixelDust22]

It looks like most if not all of the methods implemented in GlobalTransform and Transform was also implemented in glam::TransformSRT. Since we're using glam as our linear algebra library anyways, we may as well use glam::TransformSRT to implement the Transform and GlobalTransform components. This helps us to reduce redundant code.

pub struct GlobalTransform(pub TransformSRT)

The question is, do we want to directly expose the TransformSRT type to the user, or do we want to keep the current behavior as is? In the former case we can just change the definition of GlobalTransform and nuke almost all other methods. Any missing methods could be added to glam instead. Otherwise we would keep the interface as it is right now and implement the internal functions with TransformSRT.

[cart]

We actually intentionally chose to not use TransformSRT for ergonomics reasons. If we use the newtype pattern, then people can no longer directly access the translation/rotation/scale fields nicely (ex: transform.0.translation vs transform.translation). Transforms are common enough that it was worth it to us to provide a "flat" structure at the cost of some duplicate code. This is also the reason why GlobalTransform and Transform have redundant code instead of sharing the same impl.

[PixelDust22]

Thanks for this information!