What I meant to say was that this CSG code isn’t ours (as far as I know), it’s a port from another library, so nobody in the team really knows about it.
If anyone’s willing to try and improve it, we’re all for it! Or perhaps a CSG v2 could also be made, if it turns out that the existing code can’t really be improved.
The problem is not the export but the CSG operation.
Just to come back to this, for non-CSG operations, do we happen to know why the problem persists for certain shapes like a simple sphere?
I opened it up to inspect what’s wrong with it, and these are the faces it’s highlighting (that need to be closed to take a positive volume):
@WarinSpace_Game
Without diving into the sphere geometry code, and it’s been a couple years since i read it, I believe it could be the edges of the geometry that is not connected.
The sphere is created like a lathe, and it looks like (on your pictures) it’s the starting and ending edges meeting and they’re not connected, the middle points where they “connect” are duplicated rather than shared.
I’m merely guessing though.
I’ll see if i have time to dig out some old geometry cleaning code later, in the mean time, give me a couple minutes and i’ll share a sphere mesh you can try (i don’t have fusion 360)
Here are three spheres you can try and please let me know how they are looking.
1’st is cleaned with a custom function (i’m not sure this will do a difference).
2’nd have just applied the forceSharedVertices function provided in babylon.
3’rd is forceShared and cleaned.
( .babylon files you can export from your environment )
spheres.zip (40.3 KB)
Can you try with an icosphere instead:
@Evgeni_Popov – The icosphere looks perfectly fine:
@aWeirdo – Sorry, I’m having a bit of a hard time loading the .babylon files at the moment (apologies for that!) - would you be kind enough to export the STLs for me to try them into Fusion? I simply use this line for the STL export:
BABYLON.STLExport.CreateSTL([mesh], true, mesh.id);
Try these 
Spheres(stl).zip (88.4 KB)
Good Good GoodLooks like everything’s right with those.
Interesting, in your environment, try adding
mesh.forceSharedVertices();
before you export the mesh, seems like it does the trick.
Thanks for sharing! I tested it out, and that does indeed help for the sphere example. Unfortunately it’s not as helpful for the boolean operations, but I’m hoping a solution for that is found soon… 
Are you able to use an icosphere instead of a regular sphere in your boolean scenario? Maybe it will produce better results, as the geometry of the icosphere is more “regular”…
Unfortunately the boolean operations (union, subtract) are problematic even with cubes alone, i.e.:
Another example: if I take 2 cubes, “entering” into each other:
And perform a boolean subtraction, I get the following shape:
I shared the resulting STL file (cube_cutout.stl.zip) with someone to inspect what might be wrong with it, and I received the following comments:
I assume the problem here is that your STL’s topology is very strange and has many open edges, overlapping faces, and vertices in the middle of edges. Opening it in Blender and moving two vertices, you can see how strange it is. The normals are also inverted, but that probably doesn’t matter. If it is loaded in PrusaSlicer (3D printing slicer), it reports 28 open edges and 60 repaired errors.
Example of a more appropriate triangulation of the same shape as generated by Blender:
cube_cutout_blender.stl.zip (463 Bytes)
Unfortunately, as mentioned above, the CSG code is something of a black box… We’d probably need another, more robust implementation to improve on the existing one.
Yup, it is not as bad for rendering but I agree it is annoying for printing 
