After self-crossing optimization, a more severe optimization effect occurred.

[jiushi-ai]

Hello, I have a rather complex repair issue:

1. I performed self-crossing repair on a certain model and encountered a verification problem with the repaired results.

Below is a comparison of the model's performance before and after repair.

Image of a certain part of the model before repair:

repair after：

I have sent the repair code and STL file to the supporty email address. Could you please help me analyze where adjustments are needed in the repair process?

[Grantim]

Hello!

I suggest that you need to lower tolerance for this case:

This settings seems to work:

The artifacts you point have even lower resolution and if you want to preserve them you need lower tolerance:

---

Also, it seems that in this case it might be better to first heal jaw mesh (either local repair or auto rebuild) and engrave text to it, to avoid spoiling text small details with intrusive repair operations.

[jiushi-ai]

Hi, in the last email, I forgot to provide my healer source code.

I've resent the useful email.

Please take a look at my processing flow. It's based on your previous suggestions, and most of the flow is working well. The problem is that this model is encountering over-optimization due to the self-intersection issue.

Regarding the "to lower tolerance" parameter you mentioned, it's currently set to tolerance = 0.191, which is hardcoded, and all models in the batch use this parameter instead of having a suitable tolerance for each model.

This might be the reason. I will continue to adjust and test it according to your suggestions tomorrow.

[jiushi-ai]

hello，

you rep: {Also, it seems that in this case, it might be better to first heal the jaw mesh (either local repair or auto rebuild) and engrave the text to it, to avoid spoiling small text details with intrusive repair operations.}

Your suggestion cannot be met at the moment because the model is provided by a third party, and the text has already been embedded. Furthermore, areas lost during rebuild cannot be received (in this application scenario).

Your previous suggestion: a three-step approach (1: address degenerate surfaces without subdivision, 2: merge components, 3: iteratively repair self-intersections + subdivide degenerate surfaces), is a good idea. However, I encountered a specific model with this problem, and after testing, I found the following differences:

After testing, I found that following the previous steps to repair the model resulted in the severe deletion of a normal face. My program retrieved the following:

diagonal = mesh.computeBoundingBox().diagonal() #diagonal: 89.5010986328125
tolerance = 0.22375274658203126 # tolerance = 2.5 * diagonal * 1e-3

During the first step of repairing degenerate faces, the following code was executed:

# #fix_degeneracies by no subdivide
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)`

##

This will delete a face on the sharp corner of the logo “4”.

However, using the .meshinspector software, when loading the model, its default tolerance is 0.0886mm. Using the same parameter and executing: fix_degeneracies_no_subdivide, it won't mistakenly delete a face on the sharp corner of the logo “4”.

Therefore: My first question returns to a previous one. Based on experience, I recommend using a tolerance value of 2.5 * diagonal * 1e-3, but this has a significant impact on this model.

So, how does the .meshinspector software obtain a tolerance of 0.0886mm?

Below is a schematic diagram of the model being loaded into the meshinspector when tolerance = 0.0886mm and tolerance = 0.22375274658203126.

[Grantim]

Hello!

As mentioned here #5567 (comment) default tolarence in MeshInspector is result of voxel_size limitations:

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 MeshInspector 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.

In your case - edges on "sharp corner of the logo 4" are much shorter that bbox.diagonal()*2.5e-3 so I suggest you should experimentally find value that will work for you.

[jiushi-ai]

Hi, I understand your point, but my current approach to model repair isn't based on rebuilding Voxel. Instead, I'm fixing each issue step-by-step, so a suitable tolerance is crucial.

However, I want to automate these three steps of model repair using code iteration, using the has_issues function to check completion at each step.

So, in this process, has_issues returning "ok" indicates the model repair is complete.

The practical problem is that when I get the repaired model and run it in other software, I might still need to manually adjust the parameters. But if I interact with users, they won't know how to adjust them or what tolerance value is appropriate.

This is a dilemma.

Also, can I directly use cbrt(bbox.volume() / 1e8) to apply to the tolerance?

[Grantim]

The practical problem is that when I get the repaired model and run it in other software, I might still need to manually adjust the parameters.

I see. Unfortunately, there is no simple way to have single tolerance value for all meshes.

can I directly use cbrt(bbox.volume() / 1e8)

You surely can, but it is not guaranteed to work for all cases.

One other note - is that different software might have different algorithm for detecting issues, so if you find that something actually prevent model from printing and we don't detect( or fix) it, please let us know.

[jiushi-ai]

Thank you for your reply.

Currently, we're using these three iterative steps, and issuesFlag = has_issues(mesh, minAreaRatio, maxHolePerimeter, tolerance) to monitor the repair progress. Repair stops when has_issues = true.

After repair, the mesh is checked for self-intersections and overlaps in Magic RP, especially self-intersections. Currently, the program's repair process misses some; some faces are indeed found to be self-intersecting in Magic RP.

Furthermore, Magic RP doesn't require parameters to detect self-intersections, so it can find many. Our has_issues function has parameters, and these threshold values ​​might cause some self-intersections to be missed.

This is likely a difference in the underlying implementation between meshlib and magic RP, as magic RP doesn't require parameters.

I will post details of the issues I encounter during later testing.

Thank you.