From: Bruno Lalande (bruno.lalande_at_[hidden])
Date: 2008-03-07 17:54:12
We've talked about representing positions in space but the other thing I was
thinking about when talking about spatial data structures was rotations.
Rotations are representable by different kinds of structures (Euler angles,
matrices, quaternions...), the choice of which strongly varies with their
usage, the needs in performance, the degree of security needed (about gimbal
lock and stuff like that), the underlying hardware, etc...
The same principle as for points (structure / algorithms separation) cannot
apply here since the algorithm needed to do a specific computation is
completely different from one type to another. But it would be good to have
a concept specifying the interface that a structure must provide to be
considered as a "rotation" (rotate() functions, interpolations, point
transformations (our Point concept, precisely), conversions from one
structure type to another, etc...), and implementing this concept for the
most known rotation types (at least the 3 mentioned above). This way :
- we have a basic set of rotation data structures to play with
- developers of libraries that manipulate rotations only have to focus on
Structurally, we already have a quaternion in Boost.Math as well as the
uBlas library for matrices. We only need some algorithms above them to make
them speak a more "rotational" and common language.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk