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