DMat4 variant with mixed floats, inspired by Jolt Physics

[LPGhatguy]

I've been working on binding Jolt Physics for Rust in my project rolt/joltc-sys. Because glam and Jolt Physics have very similar types, glam has been an obvious choice for the math library of the high-level Rust wrapper.

Jolt has a type that's really interesting, though. Their DMat44 type stores the first three columns as f32 and only the last column as f64. For the purposes of a physics engine, it makes sense that you don't need the rotation or scale part of the matrix as 64 bits, only the translation. This type is the type used for all world object matrices when double precision simulation is enabled.

glam's equivalent DMat4 type is all f64, so these types don't quite line up.

This has got me thinking: that mixed size matrix type sounds like a pretty good idea! So, questions:

• Is this type something that glam should have?
• What kind of things do people use glam's DMat4 type for?
• What trade-offs are there to either strategy? Using f32 for as much as possible probably reduces memory usage and opens up some SIMD opportunities.

[bitshifter]

Very interesting. That does make a lot of sense, having increased precision for just the translation part.

I feel like at this stage that it might be a bit niche for glam, or not something I'd want to take on at least. One day I'd like to make glams code generator a bit more reusable so that it's easier to extend glam in separate crates for things that I don't quite fit in glam. That's possibly not that straight forward though.

I am not totally sure what people use D* types for, I think most likely large worlds, which I guess this would be useful for.

I think you could probably optimize a lot for this specific case, you'd want to deal in doubles any time translation is involved, but if you could probably start using AVX2 a bit more, glam currently doesn't assume AVX2 but I think we're at a point that very few x86_64 machines won't have AVX. Of course glam also supports NEON and I don't know what the double support looks like there.

[bitshifter]

In the context of glam it would make more sense to make an affine type like this, which is much simpler than a full mat4 as it's largely composed of other glam types

[LPGhatguy]

Yeah, I think the type is logically a half way point between an Affine3A and a DAffine3. I bet Jolt is not using the fourth component of each row for anything anyways. An Affine3A variant that just has the translation swapped out could fit fine:

pub struct JAffine3A {
    pub matrix3: Mat3A,
    pub translation: DVec4,
}

I really appreciate how readable glam's generated code is. That has helped a lot when we need to vendor code or make our own data types for our engine.

I think I'll make a type like this in our Jolt bindings and see how it goes! It could also be a useful type in our engine because our main object transform type is a DVec3 translation and a Quat rotation.