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 ;)
The fix done with https://github.com/mosra/magnum/pull/122
(0e05c7289e) was not tested properly (see
previous commit) and thus this code path never worked. This properly
lerps the translation part and recombines it with the rotation instead
of interpolating just a part of it.
Also I'm no longer having any "dotResult" that's done only on the
vector part of the rotation, but instead using the full
rotation quaternion dot product. I have no idea why it was done this
way. This branch was also never properly tested -- it'll be with the
introduction of "shortest path" variants in the next commit.
It's a straight copy of the code for quaternions -- it could probably be
simplified a bit, but I don't have the necessary brain cells at the
moment. I tried the following but failed:
retun Complex::rotation(acos(cosAngle)*t)*normalizedA;
Calling map<void>() was trying to instantiate ArrayView<void> through
arrayCast<void>(), which is not possible (void has no size etc etc.).
Casting the returned pointer directly instead. Thanks to @AndySomogyi
for pointing this out.
Disabling everything that doesn't depend on Vulkan as it's not needed to
be built again -- that's basically everything right now. This needs to
be a separate build for the foreseeable future, because it requires a
newer CMake version for the Find module and it'll probably also require
newer C++ standard.
Thanks to @LB-- for providing me with an oneliner to compile a file with
cl.exe.