Severe geometry loss when repairing Self-Intersections on embedded logo area (STL)

[jiushi-ai]

hi ,
I have an STL model with a Self-Intersections issue, as shown in the image below. The Self-Intersections triangles are concentrated in the area where the logo text is embedded in the model, as indicated by the red arrow in the image.

demo.stl.zip

 I used the local repair tool, selecting only "Self-Intersections" for repair. After the repair, I found that the triangles in the logo area were deleted, creating a large gap. This is not the repair effect I expected.

Additionally, when I used voxel reconstruction, the triangles in the logo area also showed a jagged edge, whereas they were originally straight.

My question is: what is a good way to repair the triangles in the logo area with "Self-Intersections" while maintaining the original model's accuracy and avoiding gaps or jagged edges?

Alternatively, how can I use meshlib code to repair this "Self-Intersections" issue?

I would greatly appreciate a response.

[Grantim]

Hello!

For now only voxel-based approach can guarantee full fix for self-intersections but jagged edges is price of voxelization. It is usually OK if voxel size~0.5*3d printing resolution.

While there is no perfect way to fix self-intersections for arbitrary case in this one you can use another approach:

Fixing degeneracies will lead to fix of self-intersections here but this approach is not very robust and might not work for all cases.

Make setting like this for second pass

[jiushi-ai]

Thank you for your reply.
The two-step repair method is very effective, significantly reducing the number of self-crossing surfaces and eliminating jagged edges in previously self-crossing areas.

How do I write code to implement the above two steps using meshlib Python?

However, Magic RP software still detected overlapping faces in the repaired model, as shown in the image.

[Grantim]

You can call

def fix_degeneracies_no_subdivide( mesh : mm.Mesh, tolerance : float ):
    mm.fixMultipleEdges(mesh)
    params = mm.FixMeshDegeneraciesParams()
    params.maxDeviation = 0.1*tolerance
    params.tinyEdgeLength = 0.01*tolerance
    params.criticalTriAspectRatio = 1e3
    params.mode = mm.FixMeshDegeneraciesParams.Mode.Decimate
    mm.fixMeshDegeneracies(mesh,params)

and then use iterative_repair

---

As for overlaps: we have special tool to find them

But as far as I can see they should not be an issue because they does not actually touch each other (that is why we don't detect them as self-intersections in MeshHealer)

[jiushi-ai]

Thank you!

I followed your initial two-step approach, combined with iterative repair, and achieved significant progress using Python.

However, using the test file with the parameters:
tolerance = 0.191
minAreaRatio = 0.002, after repairing the model and opening it with Meshinspector using the same parameters, all error counts were 0.

But: When I loaded the repaired model into Magic RP, I found four overlapping faces. According to Magic RP's overlapping face parameter detection rules, these spatially overlapping triangles are not uniformly arranged surfaces; they are not smooth surfaces but rather slightly concave.

You can see the following images and videos demonstrating the problem in Magic RP:

overlaps-show.zip

overlaps-show.zip

My idea is to continue further repairing these overlapping faces to make the model's surface very smooth.

What are your suggestions for solving this problem?

Additionally, I have the following ideas:

1. Based on the parameters of Magic RP, the Meshinspector or SDK functions can be used to find these non-smooth triangles (i.e., triangles that overlap in space).

2. Delete these overlapping triangles and then re-fill the holes.

3. Alternatively, there could be a projection algorithm to directly regenerate triangles based on the midpoint of the projection plane.

These three steps are my ideas for your reference. I'm unsure of their feasibility.

Looking forward to your answers.

[Grantim]

Hello!

We don't detect such issues because they does not affect printing and other algorithms. Anyway all your ideas make sense and might work out for your case.

Detecting and patching (delete + fill with new triangulation) bad areas is commonly used fix pipeline but we are not familiar with Magic RP overlap detection algorithm, so we can only guess how it works.

You can try something like this:

def isSharpFace( mesh: mm.Mesh, f: mm.FaceId )->bool:
    isSharp = False
    # detection based on MagicRP algo
    return isSharp

def isDoubleSurface( mesh: mm.Mesh, f: mm.FaceId )->bool:
    isDouble = False
    # detection based on MagicRP algo
    return isDouble

badFaces = mm.FaceBitSet( mesh.topology.faceSize() )
for f in mesh.topology.getValidFaces();
    badFaces.set(f, isSharpFace(mesh,f) or isDoubleSurface(mesh,f))

regionBDs = mm.delRegionKeepBd(mesh,badFaces)
for bd in regionBDs:
    mm.fillHole( mesh, bd[0] ) # you might want to use custom parameters or mm.fillHoleNicely

---

It seems that in this case remesh algorithm might produce good result:

# first 2 steps fix

# remesh
rs = mm.RemeshSettings()
rs.targetEdgeLen = mesh.averageEdgeLength()
mm.remesh(mesh,rs)

# fix possible issues after remesh
mesh = iterative_repair( mesh, tol )

[jiushi-ai]

Hello, your two suggested solutions are excellent.

I tried the second remesh solution, but it loses some progress, especially around the right angles of the text perforations, resulting in a rounded appearance, which is undesirable.

That's why I'm hoping to find these problematic triangles using rules, delete them, and then fill in the gaps by patching the holes.

Additionally: These issues detected by Magic RP do affect subsequent printing because these areas are very small inward-folding regions, and it's precisely because they are so small that they affect printing; therefore, smoothing them is necessary.

Also: Does our meshlib function support: judging a given triangle, finding triangles whose spatial distance to that triangle is less than or equal to a spacing parameter (e.g., 5mm) and have a certain included angle parameter (5 degrees)?

This is also my guess on the logic of MagicRP finding these problematic triangles: finding two faces that are very close in space and have a certain included angle.

Additionally, I'd like to ask: After loading a model in the Mesh Healer inspection panel of MeshSpectro, how is the "Repair Resolution" parameter obtained? Different models should have different values. How can this parameter value be obtained through Meshlib?

[Grantim]

I tried the second remesh solution, but it loses some progress, especially around the right angles of the text perforations, resulting in a rounded appearance, which is undesirable.

I see, you can try to overcome this issue by changing some parameters:

# first 2 steps fix

rs = mm.RemeshSettings()
rs.targetEdgeLen = mesh.averageEdgeLength()*0.5 # lower target edge length to preserve more detail on text area
rs.maxAngleChangeAfterFlip = math.radians(20)
mm.remesh(mesh,rs)

ds = mm.DecimateSettings()
ds.maxError = tol*0.1
mm.decimateMesh(mesh, ds) # decimate to compensate excessive subdivision 

# fix possible issues after remesh
mesh = iterative_repair( mesh, tol )

---

Does our meshlib function support: judging a given triangle, finding triangles whose spatial distance to that triangle is less than or equal to a spacing parameter (e.g., 5mm) and have a certain included angle parameter (5 degrees)?

There are this function:

MeshLib/source/MRMesh/MRMeshDistance.h

Lines 30 to 32 in ab5fd0a

	/// invokes given callback for all triangles from given mesh part located not further than
	/// given squared distance from t-triangle
	MRMESH_API void processCloseTriangles( const MeshPart& mp, const Triangle3f & t, float rangeSq, const TriangleCallback & call );

which should be available in python too

But it might be easier to play with this function parameters:

MeshLib/source/MRMesh/MROverlappingTris.h

Lines 9 to 22 in ab5fd0a

	struct FindOverlappingSettings
	{
	/// maximal distance between closest points of one triangle and another overlapping triangle
	float maxDistSq = 1e-10f; // suggestion: multiply it on mesh.getBoundingBox().size().lengthSq();
	/// maximal dot product of one triangle and another overlapping triangle normals
	float maxNormalDot = -0.99f;
	/// consider triangle as overlapping only if the area of the oppositely oriented triangle is at least given fraction of the triangle's area
	float minAreaFraction = 1e-5f;
	/// for reporting current progress and allowing the user to cancel the algorithm
	ProgressCallback cb;
	};
	/// finds all triangles that have oppositely oriented close triangle in the mesh
	[[nodiscard]] MRMESH_API Expected<FaceBitSet> findOverlappingTris( const MeshPart & mp, const FindOverlappingSettings & settings );

I'd like to ask: After loading a model in the Mesh Healer inspection panel of MeshSpectro, how is the "Repair Resolution" parameter obtained? Different models should have different values. How can this parameter value be obtained through Meshlib?

Default tolerance in MeshInspector depends on auto rebuild voxel size limits: we suggest 100'000'000 voxels for object bounding box by default: simplified formula looks like this: cbrt( bbox.volume() / 1e8 )
(I call it simplify because actual formula also checks if some dimensions of the box are degenerated)

Note: as far as auto rebuild is voxel algorithm we compute tolerance based on voxelsize in MeshInsctor but to use mesh-based algorithms one can use simpler tolerance approximation, for example bbox.diagonal()*2.5e-3. In general "tolerance" value should represent desired precision of output mesh.

[jiushi-ai]

Hello, I'm using your overlap detection function to find overlapping surfaces in the magic RP logic.
I looked at the C++ source code and have a question:
float maxNormalDot = -0.99f;
This parameter calculates the dot product of the spatial angle between two triangular faces. A smaller value indicates a smaller angle between the two triangular faces, suggesting a greater likelihood of overlap.
However, in the source code:
if ( dot( fnormal, f1normal ) > settings.maxNormalDot )
return ProcessOneResult::ContinueProcessing;

This code means that if the angle between the two faces is smaller than the preset required angle, the check is skipped, and they are not marked as overlapping.

Why is it designed this way? Is this intentional?

[Grantim]

Hello!

Yes, it is designed behavior:
if normals dot product exceeds maxNormalDot it is not considered as overlap. Default -0.99f means that faces are considered as overlaps if their normals have angle 180 +- ~8 deg

[jiushi-ai]

Hi，
I conducted a test to detect triangular faces with a dihedral angle between two faces less than 5 degrees.
So I set setting.maxNormalDot = 0.996195 (dot(5 degrees) = 0.996195). I provided a test STL file with only 4 triangular faces, overlapping in pairs. Each pair of faces has a spatial angle of approximately 4.5 degrees (and there are no coplanar or intersecting cases). Therefore, the dot product of the two triangular faces is dot(4.5 degrees) = 0.996917 > setting.maxNormalDot (0.996195). dot(4.5 deg) - dot(5 deg) = 0.000722.
Because the smaller the angle, the larger the dot product value.
This leads to: dot(4.5) > setting.maxNormalDot, which evaluates to true.
According to the current code logic:
if dt > settings.maxNormalDot:
return mm.ProcessOneResult.ContinueProcessing
overlapping = True
It returns 1, skipping directly to the next face detection, and the overlapping = True code is not executed, so overlapping remains false.
Therefore, it was not detected.

I am very confused.

[jiushi-ai]

I apologize, the description above was incorrect. The tested STL file has 4 faces, overlapping in pairs. Each pair of overlapping faces shares one common point, and they have a 4.5-degree angle between them in space.
As shown in the image below, this is actually a screenshot of the case I mentioned in my previous question. I simply extracted this particular triangular face and created four separate triangular STL files from it.

[jiushi-ai]

I guess your overlap detection method checks two triangular faces: front-to-front detection, where the normal vectors are opposite, so the dot product is negative, and the angle is within 180° ± ~8°.
My detection method checks two triangular faces: front-to-back detection, such as an intersection angle within 0-5 degrees.

If I'm guessing the situation correctly, how should I provide this parameter（for within 0-5 degrees.） if I'm still using this detection function?
Or should I rewrite the detection function code myself?

[Grantim]

It seems that to check front-to-back we need to add something like setting.minNormalDot and reverse the check to be like this:

auto dotProd = dot( fnormal, f1normal );
if (  settings.maxNormalDot < dotProd && dotProd < setting.minNormalDot )
    return ProcessOneResult::ContinueProcessing;

[Grantim]

We have just discussed this issue with @Fedr and he suggested a good way to detect such faces (detect faces with all three edges being sharp), somehow like this:

# first 2 steps fix

# find all sharp edges
creases = mesh.findCreaseEdges(math.radians(80))
badFaces = mm.FaceBitSet(mesh.topology.faceSize())

# select faces with all 3 sharp edges
for f in mesh.topology.getValidFaces():
    num = 0
    for e in mm.leftRing(mesh.topology,f):
        if creases.test(e.undirected()):
            num = num + 1
    if num == 3:
        badFaces.set(f)

# expand to nighbors
badFaces = mm.expandFaces(mesh.topology,badFaces)
# patch
regionBDs = mm.delRegionKeepBd(mesh,badFaces)
for bd in regionBDs:
    mm.fillHole( mesh, bd[0] ) # you might want to use custom parameters or mm.fillHoleNicely

Could you please give a try?

[jiushi-ai]

Okay, thank you for your continued analysis of my problem. I'll test it and get back to you with the results.