STL export is buggy on merged/subtracted meshes

I used this example Playground from the docs to merge two meshes together. I then added the following line to export the combined mesh as an STL file:

var stlFile = BABYLON.STLExport.CreateSTL([mesh], true, mesh.id);

However, when loading the exported STL into a CAD tool like Fusion 360, I get a “Mesh is not closed. Mesh does not have positive volume” warning:

The playground to reproduce can be found here: https://playground.babylonjs.com/#INZ0Z0#605


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?

That’s interesting, does it happen in other programs too?

I’m the original author of the STL export but am not sure what’s up with this, I’d have to dig in a little bit.


Seems to work fine in c4d, I am not familiar with Fusion 360 though.

I would think it is because the mesh is not only the outter surface but still has triangles inside which is valid stl.

does it happen in other programs too?

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.

I do not think we have a bug at the moment as the file opens in other softwares.

I would say the required treatment is quite specific to the sofware you use.

@PatrickRyan, are you aware of good stl cleanup tools ?

You are not really doing a Boolean operation you are just merging the meshes. Have you tried doing an actual Boolean operation?

Try this instead.

1 Like

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

You are not really doing a Boolean operation you are just merging the meshes. Have you tried doing an actual Boolean operation?

Yeah, my original app code used union like your example. If I add:

var stlFile = BABYLON.STLExport.CreateSTL([mesh], true, mesh.id);

to your playground link, it still complains:

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.

1 Like

You might need to Implement your own mesh triangulation algorithm to ensure you keep a closed area.

This would be a great addition to Babylon and a PR is welcome :slight_smile:

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. :pray:

This would be a really nice addition, let s see if @PatrickRyan or @Evgeni_Popov know the same of some techniques in this space ?

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

image

However, I don’t know if this is something we can ask for contributions on since it will have ripples throughout our toolset.

1 Like

You mentioned that the sphere alone also throws an error, while a box does not.

Can you try with two box meshes merged?
Both with and without union and let us know how it goes.

I don’t think that it’s the STL file or exporter that is bugged, it could be some loose geometry in the sphere or some other funny thing going on.

:x: Complains with union:


:heavy_check_mark: Doesn’t complain with merging:


Reproduce:

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.

1 Like

it looks fine in some stl viewers I’ve tried, whereas it looks really strange in your screenshot…

It also “looks” fine for me:

I was just hovering over the “Mesh is not closed” warning icon (:warning:) 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.

Sure thing - FYI there are 4 Repair options:


They’re the following:

If I go with Stitch and Remove (default option), I get this mesh:

union_export_fusion_repaired.stl.zip (1.4 KB)

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)

Thanks for this detailed report!

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:

2 Likes

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: