cgal
cgal copied to clipboard
Wrong of delaunay 3d
Issue Details
Delaunay 3d meshing results are abnormal.
Just like this.
On some faces the nodes are all ok, on others many nodes are ignored.
Source Code
std::vector<floatTetWild::Vector3>& pos = inpio_.GetPos();
//std::sort(pos.begin(), pos.end(), [](const floatTetWild::Vector3& lhs, const floatTetWild::Vector3& rhs) {
// return lhs[0] < rhs[0] && lhs[1] < rhs[1] && lhs[2] < rhs[2];
// });
//pos.erase(std::unique(pos.begin(), pos.end()), pos.end());
std::vector<int> v(pos.size());
std::iota(v.begin(), v.end(), 0);
std::vector<Point> points;
points.reserve(pos.size());
for (int i = 0; i < pos.size(); ++i) {
points.emplace_back(Point(pos[i][0], pos[i][1], pos[i][2]));
}
CDT cdt;
cdt.insert(boost::make_zip_iterator(boost::make_tuple(points.begin(), v.begin())),
boost::make_zip_iterator(boost::make_tuple(points.end(), v.end())));
assert(cdt.is_valid());
std::vector<floatTetWild::Vector4i> newtets;
newtets.reserve(cdt.finite_cell_handles().size());
for (CDT::Cell_handle c : cdt.finite_cell_handles()) {
floatTetWild::Vector4i tet;
for (int i = 0; i < 4; ++i)
tet[i] = c->vertex(i)->info();
newtets.emplace_back(tet);
}
assert(cdt.finite_cell_handles().size() == newtets.size());
Environment
- Operating system (Windows/Mac/Linux, 32/64 bits):Windows
- Compiler:MSVC
- Release or debug mode:debug
- Specific flags used (if any):no
- CGAL version:5.1.1
- Boost version:1.75.0
- Other libraries versions if used (Eigen, TBB, etc.):Eigen
Can you please put a self-contained file on gist.github.com so that we can reproduce. We do not see what you include and how you typedef. Together with point data. And then tell us what exactly you expect.
ok.But I used a static library. See that in https://github.com/tyc1998/inpmerger. Thanks!
ok.But I used a static library. See that in https://github.com/tyc1998/inpmerger. Thanks!
@afabri That's my code.
By the way, my code triggered CGAL::Uncertain_conversion_exception. I don't konw how it influence the result. @sloriot @afabri @lrineau L @marv Sorry to bother you, but really need help.
I further observed the results, and it seems to be caused by the numerical precision. The numerical precision of the tetrahedron division is too precise, which leads to a difference with the input, which further leads to a layer of tetrahedrons at the bottom of the hexahedron.