Closed Osspial closed 5 years ago
Ah ok, I guess it's changed since I last looked at it :)
Still been thinking about this! :)
BTW in addition to glm as a reference, there is https://github.com/microsoft/DirectXMath as well. (MIT licensed) SIMD implementations there go beyond SSE2 which is a nice perk.
@aclysma that code is unused, it's something I wanted to play with but never got around to it. Sort of forgot about it but given the licence I should just remove it.
Glam could support f64, it's just far down my priority list.
So we talked about this issue a little at the meeting today, and @AlexEne wanted us to try and form some conclusions here so that we don't get long running issues that ramble too far away from what the issue was first about.
There has been quite a bit of discussion about this here and also in the Rust Community Discord, and perhaps other places too. I'll attempt to summarize the major points.
The issue started by asking if there's some way we can make a single, easy to use math library for everyone to rally around as a standard.
Developing a complete math library is quite a bit of work. While it might be possible to some day unify the math world, the limiting factor is time.
nalgebra
and nalgebra-glm
.f32
and dimensions of 4 or less, and use of hand selected SIMD intrinsics in each particular method, checking micro-benchmarks, etc. This is the path of glam
and hektor
.gamedev-wg
will revive the effort on the "ecosystem guide" in the next few weeks and we will attempt to make clear that some math libs are focusing on hardware optimizations while others are staying as general as possible. People can decide for themselves how they want to go.The meetings are just a way to improve communication, they do not form binding decisions, decisions are reached in the github issues so that everyone has a chance to participate regardless of time zone.
Please feel free to continue to post in this issue, but please also attempt to keep it to new points, not just re-hashing the same points we've gone over.
If you'd like to have side discussions that aren't quite about how to unify (or not) the math ecosystem please open distinct issues for that.
I am closing this one with the idea that some sort of conclusion can be incorporated in the ecosystem page.
The big math libraries are
cgmath
andnalgebra
. Both of them have deal-breaking flaws for many, namely (imo):cgmath
has a weird, idiosyncratic design that simultaneously does too much and too little, and tries to shoehorn in genericism with complex traits that are difficult to internalize.nalgebra
stretches the type system so far that the documentation is nigh impossible to understand without extreme patience and a deep understanding of generics.As a result, several people have gone and made their own math libraries that try and solve those problems, which don't get adoption because the ecosystem hasn't grown up around them. I'd like this issue to house discussion on how exactly we can go about designing a library that addresses those issues, while developing enough consensus that we can potentially replace both of the current libraries.