
Geometry : 
Subject: Re: [geometry] translation and rotation proposal
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 20130613 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
> gameoriented 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
Geometry list run by mateusz at loskot.net