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-13 08:23:12

Bruno Lalande wrote:
>
> I often think about it and basically always come to the same conclusion.
> Basically there are 2 categories of users around this and we need to
> satisfy them all:
> - some people care a lot about vector/point distinction, and don't want
> subtract_point to return a point, they don't want to be able to add 2
> points (makes no sense), etc... => we need to ensure that in the library
> - some people don't care at all (I'm among them, with a mostly
> game-oriented background) - they use the "point" and "vector" words
> interchangeably => we need to keep the library as permissive as it
> currently is for them
>
> So all in all, the library needs a way to define what is the vector type
> corresponding to a point type. Could be a vector_type<point_type>
> metafunction. Could also be called difference_type<point>, since in
> essence a vector is the difference between 2 points and
> "difference_type" sounds familiar to C++/STL users. People who don't
> care about the distinction want vector_type<point_type> to return
> point_type. People who care want it to return a different type (with
> possibly same underlying structure, but different from a type system
> standpoint). The metafunction would be called by arithmetic operations
> and things like that.
>
> Regarding the model, we would of course be adding a model::vector type.
> Now the problem is which default to give it for
> vector_type<model::point>, i.e. which type of users we'd like to support
> by default - as there has to be one I suppose.
>

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?

What do you think about providing some general concepts, like in the 
case of Geometries?

coordinate_type in the case of those 3 concepts would be the type of the 
element.

But what about dimension? If we didn't have those very specific concepts 
like RotationMatrix, which I think we shouldn't, the dimention probably 
should specify the number of elements. So quaternion should have 
dimension 4 and for Matrix we could add indexed_dimension<Mat, I> which 
would return e.g. rows for 0 and cols for 1. Are you ok with this?

As for coordinate system. For Matrix and Quaternion it would probably be 
cartesian. Vectors could be defined in other coordinate systems, like 
points. We could allow usert to define it in traits but for now not 
implement any algorithm for other CS than cartesian.

Then we could implement e.g.:

vect = return_difference<Vector>(p1, p2);
pt = return_difference<Point>(p1, p2);
difference(p1, p2, vect);
difference(p1, p2, pt);

This name unfortunately wouldn't work for rotations because then 
operation couldn't be inverted. So we could just put other concepts 
aside and implement some nice transformation strategies for bg::transform().

Btw, should the strategy always have input geometries as template 
parameters? If not, calling bg::transform() could be simplified, e.g.:

bg::transform(poly1, poly2, bg::strategy::make_translation(v_or_p));

Regards,
Adam