cgmath
cgmath copied to clipboard
API is confusing
@cmr has expressed concerns on #rust-gamedev that the API is confusing, especially in regards to transformations. He suggested an API closer to that of GLM. Of course that would be rather difficult seeing as Rust's overloading isn't nearly as expressive as C++'s. I am curious however as to what you guys think regarding the current API. What could be changed and improved?
cc. @ozkriff @csherratt
The following constellation of types could be confusing for a newcomer just trying to rotate a matrix - i dunno:
/// A two-dimensional rotation matrix.
///
/// The matrix is guaranteed to be orthogonal, so some operations can be
/// implemented more efficiently than the implementations for `math::Matrix2`. To
/// enforce orthogonality at the type level the operations have been restricted
/// to a subset of those implemented on `Matrix2`.
pub struct Basis2<S> {
mat: Matrix2<S>
}
/// A three-dimensional rotation matrix.
///
/// The matrix is guaranteed to be orthogonal, so some operations, specifically
/// inversion, can be implemented more efficiently than the implementations for
/// `math::Matrix3`. To ensure orthogonality is maintained, the operations have
/// been restricted to a subeset of those implemented on `Matrix3`.
pub struct Basis3<S> {
mat: Matrix3<S>
}
/// A generic transformation consisting of a rotation,
/// displacement vector and scale amount.
pub struct Decomposed<S,V,R> {
pub scale: S,
pub rot: R,
pub disp: V,
}
/// A homogeneous transformation matrix.
pub struct AffineMatrix3<S> {
pub mat: Matrix4<S>,
}
/// A transformation in three dimensions consisting of a rotation,
/// displacement vector and scale amount.
pub struct Transform3D<S>( Decomposed<S,Vector3<S>,Quaternion<S>> );
I dunno why we have pub struct Transform3D<S>( Decomposed<S,Vector3<S>,Quaternion<S>> );
:/
pub type DecomposedQ3<S> = Decomposed<S,Vector3<S>,Quaternion<S>>;
ugh.
One point that @cmr makes is that glm just operates directly on matricies. Dunno if that would be easier. But it is nice to take advantage of types. I dunno.
Yes, I find that transofrmations api is confusing a little bit or it needs more examples. At least I have not grasp it about month ago and just implemended few simple helper functions https://github.com/ozkriff/marauder/blob/7c0474/visualizer/gl_helpers.rs#L29-L47 .
Transform3D
was meant to be used when I first got the Decomposed
stuff in, but then turned out to be left behind. Feel free to kill it.
I don't see why you'd want to stick with matrices as the only means for transformations. Current interfaces do not forbid implementing Transform
for Matrix4
(and abandoning AffineMatrix3
), if you need this to be easer to work with. I'd prefer to leave it as it is though (Matrix
as low-level, while Transform
as higher level concept).
Thanks for the info regarding Transform3D
!
On a related note, you might be interested in this discussion on putting vector/matrix math into the c++ standard https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/5uZE4G6qFdM
Not sure how useful it is right now but the discussion is ongoing.
I didn't read the whole topic, but I advocated for the same thing in Rust in the past, for exactly the same reasons as the OP.