Positions and normals have the same data, thus the data were simply
copied to positions and then moved to normals in return to save one
needless copying. However it seems that these two operations were
swapped by the compiler (C++ standard?) and thus there were no positions
to be copied.
Now explicitly creating copy of position array and then moving them in
return. While at it, renamed also `vertices` to `positions` to be
consistent with the rest of the engine. Also added simple (count only)
unit test to avoid this error in the future.
The access methods assert that the user is querying only available data.
Also updated Primitives implementation to create MeshData when
everything is done, not creating empty MeshData and then shooting the
data through interface intended for end users.
No shit. This is usable mainly if some common code expects the
mesh wrapped in MeshData and thus it is better to just have this tiny
class instead of doing it manually.
Having implicit conversion on Unit class causes much more harm than
doing the conversion some other way -- mainly for multiplication and
division, which is done with builtin operators and thus the result is
unitless. Also it is possible to do wrong "retyping" between degrees and
radians:
Rad a = Constants::pi();
Deg b(a*2);
On GCC >4.5 b is `180`, but on GCC 4.4 it is `2pi`, which is obviously
wrong and not wanted.
The conversion is done using Unit::toUnderlyingType() which is now used
everywhere instead of conversion operator. The conversion operator is
made available only for GCC 4.5, where it can be marked as explicit.
This might cause incompatibilites with `master` branch, where no
Unit::toUnderlyingType() exists, but users should have no need to
convert it to underlying type anyway as all required functions are
available through the library.
This reverts commit 36ac4de5c4 and
partially also 0db3a183ae (UnitTest.cpp).
* Calling enable_testing() only in root path.
* Using CORRADE_CXX_FLAGS instead of our own set to make things easier
to maintain.
* Various cleanup and reorganization.
Positions were originally done using Point2D/3D to simplify their
transformation using matrices and to some extent simplify their usage in
shaders. But now the disadvantages exceeded the advantages:
* They take 50% more for 2D positions and 33% more for 3D positions, as
last coordinate is always equal to 1, on the other hand when last
coordinate is errorneously not equal to 1 they have crazy behavior.
* Normalizing them or transforming them with anything else than with
matrices is PITA, as we need to strip the last component, do the
transformation, and then add the component back.
* All transformation handling classes (Complex, DualComplex,
Quaternion, DualQuaternion, Matrix3, Matrix4) now have convenience
functions for transforming points specified directly as
Vector2/Vector3 (and also for transforming vectors).
* When someone wants to use homogeneous coordinates with crazy last
component values, they can do so with plain Vector3 for 2D and
Vector4 for 3D and it will be less confusing than using Point2D/3D
which no important detail hidden.
Was causing improper implicit conversions, such as here (example
directly from unit tests, where it was unintentionally used):
Vector3 normal;
Matrix4 transformation;
auto transformedNormal = transformation*normal;
Not only that it was possible to multiply 4x4 matrix with 3-component
vector, but the resulting type was Point3D which was absolutely
confusing. Currently it must be explicitly converted:
transformedNormal = transformation*Point3D(normal);