When dealing with transforms that only contain position, orientation and possibly scale many operations can be performed more efficiently than using a general purpose matrix.

A while ago I experimented with transform types which contained position and orientation (as a quaternion) much like Unreal's FTransform, but I found these to not be particularly more efficient or to save much space in practice, so they are not enabled by default. They can be enabled using the transform-types feature.

Another option might be to have these kind of transforms backed by a matrix with simplified methods/operators similar to Transform4D described in Foundations of Game Engine Development Volume 1.

So while looking through the library, I noticed the library only has SIMD vector support for the x86/x86_64 architectures. While this is honestly great for 99% of users, having to rely on scalar math for architectures like ARM and wasm32, architectures where performance is typically more of an issue, is honestly dissapointing. I've recently been testing using SIMD, and found it difficult to use, until I found the official core_simd crate. I think that allowing using core_simd as a feature flag would be very useful, since the work of supporting multiple architectures is already being done by the core_simd team, and it would allow for SIMD vectors on many many more architectures, with little to no work needing to be done on your side.

Currently, constant types don't seem to be supported:

error[E0015]: calls in constants are limited to constant functions, tuple structs and tuple variants
  --> src/main.rs:
   |
17 | const INIT_POS: Vec3 = vec3(1.0, 1.0, 1.0);
   |                        ^^^^^^^^^^^^^^^^^^^

I can't construct the tuple manually either, since there is only crate-level visibility. Would it be possible to implement this?

I've found that when dealing with mesh data files and meshes in memory and similar, you sometimes really want a Vec3 type that's guaranteed to actually be 12 bytes (3*mem::size_of()) in size.

I could of course implement my own Vec3 and have it by the side, but I think this need might be common enough that it might be worth including (since glam's SIMD Vec3 is stuck at 16 bytes, for pretty good reasons).

One idea might want to be to export a RawVec3 type or something that's essentially equivalent to the current non-SIMD fallback, even if SIMD is enabled. What do you think?

Fixes #269.

This PR does the following:

• Exposes "mul_add" on all vector types.
• Updates documentation for the function
• Forces the scalar implementations to use f32::mul_add and f64::mul_add for the types where it's relevant.
• Updates the relevant test names as "mul_add" is no longer private.

CUDA prefers specific alignments for Vec2 and Vec4 types in order to use more efficient memory loads. This PR adds a "cuda" feature that enables those alignments using cfg_attr in order that glam can be used to generate efficient PTX code.

This is currently a draft as the changes are somehow affecting DAffine2 and causing some of those tests to fail, where as far as I can see that type shouldn't be affected, but it's hard for me to trace back through all the macro invocations to understand where it's getting affected.

It would be nice if there was a function for projecting from one vector onto another normalized vector. Here's an example code snip that I implemented inside the project:

trait Vec3Project {
    fn project(self, vector_to_project_onto: Self) -> Self;
}

impl Vec3Project for Vec3 {
    fn project(self, vector_to_project_onto: Self) -> Self {
       self.dot(vector_to_project_onto) * vector_to_project_onto     
    }
}

An example of where it would be useful can be found at this repo: https://github.com/ForesightMiningSoftwareCorporation/bevy_transform_gizmo

And here is the video of it in action:

https://user-images.githubusercontent.com/2632925/119217311-33ac8a00-ba8e-11eb-9dfb-db0b9c13cd84.mp4

NOTE: That repo itself doesn't implement that function. I cloned it and noticed a helpful place in the source code for it, tested it, and it seems to work good. The repo referenced this article in its implementation which I copied into that example function above: https://en.wikipedia.org/wiki/Vector_projection

Part of https://github.com/bitshifter/glam-rs/issues/25. A simpler version of https://github.com/bitshifter/glam-rs/pull/156.

This PR introduces the Affine3D type, implemented as 3x Vec4 (NOTE: only f32 version included).

Banchmark results on my Intel MacBook (best of a few runs):

| op | Mat4 sse2 | Affine3D sse2 | | Mat4 scalar | Affine3D scalar | | -------------------- | --------- | -------- | - | ------ | -------- | | inverse | 12 ns | 9 ns 🥇 | | 31 ns | 16 ns 🥇 | | Self * Self | 6.1 ns | 4.2 ns 🥇 | | 21 ns | 14 ns 🥇 | | transform point3 | 2.6 ns 🥇 | 3.8 ns | | 3.8 ns | 3.5 ns 🥇 | | transform vector3 | 2.5 ns 🥇 | 3.6 ns | | 3.3 ns | 2.9 ns 🥇 |

( 🥇 is the fastest in each pair of columns)

It would be nice to speed up the sse2 vector transforms more, as those are probably among the most common operations to do with a matrix. I've tried several different approaches, but I can't get further than this. Unless someone has a better idea, I think we should just recommend turning your Affine3D into a Mat4 on SSE2 targets when doing a lot of mat * vec transforms.

It is also possible that for some platforms (in particular spirv) a 4x Vec3 may actually be faster.

The motivation is that it's kind of a pain to pay the cost of only accessing fields through function calls when you're not actually using simd. This is coming up for Embark both in WASM and (now) GPU code. Opening this issue to see what your thoughts/concerns are about this.

There's a couple options for implementation... the simplest would be to just make things that can be a plain struct with public named fields, i.e.

pub struct Vec3 {
    pub x: f32,
    pub y: f32,
    pub z: f32,
}

Another option is to use the strategy that nalgebra uses which is to create specific "component bag" structs and then impl Deref for them for things which make sense. For example:

struct XYZ {
    x: f32,
    y: f32,
    z: f32,
}

struct RGB {
    r: f32,
    g: f32,
    b: f32,
}
impl Deref<XYZ> for Vec3 {
   //...
}
impl Deref<RGB> for Vec3 {
   //...
}

Now you can write both vec.x or vec.r and you get the same thing as vec.x() currently.

I'm thinking about replacing my own vector types with glam, but there is some missing functionality I need first:

• Not
• BitAnd
• BitOr
• BitXor
• Shl
• Shr
• ~~Rem~~

Would a PR to add these impls to UVec and IVec be welcome?

Having a function like this is super-useful to guard against non-finite values. For instance:

let v = foo.cross(bar) / det;
let v = v.normalize():
if v.is_finite() {
   Some(v)
} else {
   None
}

or debug_assert!(transform.is_finite());

Naming

There is already a is_nan which returns a mask. This sets a precedence that something called is_finite should also return a mask. However, is_entirely_finite doesn't feel like a great name to me. Maybe functions that return a mask should have a m suffix or something instead?

Anyway, I'll be happy to change the name of this, this is just a first draft!

I situation I frequently find myself in when working with vectors is I have a 2D rectangle or 3D volume and I need to know if a particular coordinate is "in bounds", IE, I have an axis-aligned bounding box and I need to know if a point is within it. It is straightforward to keep a minimum and maximum coordinate and >=/<= each component, but this is verbose and therefore error-prone. I like to have a single object encapsulating the bounds especially since this makes it easy to tack on convenience features such as "expand the bounds to include this point" and "offset the bounds".

There doesn't seem to be a good library for this with glam or in Rust in general. "Glamour" has Box2D/Box3D structs, but Glamour is somewhat heaviweight and expects you to use its own special specially-typed vector struct idiom, also it currently doesn't seem to be compatible with Glam 0.22 (requires 0.21). It would be great to have a Box/Bounds/AABB/multidimensional range struct that uses Glam types natively.

I previously contributed Bound2 and Bound3 classes to the CPML vector math library for Lua, and would be happy to create a PR or addon crate for Rust implementing a bounds object. It would be helpful though if while I work on the PR I could get feedback on how to fit glam's idioms best (For starters: should it be named Box2, Bound2 or something else? Would Box be preferred or specialized IBox2/DBox3 type classes? Would it be better to do this as a glam-rs PR or a new crate?).

This just matches what was done for BVec3A. There's a bunch of functions in scalar/vec4.rs that return BVec4 instead of BVec4A though, like cmpge. I tried wrangling the template files but wasn't sure how to fix that part, its a bit annoying because switching on scalar-math creates compile errors when these functions are being used. I currently only need scalar-math to run tests in miri because miri doesn't support SIMD.

What problem does this solve or what need does it fill?

Currently Vec3 provides extend(w) to unproject into homogeneous coordinates (hence Vec4 with euclidean hyperspace w - maybe I missed it, but there is no inverse to extend() or the documentation misses to mention it.

What solution would you like?

I would prefer to write something like this

transform.translation = view.w_axis.project()

rather than

transform.translation = view.w_axis.xyz() / view.w_axis.w;

My example is now for Vec4 ... same applies to homogeneous representations of Vec2 in vectorspace R3 using Vec3

What alternative(s) have you considered?

Keep writing rather obvious code

This was originally a request in bevy https://github.com/bevyengine/bevy/issues/6916#

The type of the boolean vectors used by scalar and SIMD implementations of the same vector type seems to be different.

Consider, for example, Vec3A. The SIMD implementation of the vector exposes this function signature:

pub fn select(mask: BVec3A, if_true: Self, if_false: Self) -> Self {
    // ...
}

whereas the scalar implementation of the vector exposes this different function signature:

pub fn select(mask: BVec3, if_true: Self, if_false: Self) -> Self {
    // ...
}

This seems to be a regression from 0.22.0, which:

Added u32 implementation of BVec3A and BVec4 when SIMD is not available. These are used instead of aliasing to the bool implementations.

Presumably, this problem wasn't noticed before because, on scalar platforms, BVec3 and BVec3A were interchangeable.

I’m using Quat::slerp to extrapolate rotations, and it works perfectly when the angle is greater than about π / 49.65, in which case the dot product is 0.9994995, suspiciously close to the dot threshold of 0.9995 where Quat::slerp falls back to Quat::lerp. However, when the angle is smaller than that, e.g. π / 60.00, then extrapolation no longer works properly, and the rotation goes slower as the s parameter to Quat::slerp goes further beyond 1.0.

Example code:

let start = Quat::from_axis_angle(Vec3::X, 0.0);
let end   = Quat::from_axis_angle(Vec3::X, PI / 49.65);
println!("{:?} {:?}",
    Quat::dot(start, end),
    Quat::slerp(start, end, 49.65 * 2.0).to_axis_angle());
// => 0.99949956 (Vec3(-0.023733087, -0.0, -0.0), 6.2778816)

let start = Quat::from_axis_angle(Vec3::X, 0.0);
let end   = Quat::from_axis_angle(Vec3::X, PI / 60.00);
println!("{:?} {:?}",
    Quat::dot(start, end),
    Quat::slerp(start, end, 60.00 * 2.0).to_axis_angle());
// => 0.99965733 (Vec3(1.0000001, 0.0, 0.0), 2.5490494)

Notice how in the first example, the resulting angle is 2π, i.e. properly extrapolated; whereas in the second example, the resulting angle is not even close to 2π.

I’m not quite sure why the special case for small angles exists; is it merely an optimization? Or is it there to avoid problems with precision? I saw in #57 that the implementation of Quat::slerp was based on that in cgmath. But cgmath falls back to nlerp, not lerp, which might behave differently.

It would be nice to have extrapolation work as expected, like it does for e.g. Vec3::lerp. Do you think that would be acceptable, perhaps as a separate method?

(Or maybe I shouldn’t use quaternions for animations.)