When rotation is identical, the rotation of the first dual quaternion is
returned instead, together with the linearly interpolated translation of
both (lerp of the vectors of the dual part). The additional include is
needed for `Math::lerp(Vector<3, T>, Vector<3, T>, T)`.
Signed-off-by: Squareys <Squareys@googlemail.com>
Making use of sincos() for Dual numbers, constructing DualQuaternion
from dual vector and scalar parts and using
DualQuaternion::isNormalized(). Also updated the math equation to be
consistent with conventions elsewhere.
- Use explicit conversion to `T`
- Use `std::` for `acos, cos, sin` to avoid use of double only functions
- Do not mutate variables in math code to avoid confusion
Signed-off-by: Squareys <Squareys@googlemail.com>
Should help people understand the code and counteracts the unreadability
caused by the optimization commit at least a bit.
Signed-off-by: Squareys <Squareys@googlemail.com>
Optimized with simple code tricks, some very complex math (like `2*0.5=1`),
and principal of locality. Things the compiler would probably do for me
anyway. Was able to remove about 6 useless float multiplications.
Signed-off-by: Squareys <Squareys@googlemail.com>
Now works both ways. The base class works with virtually any combination
that is supported by the underlying types, so e.g. Dual<Matrix3<T>>
could be multiplied/divided with Vector3<T> (result is Vector3<T>), with
Matrix3<T> (result is Matrix3<T>) or with T (result is Matrix3<T>).
The macros, on the other hand, because they are there only to help with
implementation of *my* subclasses, restrict that to the two only cases I
need (i.e. multiplication with Dual<T> and Dual<T::Type> and nothing
else). Could be extended in the future if it needs to be.
Useful for squeezing out last bits of performance, e.g. in this case:
Vector3 a;
a[0] = something++;
a[1] = something++;
a[2] = something++;
In the code all elements are first zeroed out and then overwritten
later, thus it might be good to avoid the zero-initialization:
Vector3 a{Math::NoInit};
a[0] = something++;
a[1] = something++;
a[2] = something++;
This will of course be more useful in far larger data types and arrays
of these.
Previously only matrices allowed to be created either as an identity or
zero-initialized. Now all Math classes support that, including (dual)
complex numbers and quaternions.
Some classes are by default constructed zero-filled while other are set
to identity and the only way to to check this is to look into the
documentation. This changes the default constructor of all classes to
take an optional "tag" which acts as documentation about how the type is
constructed. Note that this result in no behavioral changes, just
ability to be more explicit when writing the code. Example:
// These two are equivalent
Quaternion q1;
Quaternion q2{Math::IdentityInit};
// These two are equivalent
Vector4 vec1;
Vector4 vec2{Math::ZeroInit};
Matrix4 a{Math::IdentityInit, 2}; // 2 on diagonal
Matrix4 b{Math::ZeroInit}; // all zero
This functionality was already present in some ugly form in Matrix,
Matrix3 and Matrix4 classes. It was long and ugly to write, so it is
now generalized into the new Math::IdentityInit and Math::ZeroInit tags,
the original Matrix::IdentityType, Matrix::Identity, Matrix::ZeroType
and Matrix::Zero are deprecated and will be removed in the future
release.
Math::Matrix<7, Int> m{Math::Matrix<7, Int>::Identity}; // before
Math::Matrix<7, Int> m{Math::IdentityInit}; // now
It is often annoying to write e.g. this, especially in generic code:
T dot = Math::Vector<size, T>::dot(a, b);
When this is more than enough and the compiler can infer the rest from
the context:
T dot = Math::dot(a, b);
There are more downsides and confusing cases (you can call
Math::Vector<3, T>::dot(), Math::Vector3<T>::dot() and Color3::dot() and
it is still the same function), so I made these as free functions in
Math namespace. You can now also abuse ADL for the calls, but I would
advise against that for better readability:
T d = dot(a, b); // dot?! what on earth is dot? and what is a?
The only downside found when porting is that you need to specify the
type somehow when having both parameters as initializer lists:
T d = dot({2.0f, -1.5f}, {1.0f, 2.5f}); // error
T d = dot(Complex{2.0f, -1.5f}, {1.0f, 2.5f}); // okay
But that's probably reasonable (and it's also highly corner case,
the functions were used this way only in tests).
The original static member functions are of course still present, but
marked as deprecated and will be removed at some point in future.
The only places where they aren't absolute are:
- when header is included from corresponding source file
- when including headers which are not part of final installation (e.g.
test-specific configuration, headers from Implementation/)
Everything what was in src/ is now in src/Corrade, everything from
src/Plugins is now in src/MagnumPlugins, everything from external/ is in
src/MagnumExternal. Added new CMakeLists.txt file and updated the other
ones for the moves, no other change was made. If MAGNUM_BUILD_DEPRECATED
is set, everything compiles and installs like previously except for the
plugins, which are now in MagnumPlugins and not in Magnum/Plugins.
Also fixed unary RectangularMatrix::operator-() and Vector::operator-()
documentation (was stating that the operation is done in-place, which is
impossible.
Comparing squared length to 1 is not sufficient to compare within range
[1 - epsilon, 1 + epsilon], as e.g. Quaternion with dot() = 1 + 1e-7
when converted to matrix has column vectors with dot() = 1 + 1e-6, which
is just above 1 + epsilon. Thus it's needed to compare sqrt(dot()) in
range [1 - epsilon, 1 + epsilon] or dot() in range [1 - 2*epsilon +
epsilon^2, 1 + 2*epsilon + epsilon^2]. Because epsilon^2 is way off
machine precision, it's omitted, thus dot() in all isNormalized()
implementations is now compared this way:
abs(dot() - 1) < 2*epsilon;
DualQuaternion and DualComplex has now only rotation() which returns
full rotation part, rotationAngle() and rotationAxis() on Quaternion and
Complex were renamed to angle() and axis().
It better visualizes the fact that neither (Dual)Complex nor
(Dual)Quaternion contains the matrix inside them, but performs (possibly
costly) conversion.
Vladimír Vondruš