This makes it possible to conveniently do things like
Containers::StridedArrayView1D<Float> array = …;
Vector4 vector{NoInit};
Utility::copy(array, vector); // or the other way around
which is especially useful together with the new JSON classes. In some
cases this means the function is no longer constexpr, but those weren't
constexpr because it was useful for anything, they were only because it
was possible. So this breakage shouldn't do any harm I think.
Certain Clang-based IDEs (CLion) "emulate" a compiler by inheriting all
its defines, which means one gets __clang__ defined but also __GNUC__
set to 11 or whatever, breaking all these assumptions.
It was originally done using the Deg() / Rad() constructors in order to
be compatible with GCC 4.6, but fortunately those days are long gone.
Co-authored-by: Squareys <squareys@googlemail.com>
The old one is deprecated, and will be removed in a future release.
Unfortunately, to avoid deprecation warnings, all use of NoInit in the
Math library temporarily have to be Magnum::NoInit This will be cleaned
up when the deprecated alias is removed.
Before neither of the lerp(), slerp() had the shortest path check, while
sclerp() had it. Now, to be consistent, none of them has it and there
are lerpShortestPath(), slerpShortestPath() and sclerpShortestPath()
functions that have the shortest path check.
This is different from other engines, where there's usually only the
shortest path interpolation by default and either an optional
"non-shortest-path" interpolation or no alternative at all. I like to
give the users a choice, so there's both versions and the
non-shortest-path version is the default, because -- at least in case of
lerp() -- this results in a quite significant perf difference (15%
faster), so why not have it. Preprocess your data instead ;)
If the values are renormalized after every step, it shouldn't happen
that the value is denormalized even after calling `normalized()`.
The test fails for DualQuaternion with large values, as expected. Will
be fixed in the next commit.
The expectation is that the values are considered normalized only if the
difference is small enough. This should have been tested since the
beginning, but instead this was waved away with a dumb test case testing
obviously denormalized value and obviously normalized value.
The test fails for DualQuaternion with large translation values (as
expected). Will be fixed in following commits.
Similarly as it is done in STL for C++14 literals, the user has to
explicitly put them to scope with `using` keyword to avoid accidental
collisions. If MAGNUM_BUILD_DEPRECATED is set, they are still brought to
the root namespace, but that will be removed in a future release.
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>
I don't know why, but marking the output of copy constructor of any
subclass or output of conversion operator of any class as constexpr
causes MSVC to complain about non-constant expression.
Probably just another bug.