Consider switching to a generic math library

[cart]

Bevy currently uses glam, which is blissfully simple, but also doesnt cover the breadth of types required (UVec2 / IVec2 / etc). Additionally, given that we are using a data driven approach for shaders, it makes sense that the math library can map to all (or at least most) shader types. Ideally all types can be zero-copy converted into their shader types.

Libs to consider:

nalgebra
euclid
pathfinder_geometry

[cart]

First some thoughts on Euclid:

• Euclid is pretty cool. I started porting some parts of bevy to it and it definitely works.
• For ergonomics I ended up aliasing f32 types like Vector3D<f32, WorldSpace> to Vec3.
• The path to/from types isn't always clear. Ex: if you want a Transform3D and you have a Point3D, you need to convert it to a Vector3D first. Not a huge deal and relatively rare, but it came up
• The types are verbose (but we already knew that and its also a plus). This only really comes up when debugging / serializing
• I like that they directly expose fields instead of putting them behind getters/setters, but this also comes at a cost: adding SIMD would be a breaking change
• Being able to use the types directly for components (because of unit specifiers) is pretty cool.
• Its missing a number of "nice to have" methods for transform construction: permutation of "from rotation/scale/translation" , rh/lh perspective matrices.

nalgebra is "slow" to compile in comparison to everything else (nalgebra: 17seconds , glam 0.6 seconds /euclid 1.9 seconds/cgmath 3.3 seconds) and the types are still not fun to deal with

In general I only do "linear algebra operations" on f32s
If 99% of the code would use f32 aliased world space euclid types that look identical to glam and glam has a more complete, performant, and future proof api, I think it makes sense to just use glam
and then for the 1% of cases where we need integer types (ex: glsl datatypes), we can just create a new Vec3 type with a really simple api
the only downside I see to this approach:

• We're back to wrapper types for transform components. Not the end of the world imo, this is a common pattern in rust
• Less features available to our custom Vec3 api (at least at the beginning)
  and it also means i dont need to port anything which is nice