# Home

Yoan edited this page Dec 29, 2017 · 4 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 operaton 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.

## Disclaimer

This crate is in its beta days! The public API is quite close to being stable, but it hasn't been battle-tested enough.
Issues and bug reports are very welcome!

`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
You can’t perform that action at this time.
Press h to open a hovercard with more details.