The goal of such a class is to hold rotation and translation into separate objects. My use case is to extend a Quaternion with Translation information. The reason I do not want to use Affine3d is that, for my algorithm, I need to compute the angle of transformations at each iteration, which is extremely slow to get from an Affine3d. This class allows me to get cheap computation of the angle, while keeping the ease of composing transformations together. Even if I don't really see an use beyond having a Quaternion with a Translation, I have made it generic, in the sense that you can use it with other type of rotation, such as AngleAxis. I have attached a pre-patch. If there is an interest for this class in Eigen, I am willing to spend more time to polish it, update documentation and write an unit test.
IIRC, Rohit implemented dual quaternions which sounds like what you are looking for though I don't know where the implementation is :) Maybe you can ask about it on the mailing list. Another thing is that I am not seeing your patch. Did you attach it?
Created attachment 10 [details] rotation translation I must have missed something when submiting the bug... hope the attachement get attached this time :) Yes it is possible that dual quaternion can solve my problem. So I won't invest more time in this patch and switch to dual quaternion when available.
Wait, I believe that both quaternion+vector (as in your patch) and dual-quaternion are useful to have --- I'm sure that they both have their areas of use, i.e. each is faster for certain ops. So (at least to be future-proof) we should make sure they can cohabit, and the first thing to do is to give them explicit names: so s/RotationTranslation/QuaternionTranslation or QuaternionVector. Notice that in Eigen, we've kept the word 'rotation' in a generic sense, so we use specific words for each specific kind of rotation.
Well actually the rotation class is defined to use any rotation as: template<typename _Rotation> class RotationTranslation { ... } and then there is a typedef: typedef RotationTranslation<Quaterniond> QuaternionTranslationd;
Ah! sorry. Should have looked at your patch :) I don't have naming concerns anymore then. Hauke: I think this is good to have regardless of dual quaternions. What's needed, then, is a good unit test. But the timing is pretty bad as this is a bit too late for 3.0. I'd suggest this for 3.1.
The patch looks good so far. The _Rotation template should be exposed publicly. What is missing besides the unit tests are multiplication operators in order to be able to apply these "rigid" transformations to points and point sets.
-- GitLab Migration Automatic Message -- This bug has been migrated to gitlab.com's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.com/libeigen/eigen/issues/47.