CGAL users discussion list

[Sebastien Loriot <>]

On the attached screenshot, you'll see in read the intersection of
the output mesh with the cube (0 0 0 -> 100 100 100).

So clearly, the mesh is not exactly on the cube.
The initialization (intersection of the image with the cube) is
done with points exactly on the cube. But then, intersection points
are computed by bisection (it is handled as an image).

Snapping could be done by using a dedicated oracle using a different
intersection computation function when the segment intersect the
boundary cube.

Best,

Sebastien.


On 5/9/22 10:43, hello ( via cgal-discuss Mailing List) wrote:
> Hello,
>
> sure! Attached is an example source code and the resulting file for the 
> 420 example.
>
> I would have expected, that all nodes on the bounding surfaces are 
> either at x/y/z 0 or 100 (as it is for the edges) but instead they 
> appear roughly at 0 or 100 +-0.05.
> It seems to correlate with the relative_error_bound, however I can only 
> make the error smaller but not go away completely. (The attached file is 
> generated with 1e-3)
>
> Best,
> Sebastian
>
>
> On 09.05.22 09:23, Sebastien Loriot ( via 
> cgal-discuss Mailing List) wrote:
> > Hello,
> >
> > could you share a minimal example showing the problem?
> >
> > Thanks,
> >
> > Sebastien.
> >
> > On 5/7/22 13:37, Sebastian Bachmann ( via cgal-discuss 
> > Mailing List) wrote:
> > > Hello,
> > > No one has an idea? Is it not somehow possible to restrict nodes onto 
> > > a surface? I.e. if I have the polyline of the surface's boundary, can 
> > > I specify that all nodes must be on that surface?
> > >
> > > For now I have written a function to go over all nodes and check if 
> > > they are near such a boundary face and then "pull" the nodes onto 
> > > that surface. However, there are certain edge cases were this then 
> > > yields collapsed triangles etc. Thus, solving this during meshing 
> > > would be a great enhancement.
> > >
> > > Best,
> > > Sebastian
> > >
> > > On 25.04.2022 07:16, Sebastian Bachmann ( via 
> > > cgal-discuss Mailing List) wrote:
> > > > Hello,
> > > >
> > > > I created an image meshing tool, similar to the one given here in 
> > > > this example code: 
> > > > https://doc.cgal.org/latest/Mesh_3/Mesh_3_2mesh_3D_image_with_features_8cpp-example.html 
> > > > with the only difference, that I extract the surface elements and 
> > > > not write the full 3D mesh.
> > > > I noticed, that on the image boundary, the vertices would be not 
> > > > exactly on the face but roughly +- the relative error bound given in 
> > > > create_labeled_image_mesh_domain. For examples, nodes on the xy 
> > > > plane at z=0 are not on z=0 but for example -0.01 to 0.01. While the 
> > > > protected polylines are exact and have always z=0.
> > > > I created for example a mesh from the 420.inr example with the same 
> > > > meshing criteria as given in the example and can see that behaviour 
> > > > there.
> > > >
> > > > While you can control the maximal deviation using the relative error 
> > > > bound, there will always be some deviation. And if I set the 
> > > > relative error bound too low, it seems the meshing never finishes.
> > > > I wonder now, if it is possible to constraint the mesh (similar to 
> > > > the 1d polylines), such that the vertices for facets on the image 
> > > > boundary, are always exactly on the image boundary?
> > > >
> > > > Best,
> > > > Sebastian

Attachment: Screenshot from 2022-05-09 15-25-11.png
Description: PNG image