Now it is nearly similar to MatrixTransformation*D except for scaling.
Public functions setTransformation() and transform() assert that the
matrix represents rigid transformation.
Overall architecture is simplififed with this change and also it's not
needed to use reinterpret_cast in matrix internals anymore, thus there
is no need for operator() and [][] works now always as expected without
any risk of GCC misoptimizations.
On the other side, constructing matrix from list of elements is not
possible anymore. You have to specify the elements as list of
column vectors, which might be less convenient to write, but it helps to
distinguish what is column and what is row:
Matrix<2, int> a(1, 2, // before
3, 4);
Matrix<2, int> a(Vector<2, int>(1, 2), // now
Vector<2, int>(3, 4));
For some matrix specializations (i.e. Matrix3 and Matrix4) it is
possible to use list-initialization instead of explicit type
specification:
Matrix<3, int>({1, 2, 3},
{4, 5, 6},
{7, 8, 9});
I didn't yet figure out how to properly implement the general
(constexpr) constructor to also take lists, so it's a bit ugly for now.
Matrix operations are now done column-wise, which should help with
future SIMD implementations, documentation is also updated accordingly.
I also removed forgotten remains of matrix/matrix operator*=(), which
can be confusing, as the multiplication is not commutative. Why it is
not present is explained in d9c900f076.
Removing of another <*stream> #include leads to more compilation time
saving, now from ~5:12 to ~4:55. Another compilation time improvements
will now be possible only by using Clang's modules, I don't know where
to optimize further (except for getting rid of <sstream> in tests).
Allows to animate objects, pause, repeat and resume the animations. The
user implements animation step and can perform actions on state changes.
Each Animable is part of some group which is optimized for case when no
animation is running, thus it is possible to create multiple independent
"animation islands" to improve performance.
Optimalizations in Corrade::TestSuite and Corrade::Utility::Debug leaded
to significant reduction of compilation time - on my machine it was
~5:38 before with building of unit tests enabled, now only ~5:00.
It was mainly in DimensionTraits usage. Also using DimensionTraits::*Type
for private members of physics shapes instead of manually specified
superclasses. The header is still included because of all the inline
accessors, so why not use the same type inside the class.
It was pain to type it with all the template parameters (`typename
AbstractCamera<dimensions, T>::AspectRatioPolicy`,
`Camera3D<>::AspectRatioPolicy::Extend`...) and it looked like it is
different for each camera template (which internally wasn't).
* Camera is now templated also on underlying floating-point type.
* Drawable objects can be split into groups (e.g. for separated
rendering of transparent objects)
* Added (long time missing) test for draw() function.
Functionality present in Object is now split into three main components:
* Object itself, handling parent/children relationships
* Transformation implementation and interfaces for common functionality
* Object features, providing transformation caching and base for
cameras, collision shapes, rigid bodies etc.
Some functionality depending on former implementation is temporarily
disabled and will be reworked later.
Magnum.h now doesn't include anything except OpenGL headers, thus
changes in Math library don't trigger recompilation of everything, but
only of things really depending on it.
Math constants moved to separate file for similar reasons, de-inlined
some functions to remove the need for some #includes.
Resulting (debug) executables are ~100 kB smaller, all operations
which were previously logarithmic are now done in constant time and
the whole implementation is a lot simpler.
Previously the scene was its own parent, which was good sometimes back
then, but it became so ugly and complicated hack ("my friend has access
to my privates"-style) that it needed to be replaced with something less
ugly.
Now there is an function isScene() which is overloaded in Scene. Yes,
it's possible to overload it anywhere else, but you better shouldn't
even think about it.
Vladimír Vondruš