Skip to content

Home

Jump to bottom
Yoan edited this page Nov 1, 2019 · 6 revisions

vek was born from a desire to gather most useful game math foundations into a single, unified package, which means it doesn't only provide low-dimensioned square matrices, vectors and quaternions; it also provides commonly useful goodies such as LERP operations, a rectangle type, Bézier curves, and others.

An overview of features follows.

  • General-purpose vectors: Vec2<T>, Vec3<T>, Vec4<T>. They have uses for representing points or directions in euclidian spaces.
  • "Data crunching" vectors: Vec8<T>, Vec16<T>, Vec32<T>, Vec64<T>, useful for performing basic operations on many elements in the best way allowed by CPU features.
  • RGB color vectors: Rgb<T>, Rgba<T>. They have extended functionality related to color.
  • Texture coordinate vectors: Uv<T>, Uvw<T>;
  • Spatial extent vectors: Extent2<T>, Extent3<T>, for representing width, height and depth.
  • Low-dimensioned square matrices: Mat2<T>, Mat3<T>, Mat4<T>.
  • Quaternions;
  • Cubic and quadratic Bézier curves, in 2D and 3D;
  • Basic geometric primitives (bounding rectangle and box, disk and sphere, etc)
  • Traits:
    • Clamp, for constraining scalars or vectors to an inclusive range;
    • Lerp, for linearly interpolating between two values;
    • MulAdd, fused-multiply-add;
    • Wrap, utilities for values that can be wrapped around arbitrary bounds;
    • ColorComponent, for values that have a meaning as a single color component value.
    • Some others;
  • Some other lightweight goodies, not mentioned here so as to avoid cluttering this list.

Key design goals

  • Provide high-performance and SIMD support;
    This goal may or may not be achieved yet; The architecture was designed from the start to make this less painful, but up until now the policy was rather "functionality first".
  • Support less common scalar types such as fixed-point numbers and bignums;
  • Aim to be as high-quality (if only API-wise) as the standard library (or "a" standard library, for that matter).
    Be inspired by GLM, Unity's API, and a bit of SDL2.
  • Gather reasonable boilerplate so that people don't have to write it themselves for the N-th time.
    For instance, LERP, rectangles, Rgba and Extent2 vectors.
  • Be #![no_std].

However, vek is NOT, nor will it ever be...

  • A general-purpose maths library or BLAS;
    The focus is on computer graphics applications and games.
    There are other crates such as nalgebra for deeper, general-purpose maths.
  • A physics library;
    vek does appear to provide trivial collision detection functions, but will refrain from going any further. There are just so many different ways to manage physics and none of them is objectively better than any other;
    Also, no matter how you look at it, physics is a quite complex topic on its own;
  • A GUI library;
    vek provides a Rect struct, but that doesn't mean it will have a ColoredRect or RectStyle struct in the future.
    Essentially, vek provides only the very basic stuff people rewrite all the time, so you don't have to write it;
    Everybody agrees on what an axis-aligned bounding rectangle primitive should provide - on the other hand, there is no universally accepted way to write GUIs, as the many libraries in the wild show.
  • An animation package;
    The Transition struct is convenient and trivial, yet quite useful on its own.
    I could picture a fully-fledged animation system (whether 2D or 3D) that makes use of it somewhere, but it's the same problem with GUIs and physics: the best way to go is too context-dependant, and vek won't attempt to dictate it.
  • A Digital Sound Processing (DSP) package;
    In the future I would like vek to offer optimized "mass-processing" functions but they must remain simple.
    In the meantime, you may still build your own.

About optimizations

vek was designed with the intent to provide high performance and SIMD support.
Right now, the focus is more on the API itself than optimization details, which means some operations might not be as fast as they ought to be.
However, best-effort optimizations and manual checking of generated assembly will be amongst the pre-requisites of going 1.0.

If optimization is a concern, it is still possible to use the x86intrin or llvmint crates separately and convert back and forth from vek's SIMD types to those of these crates.

In the same way, if you crave for a Mat3x4 type for the sake of sparing one row in memory, you may create your own type which would then be converted back and forth into one of vek's Mat4 types.

Clone this wiki locally