Any ideas? I’ve noticed this happen with both mesh merge as well as subtraction as well (on cube vs cube). It’s unclear whether the underlying STL formation code isn’t as robust or whether I should be doing something to avoid these warnings.
Interestingly, even exporting the sphere alone shows the same warning, but exporting the cube alone works fine, so it seems the issue might not be exclusive to boolean operations?
Yup, that’s how I initially discovered it, and later used a CAD tool like Fusion to inspect further. I’m using BabylonJS to send my shapes to a physics simulation engine on the backend, which reads the STLs and tries to interpret them as 3D shapes with volume etc., so it seems that it’s important for certain rules to be met for this to happen.
Fusion also loads the shape fine (like C4D), but still shows a warning despite seeming visibly reasonable. Perhaps the “buggy” parts are hidden on the inside like @sebavan mentioned? Not sure if there’s an easy way to resolve this in Babylon or not, or whether the boolean operations would have to be adjusted vs the STL export code itself.
@sebavan, I hesitate to suggest a separate cleanup tool. There are plenty of tools that can clean up or remesh, but adding another into the mix seems to complicate the original path of Babylon to physics engine as these would all be a manual process to clean up. Things like ZBrush, MeshMixer, or even Maya and Blender all have methods to re-triangulate and/or tesselate a mesh. But it does not sound like this is a viable path here.
Not sure whether the way the union boolean operation is implemented is responsible or not.
There are plenty of tools that can clean up or remesh, but adding another into the mix seems to complicate the original path of Babylon to physics engine as these would all be a manual process to clean up.
@PatrickRyan Unfortunately my backend code utilizing Babylon’s exported meshes really expects the exported STLs to be just right, so manually correcting STL issues with third-party tools isn’t really a practical option for me, I’m afraid. Perhaps there are ways to automate things a bit with scripts etc., but I’m hoping to explore whether these issues can be prevented during the Babylon mesh formation/export in the first place.
I see, I’m probably not capable of pulling this off on my own, but since this is for a commercial open-source project, I’d be more than happy to fund someone/somehow make a donation to BabylonJS in case anyone might be interested in digging into this and giving it a shot.
@sebavan, I’m not familiar with the particular algorithms for boolean, tesselation, and remeshing that we could implement. What I can say is that traditionally the act of boolean operations on meshes for export to STL for 3D printing has fallen to MeshMixer. This is a free Autodesk app that does handle booleans and the export to STL very well. MeshMixer, while still available, is retired and no longer in active production because they have replicated most of what MeshMixer did in Fusion 360 and are pushing people that way. Another package that does booleans really well is ZBrush, obviously, and their remeshing and tesselation are really powerful as well. However, none of these solutions use a browser and likely are beyond the some of the scope of what we can do.
I will say that we run into some of the same issues with the boolean operations in Node Geometry and it is a known issue that we need to improve our constructive solid geometry technique. When remeshing some boolean operations like in this example we end up with triangulations in the resulting mesh that don’t match up. You can see in this cube booleaned with two cylinders and a sphere that the original cube face was re-triangulated to have quads on half of the area vertically, and triangles radiating from a single vertex on the other half. This happens on each side of the mesh, so we are left with holes in the geometry that we can’t fix.
However, I don’t know if this is something we can ask for contributions on since it will have ripples throughout our toolset.
The CSG version seems OK, it looks fine in some stl viewers I’ve tried, whereas it looks really strange in your screenshot…
I’m not sure what the problem is with Fusion 360. Can you click on the warning and choose to repair the mesh, to see what Fusion does to make it work? Maybe that will give us some clues as to what’s wrong.
I was just hovering over the “Mesh is not closed” warning icon () which highlights the problematic mesh regions in blue that it’s asking us to repair. In the screenshot below, it states that the issue is 4 open boundaries and 4 self intersections.
Can you click on the warning and choose to repair the mesh, to see what Fusion does to make it work? Maybe that will give us some clues as to what’s wrong.
While the triangles don’t look identical to Babylon’s merged (not union’d) mesh, the STL no longer complains and my backend physics engine likes it (unlike Babylon’s union outputs).
Babylon’s problematic export of what I gave Fusion to repair for reference: union_export.stl.zip (1.3 KB)
The problem is not the export but the CSG operation. The problem is that we have no way of influencing what CSG produces, it’s a kind of black box. I suppose we’d need a “repair” step like in Fusion 360… This page lists a number of resources, it might be a good start for someone who wants to tackle the problem:
The problem is that we have no way of influencing what CSG produces, it’s a kind of black box.
Why is that? The subtract CSG code for example seems to be here, which seems to originate from csg.js. Note that this file hasn’t been maintained for 12 years. Perhaps there’s some room for improvement?
I suppose we’d need a “repair” step like in Fusion 360…
I tried Fusion and MeshFix (which also happens to be on the link you sent), and they work OK for union’d Babylon meshes, but not very well for subtract’d meshes. I feel that trying to repair a poor mesh caused by an improper CSG algorithm isn’t an ideal solution, and will often not give very accurate results; just a guess of what the mesh should look like according to the repair algorithm.
Perhaps it might be easier to investigate whether the CSG boolean operation algorithms could be improved, or what exactly is causing those triangulation issues.
Some links on constructive solid geometry (CSG) and binary space-partitioning (BSP) trees in case anyone’s curious to understand how Babylon’s boolean operations are supposed to work:
Complains with union:
Doesn’t complain with merging:
) which highlights the problematic mesh regions in blue that it’s asking us to repair. In the screenshot below, it states that the issue is 4 open boundaries and 4 self intersections.
