It's now possible to conveniently transform 2D vectors and points with
3x3 matrices and 3D vectors/points with 4x4 matrices. Previous most
low-level solution:
Matrix4 m;
Vector3 v;
Vector3 a = (m*Vector4(v, 1.0f)).xyz();
Vector4 b = (m*Vector4(v, 0.0f)).xyz();
Another, more generalized solution for points was with Point2D/Point3D,
adding a lot of confusion (what is that class and what does .vector()?):
Vector3 a = (m*Point3D(v)).vector();
And the worst solution was with generic 2D/3D code (WTF!):
auto a = (m*typename DimensionTraits::PointType(v)).vector();
Now it is just this, similar for both dimensions:
Vector3 a = m.transformPoint(v);
Vector3 b = m.transformVector(v);
Note that transformation three-component vectors with 3x3 matrices or
four-component vectors with 4x4 matrices is easy enough so it doesn't
need any special convenience functions whatsoever:
Vector3 c = m.rotation()*v;
Will allow for more convenient usage of e.g. ShapeGroup operators:
Physics::ObjectShape3D* shape;
shape->setShape(Physics::Sphere3D({}, 0.75f) ||
Physics::AxisAlignedBox3D({}, {3.0f, 1.5f, 2.0f}));
Removed workarounds for alias templates, variadic templates and
anonymous enums, but 1.8.2 has some bug with forward declarations
causing classes to appear in default namespace, breaking
cross-references.
It prevents unwanted implicit conversions from e.g. nullptr to Camera,
Vector2 to Physics::Point etc. By making all the constructors explicit
it is easier to routinely add the keyword to all new classes instead of
thinking about cases when to add and when not to.
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.
* In shader uniforms (projectionMatrix makes more sense than projection
alone)
* For underlying types for SceneGraph transformation. It is already
used in Drawable::clean() as transformationMatrix, so why not use it
also in AbstractFeature::clean(). Moreover, clean() could be in
future also done using something else, this helps to distinguish the
type just from parameter name.
* In Physics shapes - applyTransformationMatrix() (as it could be in
future also done using something else).
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.
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.