|
Geometry : |
Subject: Re: [geometry] translation and rotation proposal
From: Adam Wulkiewicz (adam.wulkiewicz_at_[hidden])
Date: 2013-05-29 08:07:21
Hi,
2013/5/29 Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]>
>
> I was probably too hasty with the rotation proposal and must think more
> about it.
>
>
The reason that I've written that I had been too hasty is that if we
consider calculating the rotation between two arbitrary vectors, this
really would be a rotation between corresponding, normalized vectors (or
vectors of the same length) because only the angle and the axis of rotation
counts. This means that it won't be possible to calculate the rotation
between two arbitrary vectors, apply it to the first one and always get the
second one. So this differs from translation where one may:
v = return_translation(p1, p2);
p3 = return translated(p1, v);
equals(p2, p3) == true
I think about those options:
1. Don't mind it and write in docs that the rotation is calculated between
normalized vectors/points/etc. This is probably what's done in most
libraries or other code in the Net.
2. Force the user to express mentioned property of a rotation in the code -
provide UnitVector concept (which btw could be used for different purposes)
and allow calculating rotations using unit-length vectors only.
Normalization of vector could be done by convert() function:
bg::convert(vec, unit_vec);
bg::convert(point, unit_vec); // ?
// or
bg::normalized(vec, unit_vec)
bg::normalize(vec, unit_vec) // ?
3. Think about some other interface
>
> Another thing, if we have transformations in the future, it would probably
> be good to replace translate() and rotate() with one transform() function
> working for vectors, rotation and transformation matrices, quaternions, etc.
> And then replace translation() by some more general name like
> vector_between().
>
>
It would be nice to allow connecting transforms to form a compound
transformation. It maybe would be possible to use expression templates
however I don't know if would work well with Boost.Geometry's design
rationale. For now I think of some naiive solution. We could probably use
some function like bg::append() however this name probably isn't good
enough. Nevertheless the example would look like this:
model::transformation_matrix<double, 3> tm;
model::rotation_matrix<double, 3> rm;
model::rotation_quaternion<double> rq;
model::vector<double, 3> v, v1, v2;
bg::rotation(v1, v2, rm);
bg::rotation(v1, v2, rq);
bg::translation(v1, v2, v);
bg::convert(rm, tm);
bg::append(tm, rq);
bg::append(tm, v);
bg::transform(geom, tm);
// the same as:
bg::transform(geom, rm);
bg::transform(geom, rq);
bg::transform(geom, v);
Ok, I wanted to initiate a small mind storm here ;)
Especially I'd like to hear what do you Bruno have to say about this,
because I remember you mentioned vectors some time ago.
Regards,
Adam
Geometry list run by mateusz at loskot.net