Geometry Boost List: Re: [geometry] translation and rotation proposal

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

Bruno Lalande wrote:
> Hi,
>
>     So for sure we need a few additional concepts, i.e. Vector, Matrix,
>     Quaternion.
>
>     So then quaternion_type<point> and matrix_type<point>? Would this
>     always return square matrix?
>
>
> I don't see why we should provide concepts for quaternions and rotation
> matrices right now. Tell me if I misunderstood but I thought the point
> of the conversation has basically been to say that rotations and
> translations are just yet another kind of transform strategies. So I
> thought the plan was to develop new strategy classed to be passed to
> transform(), implemented in terms of whatever mathematical tool you want
> to use. "quaternion_rotation", "euler_rotation", "matrix_rotation" would
> be the names of such strategies. Am I misunderstanding?
>

I thought about it differently. If we provide Vector, Matrix and 
Quaternion concepts we'd be able to write strategies using those 
concepts. Then if the user used some arbitrary linear algebra library 
he'd be able to just pass his representation of Vector or Matrix with
the strategy e.g.:

transform(geometry2d, make_translating_strategy(my_vector2d));
transform(geometry2d, make_rotating_strategy(my_matrix2x2));
transform(geometry2d, make_transforming_strategy(my_matrix3x3));

transform(geometry3d, make_translating_strategy(my_vector3d));
transform(geometry3d, make_rotating_strategy(my_quternion));
transform(geometry3d, make_rotating_strategy(my_matrix3x3));
transform(geometry3d, make_transforming_strategy(my_matrix4x4));

// and more

and this would just work. He wouldn't be forced to convert his 
Quaternion or Matrix to BG strategy as it is now.

Is that reasonable?

>        we could just put other concepts aside and implement some nice
>     transformation strategies for bg::transform().
>
>
> If by this you mean what I'm describing above then yes, that would be my
> approach.

I meant that we might not implement functions returning rotation or 
transformation from 2 points or a set of points, for now. You've told 
that for Vector concept you'd like to provide it (probably because there 
already is subtract_point). If we implemented other concepts we could 
provide similar functions, e.g. calculating rotation Matrix from two points.

As I've written before, later we could also provide a function 
approximating the transformation (or pose - translation and rotation) of 
a set of points into other set of points, e.g. by implementing Iterative 
Closest Point algorithm.

We could even support higher order Tensors to make possible other types 
of transformations and coordinate systems.

Those concepts opens a lot of new possibilities.

>     Btw, should the strategy always have input geometries as template
>     parameters? If not, calling bg::transform() could be simplified, e.g.:
>
>
> I did some work recently on the distance strategies to have them take
> the input geometries template parameters at function level (in their
> apply()) rather than class level. Not committed yet, I have to find the
> time for that. But I guess the same idea would apply for other
> strategies. Basically we need to free them from their class-level
> geometry template parameters in order to make then more flexible and
> easy to use.
>
>     bg::transform(poly1, poly2, bg::strategy::make___translation(v_or_p));
>
>
> Yep, that's exactly the goal of my change (for distance strategies - did
> nothing on transform strategies so far - the distance strategy change
> was already a huge work involving hours of work).
>

Great, this would simplify using strategies.

Regards,
Adam