CGAL
Isosurfacing_3 (new package)
Summary of Changes
Extracting isosurfaces from scalar functions is a common method for generating 3D meshes. An isosurface is a subspace with equal values of the function.
### ToDo:
- [ ] Check branch size
- [ ] TMC_functor::compute_edge_index() uses operator[] on cell_descriptor (violates concept)
- [ ] Check Orthtree as partition for Marching Cubes after fixing compute_edge_index()
### Extra:
- [ ] Use Isosurfacing_3 in the demo (Isosurface_3_plugin)
Release Management
- Affected package(s):
Isosurfacing_3 - Issue(s) solved (if any): -
- Feature/Small Feature (if any): Isosurfacing_3
- License and copyright ownership: see feature
There was an error while building the doc: /home/runner/work/cgal/cgal/Isosurfacing_3/include/CGAL/Octree_wrapper.h:330: warning: The following parameters of CGAL::Isosurfacing::Octree_wrapper::e_glIndex(const std::size_t &e, const std::size_t &i_idx, const std::size_t &j_idx, const std::size_t &k_idx, const std::size_t &depth) const are not documented:
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
The data files have a problem with rights. I think they also need o+r But more importantly they should be in the package Data so that we do not have millions of bunnies and skulls.
The documentation is built. It will be available, after a few minutes, here: https://cgal.github.io/6849/v1/Manual/index.html
@MaelRL as you recently cleaned up CMakeLists.txt files in a PR: Are my additions concerning Eigen needed or not. Apparently @JulyCode does not need them. And note that I removed eigen3 from <eigen3/Eigen/SVD>. Maybe he needs that?
I did not need them. I have Eigen installed with vcpkg and used that as toolchain for cmake. But for me everything still compiles, so apparently the changes don't do any harm.
Hello @JulyCode, I think it would be a good idea to run vtune already once in an early stage to identify performance problems. What cpp would you suggest to run with which data set and what parameters? A run should take more than 30 sec.
Note that the CI fails with the message The following files have tabs: Isosurfacing_3/examples/Isosurfacing_3/CMakeLists.txt
Hello @JulyCode, I think it would be a good idea to run vtune already once in an early stage to identify performance problems. What cpp would you suggest to run with which data set and what parameters? A run should take more than 30 sec.
There is benchmark/benchmark.cpp that I used for benchmarking so far. In benchmark/benchmark_size.py and benchmark/benchmark_utils.py you can see how it has to be build (the CMake defines are the important part). You can also just let the Python script build it and then cancel it. It can then be run with for example the argument -N 500 to get a sequential runtime of a few minutes.
IIRC you need to have your CGAL membership public on github for it to work, which isn't the case for @JulyCode (to be modified in one's settings).
It likely should be documented clearly on https://github.com/CGAL/cgal/wiki/Building-the-Documentation.
I'm not sure, if what I changed was enough. This way of building the doc is not mentioned on the wiki page at all as far as I can see.
You have to change it there: https://github.com/orgs/CGAL/people?query=julycode. It's still private.
My comment above was saying that indeed it is not documented on that particular wiki page, but that it should have been.
The documentation is built. It will be available, after a few minutes, here: https://cgal.github.io/6849/v2/Manual/index.html
@sloriot @MaelRL: Daniel just told me that @JulyCode has test data locally on his machine. Can you advice how to proceed. Apparently they are publicly available but not necessarily in a format we can read (so we maybe have to convert), and rather big. We have to check under which license, and where to put them, and with which parameters they should be meshed.
@JulyCode @MaelRL Hi, what would be the best references to compare this implementation to? Marching Cubes from VTK probably. You have any other suggestions?
I turned a vtkImage into Image_3, then CGAL::Isosurfacing::Cartesian_grid_3<Kernel>, then CGAL::Isosurfacing::create_explicit_Cartesian_grid_domain(grid) and finally applied CGAL::Isosurfacing::marching_cubes.
There is a result, however, I get plenty of "ERROR: can't correctly triangulate cell's face" and in the resulting off file are quite a few isolated vertices as the polyhedron demo told me. I understand why marching cubes can generate isolated vertices, just wanted to mention it.
The input image is a medical image with anisotropic voxels. The debugger shows that the voxel size is in the domain that is passed to the marching cubes. The resulting mesh, however, seems to assume a isotropic voxel size. Thus, the result looks compressed to the result generated by vtks marching cube.
Code: https://gist.github.com/soesau/127d7d7cdefbf6be4f36c397208cbdcd
The image is FullHead.mhd/.raw from https://github.com/lorensen/VTKExamples/tree/master/src/Testing/Data
I turned a vtkImage into Image_3, then CGAL::Isosurfacing::Cartesian_grid_3, then CGAL::Isosurfacing::create_explicit_Cartesian_grid_domain(grid) and finally applied CGAL::Isosurfacing::marching_cubes.
There is a result, however, I get plenty of "ERROR: can't correctly triangulate cell's face" and in the resulting off file are quite a few isolated vertices as the polyhedron demo told me. I understand why marching cubes can generate isolated vertices, just wanted to mention it.
The input image is a medical image with anisotropic voxels. The debugger shows that the voxel size is in the domain that is passed to the marching cubes. The resulting mesh, however, seems to assume a isotropic voxel size. Thus, the result looks compressed to the result generated by vtks marching cube.
Code: https://gist.github.com/soesau/127d7d7cdefbf6be4f36c397208cbdcd
The image is FullHead.mhd/.raw from https://github.com/lorensen/VTKExamples/tree/master/src/Testing/Data
Unfortunately I can't test this with your image right now, because I don't have vtk installed at the moment. Are you using the latest version of Isosurfacing? The last commit fixed a bug that prevented anisotropic voxels when using the Cartesian_grid_3. I only tested this with another image with anisotropic voxels and it seems to work for me.
Regarding the error messages and isolated vertices: our version of marching cubes actually should guarantee a manifold mesh without any isolated vertices, so I'm very curious what causes this. I'll look into it as soon as possible. Does the isosurface leave the image at some point? Another reason could be that the values are inverted. Medical images often use positive values on the inside and negative on the outside. We require it to be the other way around, positive values on the outside of the mesh. Do you know if this is the case for your image? If so, negating all values of the image could resolve the issue with isolated vertices.
Ok, I can confirm, that a recent commit fixed that voxel size bug.
The surface is inverted, e.g., the backfaces show outside and the front faces are on the inside. I'll see if I can check the image values to confirm. But it is a medical image. "ERROR: can't correctly triangulate cell's face" still appears with the last version. I'll check to invert the image and try again.
I managed to convert the vtk image to an inr image and attached it to the gist below.
I added the inversion and I still get the triangulation error and a number of isolated vertices in the off file. But the orientation is now correct.
https://gist.github.com/soesau/0265212bbaf409b268db6b1189791b7d
I managed to convert the vtk image to an inr image and attached it to the gist below.
I added the inversion and I still get the triangulation error and a number of isolated vertices in the off file. But the orientation is now correct.
https://gist.github.com/soesau/0265212bbaf409b268db6b1189791b7d
Ok, thanks. I will take a look and try to find the reason for the errors.
I tried the parallel version using TBB. But I get crashes which seem to be caused by a race condition. When changing the input containers, PointRange and PolygonRange, to tbb::concurrent_vector the crashes disappear. However, the resulting mesh has plenty of wrong triangles. Seems to me, that the triangle indices are messed up.