Boost logo

Geometry :

Subject: Re: [geometry] translation and rotation proposal
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-06-03 10:47:18


2013/5/29 Barend Gehrels <barend_at_[hidden]>

> 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:
> 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

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

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

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

- 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
- 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.


Geometry list run by mateusz at