Optional implementation of HasPosition2D for glam::Vec2 and glam::DVec2

[timothee-haudebourg]

I use the glam crate in a project where I need to compute a delaunay triangulation. It would be nice to have a HasPosition2D implementation for the glam 2D vector types. Could this be added as an optional feature?

[Stoeoef]

Sorry for the late reply.

I'm really torn about how to support external geometry libraries. I really, really dislike gluing code like triangulation.insert(Point2::new(glam_point.x, glam_point.y)). However, the point abstraction in Spade 1 (via the PointN trait) also had a few disadvantages:

• PointN did a lot of re-implementation of common geometry operations (e.g., the dot product). Those implementations needed to be maintained and may not always be the best implementation
• It might (theoretically) break whenever the third party library changes

My current least-unfavourable solution would probably to simply depend on a proper algebra library - likely nalgebra as that seems to become more and more a standard.
The second least-unfavourable solution would be to start a "algebra_traits" library (similar to num_traits) that defines common traits for Points and Vectors. This would look similar to the alga crate, but hopefully less complex. This crate could then implement nalgebra, glam and you-name-it support.

Unfortunately, none of this makes interaction with glam easier. I'm not sure how that could be achieved.
In any case, integration with other linear algebra libraries is on the roadmap for spade 3.

[caspark]

Mint is an interop standard which glam supports and nalgebra supports too. The Mint types themselves (e.g. Vector2) don't have any useful operations themselves - they solely exist to work around Rust's orphan rules.

Still, if HasPosition were implemented for them (under a cargo feature of course), then I think that would address this minor ergonomics papercut of having to convert into Point2.

(And FWIW, in case you are still considering depending on a proper algebra library directly: I prefer glam over nalgebra as the latter's generic programming makes compiler error messages a bit painful to understand sometimes. But with Bevy using Glam and Rapier & Parry obviously using nalgebra then I think there's reasonable arguments to be made either way - in the gamedev space at least.)