Watertight design when exporting to obj?

We created some objects, exported as OBJ files.
as we encountered some artifacts, we loaded the files into trimesh.

import trimesh
mesh=trimesh.load(r"object.obj")
mesh_is_watertight #returns false
broken = trimesh.repair.broken_faces(mesh, color=None)
len(broken) # returns 5122

The gaps seem to be in sub-mm range.

This is not in line with the claim of constructing watertight models (which I do not question). There are several possibilities how this can be interpreted:
(1) trimesh does not interpret the obj file in the same way Shapr3D writes it
(2) The export function of Shapr3D into obj has some (potentially very small) deviations.

Any suggestions what might be the reason for this behaviour and what would be a work around?
Oh, and by the way importing OBJ would be a nice feature…

Many thanks for any help and suggestions!
Franz

1 Like

Thanks for reporting this, we will investigate the issue.

Does it give you the same error if you export to binary stl?

Many thanks for the quick reaction. We will investigate this and report back!

We have now looked into this again with various tools, inter alia pyview. If I export a simple cube 1x1x1 m as obj or stl, the result is not closed on the edges. The points are very close together but do not completely match. In addition we can read values like 1e-16 where there should be zero. This might be due to improper resetting of variables or rounding errors. We can get pyview to correct the mesh and the result is a properly watertight cube. If I export a cyclinder, there is always a self-intersection which to our understanding results from the same error, as start and end points do not exactly match.
The error seems to be negligible for many uses, but if starting additional automated calculations on the corpus, this is a show stopper.
Let me emphasize that we generally enjoy the easiness of use, the ipad usage as a killer feature on-site and we are totally overwhelmed by the productivity improvement with the integration of 3Dconnexion’s hardware on Mac. So we would like to see our comments less as criticism on a high level but more as our contribution to further improvement.
Your doing a great job.

1 Like

We will look into this, but can you help us understand why 1e-16 errors matter for your use case? When you are doing this with other CAD applications, are you getting results that are more accurate than this?

We are going to run automated scripts on the models that give us (mathematically changed) features such as volume, if the model is not really watertight, this breaks. This might not be a typical application, I am aware, we’re just trying to find out what is behind it. I am not a CAD specialist, thus was a bit surprised that this is in some cases not the analytical solution but approximation. This is not a general lack of Shapr3D, but we have chosen Shapr3D because it is based on volumes, not surfaces.

Got it. Have you tried to do the same with any other solid modeler? I’d be curious what’s the quality of the output that you get from Fusion or Solidworks.

Sorry, no we did not check that. As I said, this might be a comon problem, not a specific one of Shapr3D.

Hi Frabo!
We’ve investigated the issue, and found that we can only guarantee watertightness up to 1e-8.

1 Like

Hi Andrea,
thanks for the investigation, that is highly appreciated and helps us to understand the issues.
BR
Franz