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

Subject: Re: [geometry] translation and rotation proposal
From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2013-06-12 10:47:08

Hi,

Bruno, do you have an opinion about this?

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.

Does the approach make any sense?

Regards
Bruno

>
>
>
>
>>
>>>> For now I've implemented:
>>>> - Vector, RotationMatrix and RotationQuaternion concepts,
>>>> - translation() calculating Vector between two cartesian points,
>>>>
>>>
>>> What is the difference between this and "subtract_point" (which was in
>>> arithmetic)?
>>>
>>
>> It's almost the same. The main difference is that the result is a Vector
>> which can be used to calculate something using some linear algebra library
>> without the conversion of the Point to the Vector. Again, instead of this,
>> one could adapt his vector to Point concept. This is IMO not very elegant,
>> btw like subtracting one point from another.
>>
>
> OK, I see and agree.
>
>
>
>>  - rotation() calculating Rotation representation between Vectors,
>>>> - transform_geometrically() applying transformations to Vectors and
>>>> Points - temporary,
>>>> - convert() converting between rotations representations.
>>>>
>>>
>>> Can you specify the last three items? I just don't understand it.
>>> calculating rotation between vectors, do you mean that you have one
>>> origin, two vectors (probably unit vectors), and calculate the
>>> transformation matrix from these? Actually I don't understand the exact
>>> meaning of all these things you specify. Without looking at the source
>>> (I did not do that yet).
>>>
>>>
>> rotation() calculates the rotation representation from 2 vectors, could
>> also work for points. This rotation is along the shortest arc between
>> normalized vectors. For now it calculates 2x2 rotation matrix for 2D, 3x3
>> rotation matrix or quaternion for 3D.
>>
>> transform_geometrically() works basically like geometry::transform() with
>> some transformer. It applies the transformation to Points. Therefore this
>> function should be removed after the implementation of better interface -
>> probably some additional strategies.
>>
>> convert() converts between different rotation representations. For now it
>> only converts between 3D rotation matrix and quaternion. It should probably
>> convert also between rotations and transformation matrix. If there were
>> additional rotation Concepts, like AxisAngle it should convert from it too.
>>
>
> OK.
>
>
>
>
>>
>>>> Implemented but probably not needed or should be changed:
>>>> - assign_zero() for Vectors,
>>>> - assign_identity() for Rotations (new function),
>>>> - clear() - experimentally, setting Vectors to 0 and Rotations to 1 -
>>>> create empty
>>>> - reverse() - experimentally, negating Vectors and inverting Rotations
>>>> - create the opposite
>>>>
>>>> Missing:
>>>> - TransformationMatrix concept,
>>>> - function connecting transformations together e.g.
>>>> append(transformation, next);
>>>> - use of geometry::transform()
>>>> - other coordinate systems
>>>>
>>>> The future:
>>>> - algorithm calculating  transformation of a set of points, e.g. ICP.
>>>>
>>>
>>> Can you specify this more?
>>>
>>
>> E.g. in image processing or robotics there is sometimes necessary to
>> check how one set of points is placed in relation to the other one. What is
>> the transformation (position and orientation, or pose) of a set of points
>> in relation to some other, base set of points. ICP is an iterative
>> algorithm which calculates it. Both sets of points musn't be exactly the
>> same. The algorithm returns some approximation, closest best bet.
>>
>>  Questionable:
>>>> - RotationMatrix and TransformationMatrix could be one concept - Matrix,
>>>> - then RotationQuaternion could be named Quaternion,
>>>> - dimension<RotationQuaternion> is 3 even if it has 4 components
>>>> because it represents rotation in 3D,
>>>> - dimension<**TransformationMatrix> would probably be 2 for 2d even if
>>>> it were 3xe, for 3d even if it were 4x4,
>>>> - transform_geometrically() should probably be replaced by
>>>> geometry::transform(),
>>>> - clear() and reverse() are experimental and should probably be
>>>> changed by something else or removed,
>>>> - assign_identity() would be not needed if there is some kind of
>>>> clear()/init(), and is probably not needed at all.
>>>>
>>>>
>>> Great work! However, up to now is it good to consider them all as
>>> experimental? I really appreciate you're hard working on this, but
>>> within a week we have to cope with 20 new headerfiles, with
>>> implementations of things which were already there, though in a
>>> different (and maybe not perfect) form, without proper discussions
>>> before... We have to be able to keep the overview, no? And besides this
>>> there are the new things and new headerfiles for ball (which also
>>> already existed) too...
>>>
>>>
>> Sorry if I've messed up with extensions too much. I thought that this is
>> the purpose of extensions, which is the place for some experimental
>> features which can be dropped easily. I'll be more careful in the future.
>>
>
> OK, so this was indeed not clear enough. The "extensions" are meant to be
> in development and at a certain phase promoted to the central part of
> Boost.Geometry. Up to now they (mostly) have more or less their definitive
> interface, though it might be changed if necessary.
>
> But maybe we indeed can make a similar tree with "experimental" features.
> I think that is a good idea, to change thoughts as we did now. Because they
> were all in extensions I assumed this was meant to be developed further
> etc, it seemed quite complete, so good to hear it was more meant for
> discussion.
>
>
>
>
>> Yes, all features are experimental, they may be removed. I've implemented
>> them as an example of what I'm talking about in the emails. The ball is no
>> longer needed. I'd hardly say that the rest exists though. However some of
>> those features aren't needed. The minimal set would probably include only
>> Concepts and strategies for translate().
>>
>>  I realize you mailed recently about this, 27/5, but one or two days
>>> later you mailed that it was sent too hastily. So it was mostly ignored.
>>> Or do we still have to re-read these mails before understanding the
>>> things above?
>>>
>>
>> Everything is above. I have some doubts about the Concepts and interface,
>> but this maybe later.
>>
>
> OK great, thanks again for your explanations, it is much more clear to me.
>
>
> Regards, Barend
>
>
> ______________________________**_________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/**mailman/listinfo.cgi/geometry
>

>