ParametrizedLine should follow the Hyperplane model and have a transform methods for matrices and Transforms.
I'll try make a formal patch but including special methods for homogeneous transforms, something like memberized versions of these (mostly untested) non-member templates: template<typename LineT, typename XprType> inline LineT& transform( LineT & line, const Eigen::MatrixBase<XprType>& mat, Eigen::TransformTraits traits = Eigen::Affine ) { if (traits==Eigen::Affine) line.direction() = mat.inverse().transpose() * line.direction(); else if (traits==Eigen::Isometry) line.direction() = mat * line.direction().homogeneous(); else eigen_assert(0 && "invalid traits value in ParametrizedLine::transform()"); return line; } template<typename LineT, typename Scalar, int AmbientDimAtCompileTime, int TrOptions> inline LineT& transform( LineT & line, const Eigen::Transform<Scalar,AmbientDimAtCompileTime,Eigen::Affine,TrOptions>& t,Eigen::TransformTraits traits = Eigen::Affine ) { transform(t.linear(), traits); line.origin() += t.translation(); return line; } template<typename LineT, typename XprType> inline LineT& transformHomogeneous( LineT & line, const Eigen::MatrixBase<XprType>& mat ) { typename LineT::VectorType pt0 = line.origin(); typename LineT::VectorType pt1 = line.origin() + line.direction(); pt0 = (mat * pt0.homogeneous()).head(line.dim()); pt1 = (mat * pt1.homogeneous()).head(line.dim()); line.origin() = pt0; line.direction() = (pt1 - pt0).normalized(); return line; } template<typename LineT, typename XprType> inline LineT transformHomogeneous( const LineT & line, const Eigen::MatrixBase<XprType>& mat ) { LineT outLine; typename LineT::VectorType pt0 = line.origin(); typename LineT::VectorType pt1 = line.origin() + line.direction(); pt0 = (mat * pt0.homogeneous()).head(line.dim()); pt1 = (mat * pt1.homogeneous()).head(line.dim()); outLine.origin() = pt0; outLine.direction() = (pt1 - pt0).normalized(); return outLine; }
It seems that this function has been implemented (https://bitbucket.org/eigen/eigen/commits/c2fee950a7f1e2eeccfd03f492532f6aa9e212b4) in 2016 and is present on the default branch: https://bitbucket.org/eigen/eigen/history-node/28668dca1bdef0cbd403013d7ce0158aff9f0cbf/Eigen/src/Geometry/ParametrizedLine.h?at=default I don't understand why, but that same commit is not present in the 3.3 branch: https://bitbucket.org/eigen/eigen/history-node/79c45742ea21cbb368742d441c31ecc64c005ec4/Eigen/src/Geometry/ParametrizedLine.h?at=3.3 I don't know the development model of Eigen, but I guess that the change which has been made on the default branch three years ago should also be in the latest release?
In general, the stable branch only gets bug-fixes. New features only go to the development branch. It is a bit unfortunate that this feature got added shortly after releasing 3.3 (and that it often takes a while between new releases). Is switching to the development branch an option for you? Otherwise, you can add a free function doing that. Open questions regarding this feature: Should we change the API to operator*(Transform, ParametrizedLine); and for consistency, shouldn't we add transform functions for Hyperplanes as well? And AlignedBoxes (--> Bug 1623)
> In general, the stable branch only gets bug-fixes. New features only go to the development branch. It is a bit unfortunate that this feature got added shortly after releasing 3.3 (and that it often takes a while between new releases). I see. Well for semantic versioning I guess it's expected behavior then, and I am indeed just unlucky that the 3.3 branch was branched off just before feceaf0 was added ;-) I have worked around it by transforming my points before I use `ParametrizedLine::Through(...)`, so I think I don't need to switch to the develop branch just for this change. Also just wanted to link this issue with the commit because it seems there was no mention of this bug in the commit message.
(In reply to Christoph Hertzberg from comment #3) > Open questions regarding this feature: Should we change the API to > > operator*(Transform, ParametrizedLine); > > and for consistency, shouldn't we add transform functions for Hyperplanes as > well? And AlignedBoxes (--> Bug 1623) My feeling is that using operator* for that is going a bit too far regarding abuse of notations. Hyperplane already exposes such a transform() function (it is present in 3.3)
-- 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/445.