mr::Quat implementation #19

cone-forest · 2024-11-23T20:22:29Z

Benchmarks to be added

include/mr-math/quat.hpp

dantibel · 2024-11-25T15:20:51Z

include/mr-math/quat.hpp

+      }
+
+        friend constexpr Vec<T, 3> operator*(const Vec<T, 3> &lhs, const Quat &rhs) noexcept {
+          auto vq = rhs._vec * std::cos(rhs._angle._data / 2);


I'd use const VecT for clarity

As we introduce more and more metaprogramming magic, we might cause implicit casts from Proxy classes to Underlying types, which is costly. I'd use auto where possible.

fair enough

dantibel · 2024-11-25T15:40:03Z

Consider adding mr::Quat<T> mr::rotate(const mr::Vec<T, N>& axis, mr::Radians<T> angle) to match other transform functions. That likely imply adding product for ScaleMatr and Quat

Add explicit to Vec cast operator. Fix operator+-*.

All passing.

dantibel · 2024-11-25T17:37:55Z

include/mr-math/quat.hpp

@@ -55,8 +73,8 @@ namespace mr {

      friend constexpr Quat operator*(const Quat &lhs, const Quat &rhs) noexcept {
        return {
-          lhs[0] * rhs[0] - lhs & rhs,
-          lhs._angle * rhs + rhs._angle * lhs + lhs % rhs
+          mr::Radiansf(lhs.w() * rhs.w() - lhs.vec().dot(rhs.vec())),


We can return Radians from w() (and call it angle() then), so such casts won't be necessary. That is also better, since user will be sure they dealing with radians

Wouldn't you have to cast dot product to Radians or lhs.w() to T in this case?

Ideally, Radians would support arithmetic operations with primitive types. Since the conversion from Degrees is explicit (I hope) that wouldn't lead to an ambiguity

Actually, Radians support + or - with Radians and * or / with numbers (which makes sense). Then yep, we need to add the cast to the dot product

Initial mr::Quaternion implementation

84c9d86

cone-forest linked an issue Nov 23, 2024 that may be closed by this pull request

Add mr::Quat #12

Closed