Hi,

2013/5/29 Barend Gehrels <barend@xs4all.nl>
On 29-5-2013 3:23, Andrew Hundt wrote:
I recommend taking a look at how eigen does things for ideas before any major design decisions, and consider the possibility of directly integrating with ublas as well once you start getting into real matrix operations.

The currently implemented matrix operations (transform strategies) are using ublas.

<snip>

Please also refer to Boost QVM: http://www.revergestudios.com/boost-qvm/

This is not (yet) a boost library, and already for long in the review queue, but it is worth to visit. I hope that it will become part of Boost and we could then use that library (instead of current Ublas usage).


Yes, I know this library. I thought about providing Concepts, i.e. Vector, Rotations representations, Translation, etc. One would be able to adapt vector and matrix classes he'd like to use for linear algebra - uBlas, QVM or other. Also, I thought about providing algorithms needed for creation of those, e.g. translation between points, rotation between two points/vectors, appending rotations and translations to create transformation, conversion between different representations, etc. And of course, implementing a function applying those transformations to all geometries.

For now I've implemented:
- Vector, RotationMatrix and RotationQuaternion concepts,
- translation() calculating Vector between two cartesian points,
- rotation() calculating Rotation representation between Vectors,
- transform_geometrically() applying transformations to Vectors and Points - temporary,
- convert() converting between rotations representations.

Implemented but probably not needed or should be changed:
- assign_zero() for Vectors,
- assign_identity() for Rotations (new function),
- clear() - experimentally, setting Vectors to 0 and Rotations to 1 - create empty
- reverse() - experimentally, negating Vectors and inverting Rotations - create the opposite

Missing:
- TransformationMatrix concept,
- function connecting transformations together e.g. append(transformation, next);
- use of geometry::transform()
- other coordinate systems

The future:
- algorithm calculating  transformation of a set of points, e.g. ICP.

Questionable:
- RotationMatrix and TransformationMatrix could be one concept - Matrix,
- then RotationQuaternion could be named Quaternion,
- dimension<RotationQuaternion> is 3 even if it has 4 components because it represents rotation in 3D,
- dimension<TransformationMatrix> would probably be 2 for 2d even if it were 3xe, for 3d even if it were 4x4,
- transform_geometrically() should probably be replaced by geometry::transform(),
- clear() and reverse() are experimental and should probably be changed by something else or removed,
- assign_identity() would be not needed if there is some kind of clear()/init(), and is probably not needed at all.

Regards,
Adam