vtk Delaunay2D is too expensive, how can i accelerate

I use the following code

// _pd is a vtkPolyData object  only with points
// the code is c# 
var delaunay =  vtkDelaunay2D.New();

the above code cost 100 millisecond level while the _pd have 10,000 points,.
So i use c++ CGAL build delaunay2D , in c++ code, CGAL build delaunay2D cost 10 ms level with the same points. Then I Pass cell information to c#.
I think I’m using it wrong, can you tell me how to speed up the delaunay2D of vtk? I just need cell and point information。

This is a known issue with VTK delaunay implementation.

FYI @Tiffany_Chhim @Charles_Gueunet

1 Like

We aim to improve the vtkDelaunay2D filter, I will keep you informed if we manage to get the time to do so.
If you want to keep the VTK flexibility while having the CGAL performance, please have a look at the Vespa project. This is a collection of VTK filters relying internally on CGAL. It provides a Delaunay2D vtkAlgorithm.


Thank you very much for your prompt reply!
Although CGAL’s delaunay is fast, there seems to be a problem.
As you see, this fig is CGAL Delaunay,When the data is not closed like this, the edges will have strange triangles

the same data vtk is

I haven’t looked at the source code of vtk, but I want to ask if this is related to the
set by vtk,
I use fast-vtk-delaunay2d, Its performance is the same as cgal, and the reconstruction of this kind of data is not good.
As for the simultaneous use of vtk and cgal you said, I have already realized it. The point I’m struggling with now is this strange triangle, is there a good way to get rid of it?

1 Like

Could you show use or share the point cloud you use ? Delaunay2D should be applied on planar data, or data that can trivially be projected onto a plan. Is it the case for you ?

1 Like

Thank you very much for your reply. I think I probably know where the problem is. It should be the problem of vtk and cgal for the accuracy of point coordinates. I converted my xy coordinates into int values to solve this strange triangle problem. in fact, the source data is originally int, because I used the depth map to generate point cloud, which went through a series of preprocessing into float.