2 Region Meshing node/vertex/facet Issues

[DNedrelow]

Hi, I'm really amazed with the run_TetGen() function. It works great when I have two STL networks with one inside the other, but whenever one object intersects another, the volume cannot be meshed because of the overlapping networks. My current strategy is to assemble the object faces that intersect in 2D using the regiontrimesh2D() function, but then when I put more faces together, the edges do not share nodes and I run into the same problem. I think I must be missing some function that will nicely clean up all of my intersection problems... I want the attached image mesh, but with the blue part going all the way to the edge (intersects the surface mesh of the red part). Any tips appreciated.

[abhiawasthi1993]

Hi @Kevin-Mattheus-Moerman, I am also facing the same issue while using TetGen to mesh my 3D segmented model, as there are multiple faces that intersect. Any help in this regard would be greatly appreciated.

PS: The model passed all the preliminary tests mentioned in one of the previous this issue.

[Kevin-Mattheus-Moerman]

@DNedrelow @abhiawasthi1993 thanks for posting your issues/comments. Sorry I have not been able to respond as quick as I'd like.

Dealing with surfaces intersecting each other, depends a bit on how you want to resolve it.

1) They should not intersect, the intersection is an artifact. The surfaces are just very very close normally but due to things like "noise" one protrudes through the other in some spots.

For a case like this you'd need to work to resolve the overlap first. TetGen cannot resolve it for you. TetGen can only fill well defined regions with tetrahedrons. I have had blood vessels with features intersecting in the past. To resolve it I've pushed one surface out of the way (e.g. by moving nodes in the direction opposite to the local surface normal). You can do this locally by first "detecting" the overlapped region. You can also do this iteratively with tiny steps to "push until resolved". Detecting the overlap/intersection, may require some distance computations. Let me know if you need to know more on this.

2) The overlap/protrusion is a real feature and I need to have a volumetric mesh incorporating this real phenomenon.

In this case you'd need to cut the surfaces with each other. You start with surface 1 that enters surface 2, but then you compute surface 3 (surface 1 inside surface 2), and also surface 4 (surface 2 inside surface 1). You then also need to remesh the intersection region to have node shared regions so the surfaces touch at nodes at the intersection. Once you have this you tell TetGen to mesh region 1 (consisting of the space in surface 1+4), region 2 (the space inside surface 3+4), and region 3 (space inside surface 2+3). Let me kwow if you need to more on this too.

More information on exactly what you want is needed. And if you could share close up pictures of the issues/intersections that would help too.

Hope this helps.

[DNedrelow]

Prof M,Ah thanks. I was trying something along approach 2 as you described it. I had failed to appreciate how even shared nodes at the interface will have intersecting surfaces. I dream of a day when I won’t have to kludge these surface intersections together. Maybe with some luck I can share some applicable functions. DavidSent from my iPhoneOn Oct 24, 2023, at 5:08 AM, Kevin Mattheus Moerman @.***> wrote: @DNedrelow @abhiawasthi1993 thanks for posting your issues/comments. Sorry I have not been able to respond as quick as I'd like. Dealing with surfaces intersecting each other, depends a bit on how you want to resolve it.

They should not intersect, the intersection is an artifact. The surfaces are just very very close normally but due to things like "noise" one protrudes through the other in some spots.

For a case like this you'd need to work to resolve the overlap first. TetGen cannot resolve it for you. TetGen can only fill well defined regions with tetrahedrons. I have had blood vessels with features intersecting in the past. To resolve it I've pushed one surface out of the way (e.g. by moving nodes in the direction opposite to the local surface normal). You can do this locally by first "detecting" the overlapped region. You can also do this iteratively with tiny steps to "push until resolved". Detecting the overlap/intersection, may require some distance computations. Let me know if you need to know more on this.

The overlap/protrusion is a real feature and I need to have a volumetric mesh incorporating this real phenomenon.

In this case you'd need to cut the surfaces with each other. You start with surface 1 that enters surface 2, but then you compute surface 3 (surface 1 inside surface 2), and also surface 4 (surface 2 inside surface 1). You then also need to remesh the intersection region to have node shared regions so the surfaces touch at nodes at the intersection. Once you have this you tell TetGen to mesh region 1 (consisting of the space in surface 1+4), region 2 (the space inside surface 3+4), and region 3 (space inside surface 2+3). Let me kwow if you need to more on this too. More information on exactly what you want is needed. And if you could share close up pictures of the issues/intersections that would help too. Hope this helps.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

[abhiawasthi1993]

Hi @Kevin-Mattheus-Moerman, thank you for the clarification. Mine is actually the first case. I am trying to mesh a full brain model wherein, firstly, I am dividing the whole brain surface into left and right hemispheres. After smoothing and correcting the surfaces, I am trying to mesh them in Gibbon. However, there are a few faces in both the hemispheres that are self-intersecting and producing the error while meshing using TetGen. Could you please have a look at the combined STL file?

[Kevin-Mattheus-Moerman]

@abhiawasthi1993 I had a look at the geometry contained in your STL file. I understand your problem now. This is not really a GIBBON issue, e.g. with TetGen. The intersections need to be resolved first. How do you currently obtain this geometry? If it is from a levelset function, you can evolve the surface, e.g. to start to small, and to grow towards the correct levelset, but have a repulsive action when the surface gets too close.

[Kevin-Mattheus-Moerman]

Here is an example, where the surfaces evolve to nearly touch but never protrude through eachother:

and for two separate surfaces, one would usually get a merged result, but through this gradient inflation approach they will "nearly kiss" but not bite each other or be merged:

Note this is novel functionality I have not added to GIBBON yet. It would only work for you if you have a levelset (e.g. a signed distance function of some sort) for the brain surface. Although it is also possible to compute a levelset for your STL geometry, but there will be some erosion of quality likely.