Is it possible to use Eigen as types for CGAL?

[afabri]

This was a question on stackoverflow

I am wondering how far we can get by replacing std::array<FT_, 3> with Eigen::Matrix<FT,3,1> and the some make_array() calls in Vector_3.h. This might even work for FT different from double. Any thoughts @sloriot and @mglisse ?

[mglisse]

The type Point_3 would still not be an Eigen type. Adding conversions between Point_3 and Eigen would probably help that user more. Making Point_3 derive from Matrix could achieve some of that. I didn't check recently if NewKernel_d still worked with Vec_=LA_eigen in Cartesian_LA_base.h...

[jjcasmar]

Would adding a template parameter to the Kernel to specify the point type work? That way we could define the default type to be what it is now, but the user could override it and could build a kernel with its own point type.

[mglisse]

Even if you got rid of Type_equality_wrapper, Kernel_23 assumes that a point can be created with Point_3(x,y,z), that coordinates can be accessed with .x(), .y() and .z(), etc (In NewKernel_d, I always use the equivalent of Construct_point_3 and Compute_x_3).
And why stop at points? People might want to specify Vector_3 as well (and Kernel_23 relies on the fact that this is not the same type as Point_3), and possibly more.

[afabri]

The point class is nevertheless the most fundamental one.

[jjcasmar]

Eigen provides .x(), .y(), .z() and .w() operators.

[mglisse]

Indeed, it has the constructor from 3 coordinates and .x, which could help, but it doesn't have .dimension(), .cartesian(i), .w() which returns 1 for 2d/3d points, etc. CGAL didn't really try to be generic there, so there may be quite a few assumptions baked in.

[lrineau]

What could be done (but that is a big work) is to create a model of CGAL Kernel concept that uses Eigen types. But it would only be a model of the concept, and will not have:

• the type-equality property, that allows the use of all the global functions in the CGAL namespace (like CGAL::compare_squared_distance),
• the user-friendly constructors (Point_2(double, double)) and accessors (.x(), .y()...).

[jjcasmar]

I am not sure I understand the second point.
If you parametrize your kernel with an Eigen::Vector2d for the Point_2 type, the constructor should work, no? Also .x() and .y() are members of Eigen::Vector2d. It can be used up to .w() as an equivalent of Eigen::operator[](0//1//2//3)

[lrineau]

I am not sure I understand the second point.
If you parametrize your kernel with an Eigen::Vector2d for the Point_2 type, the constructor should work, no? Also .x() and .y() are members of Eigen::Vector2d. It can be used up to .w() as an equivalent of Eigen::operator[](0//1//2//3)

You are right:

• the constructor from coordinates would certainly work,
• the accessors x(), y(), z() are from Eigen::DenseCoeffsBase, that is a base of Eigen::Vector2d.

w() will be wrong, though, because for CGAL::Epick::Point_3 it is supposed to return always 1 (without storing that coordinate). But that is probably not a major issue.

I do expect the required work to be a lot of work, though. I am not sure that is a price the CGAL project is willing to pay, because the benefit is rather small for the project. ... Actually, that would be nice to have in CGAL a kernel that interoperate with a third-party library, without copies, just for the sake of verifying if our data-structure and algorithms use the Kernel concept as it is documented and nothing more.

[jjcasmar]

Fair enough. iirc OpenMesh had to do a lot of changes to internal stuff to be able to fully use Eigen for its data types, mostly modifying all Point::foo to free functions so that they could be overloaded with Eigen. Looks like a lot of work to do that in CGAL.

[jjcasmar]

My idea would be something like this:

// Create a kernel with Eigen::Vector2d and Eigen::Vector3d for K::Point_2 and K::Point_3 types
using K = CGAL::Simple_cartesian<double, Eigen::Vector2d, Eigen::Vector3d>;

// A triangle which uses Eigen::Vector3d as point type
using Triangle = K::Triangle_3;

I admit I don't know too much about CGAL internals. Could something like that work?

[mglisse]

Yes it could work, the question is how much work it would be. And you probably wouldn't want to stop there, You would want to be able to add some filtering on top of it (like Epick).

[mglisse]

One thing I forgot to mention: using Eigen types safely (without a lot of special code) probably requires C++17 (aligned new).

[lrineau]

That is not a problem: we are talking about the possibility to decline a new model of Kernel. It can require C++17. The current CGAL kernels (as of CGAL-5.2) would remain with the same implementation and requirements.

[mglisse]

It was relevant for NewKernel_d, which can already use Eigen vectors internally.

[lrineau]

It was relevant for NewKernel_d, which can already use Eigen vectors internally.

That is fine: new features of CGAL can have extra requirements (besides C++14), if that is justified and documented.