Fetching latest commit…
Cannot retrieve the latest commit at this time.


Build Status Documentation Version License Downloads Gitter

A linear algebra and mathematics library for computer graphics.

The library provides:

  • vectors: Vector2, Vector3, Vector4
  • square matrices: Matrix2, Matrix3, Matrix4
  • a quaternion type: Quaternion
  • rotation matrices: Basis2, Basis3
  • angle units: Rad, Deg
  • points: Point2, Point3
  • perspective projections: Perspective, PerspectiveFov, Ortho
  • spatial transformations: AffineMatrix3, Transform3

Not all of the functionality has been implemented yet, and the existing code is not fully covered by the testsuite. If you encounter any mistakes or omissions please let me know by posting an issue, or even better: send me a pull request with a fix.


cgmath interprets its vectors as column matrices (also known as "column vectors"), meaning when transforming a vector with a matrix, the matrix goes on the left. This is reflected in the fact that cgmath implements the multiplication operator for Matrix * Vector, but not Vector * Matrix.



This library offers an optional feature called "swizzling" widely familiar to GPU programmers. To enable swizzle operators, pass the --features="swizzle" option to cargo. Enabling this feature will increase the size of the cgmath library by approximately 0.6MB. This isn't an issue if the library is linked in the "normal" way by adding cgmath as a dependency in Cargo.toml, which will link cgmath statically so all unused swizzle operators will be optimized away by the compiler in release mode.


If we have

let v = Vector3::new(1.0, 2.0, 3.0);

then v.xyxz() produces a

Vector4 { x: 1.0, y: 2.0, z: 1.0, w: 3.0 }

and v.zy() produces a

Vector2 { x: 3.0, y: 2.0 }


cgmath is not an n-dimensional library and is aimed at computer graphics applications rather than general linear algebra. It only offers the 2, 3, and 4 dimensional structures that are more than enough for most computer graphics applications. This design decision was made in order to simplify the implementation (Rust cannot parameterize over constants at compile time), and to make dimension-specific optimisations easier in the future.


Pull requests are most welcome, especially in the realm of performance enhancements and fixing any mistakes I may have made along the way. Unit tests and benchmarks are also required, so help on that front would be most appreciated.


Contact bjz on #rust and #rust-gamedev, or post an issue on Github.