CGAL users discussion list

[Sebastian Bachmann <>]

Hi!

Sure, here is an example: https://files.reox.at/.mesh/

You may have to run it several times until such a hole appears, as no 
optimization is present. However, you can make them appear much easier 
by changing the line with refine_mesh_3 to:
  CGAL::refine_mesh_3(c3t3, domain, criteria, CGAL::parameters::odt());

ODT seems to be more prone than Lloyd.
I uploaded two surface.off files as well, where this can be seen 
(surface.off is without odt/lloyd and the second run, surface_odt.off is 
with ODT active).

Best,
Sebastian

Am 17.02.2025 um 11:34 schrieb Jane Tournois:
> Hello,
> can you please post some code and data so that we can try to reproduce 
> your issue?
> Best,
> Jane
>
> Le 07/02/2025 à 16:30, Sebastian Bachmann ( via cgal- 
> discuss Mailing List) a écrit :
> > Hi!
> >
> > I send this mail to the list yesterday, but apparently it was not 
> > posted - but I also did not get a rejection mail? I suspect that 
> > attachments are not allowed and get silently dropped?
> > So here it is again with a link instead, sorry if it is now posted twice!
> >
> >
> > I extended the example code from 
> > mesh_3D_image_with_custom_initialization.cpp to mesh a multi-label 3D 
> > image, i.e., I have for example 3 voxel values: 0 (background), 1 
> > (some part), and 2 (some other part).
> > This works reasonable well, but if I go down with the cell size, I get 
> > weird artifacts in the surface of the mesh: at some random places, 
> > "holes" appear (see screenshot here: https://files.reox.at/.mesh/ 
> > screenshot.png).
> >
> > I tried to track down the problem and it can be triggered by using 
> > lloyd or odt optimization. When either of these are used, such holes 
> > appear in my mesh (much much more in odt) - if I switch them off, 
> > these holes are usually gone. But I found also images were such holes 
> > appear in certain configurations, even without llyod or odt active.
> > There, I can influence these holes by choosing a larger 
> > relative_error_bound in create_labeled_image_mesh_domain (my default 
> > is 1e-7) or by generating a new mesh, as there is some randomness in 
> > initialize_triangulation_from_labeled_image (in my code, I specified a 
> > seed for the PRNG and thus can reliably trigger it by choosing a 
> > specific seed).
> >
> > Interestingly, it seems to appear more often when more than two labels 
> > are used. Thus, in a binary image (only 0 and 1), this does not 
> > happen. For example, if I take the same image with 3 labels and 
> > replace all 2's by 1's, I get a much better mesh.
> >
> > Is there anything I may have missed to implement, for example during 
> > the creation of the label domain? I can try to track down the problem 
> > even more, but don't know at the moment where to look next and thus 
> > would appreciate some guidance!
> >
> > Best,
> > Sebastian