The perf cost is just too great for these to be enabled always. The only
place where the assertions are kept always is in the batch APIs -- there
it's assumed the function is called on large enough data to offset this
overhead, plus since it's often dealing with large blocks of data the
memory safety is more important than various FP drifts which were the
usual case why other assertions were firing.
The article this API was originally based on assumes a scenario which
just *isn't* matching usual practices here, giving wrong results. Too
bad I didn't spend more time questioning the proof there and just
blindly assumed it's correct because everyone said so.
Won't be typing all that reasoning again in the commit message, see the
changelog entry and the comment in the test for details.
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>
It gives the same result, nevertheless something is not right when it
comes to negatively scaled meshes. Postponing the rest of the
investigation to later.
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.
Turns out this seriously broke properites that should always hold, such
as that R*S = M for a R and S extracted out of M. Another way to fix
this would be flipping signs in the rotation() / rotationShear() / ...
queries as well, but that adds extra operations to both rotation() and
scaling() and at that point it's just better to do what was done the
whole decade before.
To ensure this doesn't happen again and doesn't cost me a whole day of
debugging in an end-user app (SceneGraph TRS transformations got broken
because those assume that rotation() and scaling() *do* combine back,
which is a reasonable thing to assume), the docs are extended to note
this and there's an explicit test for both negative scale and large
angle corner cases as well.
This reverts commit 9aa68715db.
This is a breaking change, but I think it is worth doing. Because now
Matrix4::scaling(vec).scaling() == vec
which was true also for translation and other.
Important: the rotation() accessor now allows non-uniform scaling but
expects orthogonality (previously it allowed non-orthogonal rotation
axes but disallowed non-uniform scaling).
Documentation of all these accessors is further improved now as well.
Vladimír Vondruš