Dual Quaternions

[jim-ec]

I would like to implement support for dual quaternions in glam.

In fact, I've already implemented them in a personal project of mine, but I'd like to upstream it.
My current implementation is only available for floats, so there would still be work to refactor it into the Tera template format. But before investing much time into that, I'd like to check if the maintainers of glam would accept that feature, or if it's considered out of scope.

Dual quaternions are an extension to regular 4D quaternions, that in addition to rotation, can also encode translation, i.e. implement 3D isometries. They are the equivalent of motors from Geometric Algebra.

My main use-case of dual quaternions is for a camera transform hierarchy. Usually, to get the view matrix that is sent to the vertex shader, the camera matrix is inverted. That is pretty expensive, while inverting (or rather, conjugating) dual quaternions is pretty cheap (pretty much just a few sign flips). It is analogous to how it is faster to invert a rotation stored as a quaternion than to invert a full 3x3 matrix (which can encode more than just rotations, but if only does need rotation, one still pays for the generality of matrices in terms of performance).

Dual quats can be "chained" just like matrices and quats by multiplying them. Just like mat and quat products, the dual quat product does not commute.

The implementation of dual quats are pretty simple, actually, as their simple are 2-tuples of two quats:

#[derive(Debug, Clone, Copy)]
pub struct DualQuat {
    real: Quat,
    dual: Quat,
}

My implementation is largely based on the dual_quaternion crate, but based on glam's quat types and linalg functions.

Kenwright, B. (2012). A Beginners Guide to Dual-Quaternions

[bitshifter]

@jim-ec how does your implementation compare to the Embark one feature wise https://github.com/EmbarkStudios/macaw/blob/main/src/dual_quat.rs? See #691 (comment)

Potentially I'd look at adopting macaw's impl just because it was suggested privately a while back but I've not worked with Dual Quats myself so I'm not sure how it compares.

If I was to take this, I'd make it a separate crate from glam, so it can be updated independently.

[jim-ec]

@bitshifter The dual quat implementation that you have linked has a few more functions that my implementation lacks, like formatting and sqrt calculation. It also is implemented just for f32. It would be nice if one could use dual quats for f64s.

Other than that, dual quats work the same way in both implementations, but I my on-a-need basis implementation could definitely improve by looking at macaw's code. But again, that's why I'm asking if you would be interested in having an dual quat support at all. If so, I would invest more time in e.g. unit tests, which both implementations currently lack.

Regarding implementing dual quats in their separate crate, that's your choice. After all, it's your repos to maintain :) But my personal take on this is that, as soon as dual quats are implemented, they don't need much updating besides bug fixes. The feature set provided by dual quats is pretty much fixed, I don't expect regular updates with new features. From a game developer perspective, it would be nice if there is a "default" dual quat implementation shipped with glam.