Hi
I have a CGAL Code that works for remeshing but when I want to use the same task in VESPA, it gives me nothing. does anybody else who can help me?
the results are shown below:
My code in CGAL:
My code in VESPA:
the output in cmd:
My code in VESPA:
the output in cmd:
1 Like
@kimia_ghodoosi As I see you used the same target length for both your native CGAL code and the Vespa one, I assume the preprocess you do with split_long_edges is the reason you don’t have the error in your version.
An easy fix would be to update the Vespa code with your own version to see if it works. A better approach would be to merge both. If you do so, please open a MR and I would be glad to update Vespa accordingly 
does VTK have a class for remeshing? if I decide not to use CGAL or VESPA.
@Charles_Gueunet
Sorry, I wanted to use toCGAL method for converting my polydata to a CGAL mesh but it doesn’t work although i created an object like this vtkNew rm
could you please help me to convert a vtk polydata to a cgal surface mesh?
Regarding re-meshing, the closest thing you will find Delaunay. You can also have some decimation filters like the vtkQadricDecimation, as shown here, but this is more re-meshing.
for the CGal conversion, you may have a look at the vtkCGALPolyDataAlgorithm::toCGAL method here.
Keep in mind that this method is used when adding new filters into Vespa. Using the library, you simply need to set your polydata as input of your filter.
Hi. I tried vtkQuadricDecimation and it was very good in Debug mode but it didn’t have the same result in release mode.do know how i can solve this problem?
Do you have a sharable state + data so I can try to reproduce the behavior ? You may want to try to compile in RelWithDebInfo in order to get the Release optimizations while still keeping some debug abilities. With a bit of luck, the undefined behavior will still leads to bug in this mode.
well, I built my project in “RelWithDebInfo” but it has the same problem that had had in Release mode.
This is my code:
double target_reduction = targetReduction;
vtkNew decimate;
decimate->SetInputData(polydata);
decimate->AttributeErrorMetricOn();
decimate->SetTargetReduction(targetReduction);
decimate->VolumePreservationOn();
decimate->Update();
@kimia_ghodoosi I quickly tried the following C++ pipeline:
vtkNew<vtkSTLReader> reader;
reader->SetFileName(baseName.c_str());
vtkNew<vtkConnectivityFilter> largestCC;
largestCC->SetInputConnection(reader->GetOutputPort());
largestCC->SetExtractionModeToLargestRegion();
vtkNew<vtkQuadricDecimation> decimate;
decimate->SetInputConnection(largestCC->GetOutputPort());
decimate->AttributeErrorMetricOn();
decimate->SetTargetReduction(0.9);
decimate->SetVolumePreservation(true);
decimate->Update();
std::cout << "Actual reduction: " << decimate->GetActualReduction() << std::endl;
vtkNew<vtkXMLPolyDataWriter> w;
w->SetInputConnection(decimate->GetOutputPort());
w->SetFileName("result.vtp");
w->SetDataModeToAscii();
w->Write();
With both VTK and my test module build in Release
It leads to the following result:
Which seems fine to me. Here is the result.vtp (317.1 KB) for inspection.
I used VTK master for this pipeline, and I added a connectivity filter to extract the largest area.
Best,
Charles
Thank you so much for your response but I have the same problem that I had, with your code.my version of visual studio is 2019 and my VTK version is 9.2.6. do you think that the problem occures because of my Visual Studio or VTK?
@Charles_Gueunet
@kimia_ghodoosi I would suspect the version of VTK may be a potential suspect here as we improved the vtkQuadricDecimation in between v9.2 and v9.3. Can you try with the v9.3 release ?