glam

glam provides the vector, matrix, quaternion, and affine-transform types that games and graphics code need — Vec2/Vec3/Vec4, Mat2/Mat3/Mat4, Quat, Affine2/Affine3, and camera/projection constructors — for f32 and f64, plus a full set of integer and boolean vector types (i8 through i64, u8 through u64, isize/usize, bool). On x86, x86_64, and wasm32/wasm64 it stores SIMD-friendly types like Vec3A, Vec4, Quat, and Mat4 using 128-bit SIMD registers for performance that consistently benchmarks ahead of comparable Rust math crates on the mathbench project.

The library deliberately avoids generics and public-facing traits for its core types — Vec3 is a concrete struct, not Vec3<T> — trading some flexibility for fast compile times, a simple mental model, and documentation that lives on the type itself rather than being fragmented across trait impls. Swizzle methods (.xyz(), .wzyx(), etc.) are the one place traits are used, specifically to keep that large surface out of the main struct’s docs.

What You Get

• f32 types: Vec2/Vec3/Vec3A/Vec4, Mat2/Mat3/Mat3A/Mat4, Quat, Affine2/Affine3/Affine3A, plus a camera module for view/projection construction
• f64 equivalents (DVec2..DVec4, DMat2..DMat4, DQuat, DAffine2/DAffine3, dcamera module) for double-precision needs
• Full integer (i8/u8 through i64/u64, isize/usize) and boolean vector families, each independently feature-gated to control compile time
• SIMD backing (SSE2 on x86/x86_64, NEON on aarch64, simd128 on wasm) for Vec3A, Vec4, Quat, Mat3A, Mat4, Affine2, Affine3A, with automatic scalar fallback
• no_std support and an ARCHITECTURE.md documenting the library’s design rationale in depth

Common Use Cases

• Game engine math: transforms, camera view/projection matrices, skeletal animation, physics integration
• Graphics and path-tracing/rendering code needing fast, cache-friendly vector/matrix math (the author’s own path-tracer work motivated the SIMD design)
• WASM-targeted game or graphics code that needs consistent math behavior across x86, ARM, and wasm32/wasm64
• Any Rust project needing compact, benchmarked-fast linear algebra without pulling in a generic, trait-heavy math crate

Under The Hood

Architecture: glam’s src/ is organized by scalar type (f32.rs/f32/, f64.rs/f64/, i8.rs/i8/, etc.), each containing the vector/matrix/quaternion types for that type family, plus architecture-specific backend modules (sse2.rs, neon.rs, wasm.rs, coresimd.rs) that implement the actual SIMD storage and operations behind a consistent per-type API. swizzles.rs and the per-type swizzles/ directories implement swizzle access (.xyz(), .wzyx()) via traits specifically so that documentation for the many swizzle permutations doesn’t clutter the core struct docs, per the project’s own ARCHITECTURE.md. Code generation (codegen.json, templates/, tools/) generates the repetitive per-type-per-backend boilerplate rather than hand-writing it, and align16.rs centralizes the 16-byte alignment handling SIMD types require.

Tech Stack: Pure Rust, edition 2021, MSRV 1.68.2, zero mandatory runtime dependencies. Feature flags (std, f64, per-integer-width flags, all-types, core-simd for nightly portable-SIMD) let consumers opt into exactly the type families and precision they need, keeping compile times down for projects that only need f32/bool. deny.toml and clippy.toml enforce dependency and lint policy; benches live under benches/ and are cross-referenced against the separate mathbench-rs project for competitive performance tracking.

Code Quality: The project carries a documented ARCHITECTURE.md explaining explicit design tradeoffs (no generics, no public traits, SIMD-first) which is unusually thorough for a library this size and gives strong signal about deliberate engineering rather than accidental structure. Tests live under tests/, CI runs are badge-linked with coverage tracked via Coveralls, and a CODE_OF_CONDUCT.md/CONTRIBUTING.md pair plus 111 contributors indicate active, process-mature maintenance. ATTRIBUTION.md documents upstream influences (notably DirectXMath) transparently.

API Design: The public API favors concrete, non-generic structs (Vec3, Mat4, Quat) matching Rust standard-library naming and API-guideline conventions, so IDE autocomplete and rustdoc surface every method directly on the type rather than scattered across trait implementations. This is a conscious tradeoff documented in ARCHITECTURE.md: no Vec4<T> generic parameter, which simplifies usage and speeds compilation at the cost of not being generic over scalar type. The one exception — swizzle methods — uses traits deliberately to avoid polluting the main type’s documentation, showing a consistent philosophy applied selectively rather than dogmatically.