Amethyst: Consider exposing math types via `mint`

[kvark]

https://github.com/kvark/mint

Exposing cgmath types would introduce conflicts whenever cgmath updates faster than Amethyst. More importantly, it would alienate nalgebra and euclid users. The solution I see is to use a neutral standard for math interop, which is where mint comes handy. It's not a math library, so it's not competing with anything. It's not introducing any new types, so it's not even required to be a dependency.

[torkleyy]

Okay, I'm fine with the general idea of exposing math types like this. Do we want to accept Vector3 or Into<Vector3> types then? I experienced that beginners find it complicated to have such a type, but it makes the usage easier.

[kvark]

On one hand, Into<T> is always implemented for T.
On the other hand, we don't have a strong confirmation yet that Into/From will indeed be provided by the existing math libraries, so perhaps we shouldn't rush into conclusions here.
A safe bet would be to wait and see how the corresponding PRs (into math libs) are going to be accepted, if any.

[kvark]

I don't think Amethyst needs to be the first adopter for mint. I'll get genmesh, maybe plane-split and other stuff on it first, see how it goes. It depends on how math authors see it.

[kvark]

Ok, Three-rs is now the front adopter for mint, and it seems to work out fine.
In other news, nalgebra got on board 🎉
I think we reached the point where mint could be considered here for real :)

[Rhuagh]

We don't do an awful lot of math internally in amethyst at this point, but Transform, LocalTransform etc could benefit from using mint types.