
Geometry : 
Subject: Re: [geometry] translation and rotation proposal
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 20130617 12:10:50
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?
> 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.
> 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 classlevel 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).
Regards
Bruno
Geometry list run by mateusz at loskot.net