Open ebeling-rump opened 4 weeks ago
(fellow user following the hub) I imported your 3mf into fusion to look at it. If I export that mesh to an stl and try to slice it in your project file or into a fresh instance of the slicer, I get the same result as you. If I convert it to a brep body, then back to mesh and loaded that into your project, I get a successful slice: I appreciate that I've demonstrated that the problem between the mesh and the slicer survives coming out of your project file, but If you can post the original stl, and there's a difference between them, we know that the difference isn't the problem, which narrows the search. (The original stl has characteristics A and B, where A is the problem for prusaslicer and B might be something or nothing, and the one in the project file may have characteristics A and C, where C may include some of B. If they're different in any way, that could be helpful.)
Hey Dave,
thanks for looking into this!
Here is the original stl, exported into ASCII format:
At this point, I'm stumped. Will probably look again at some point. In the meantime, if you can describe your software and processes chain that got you to your 3mf file, someone might recognize it. Your point about the automatic repair the slicer shows with a warning triangle seems important.
If you import your stl into meshmixer and then export it immediately, that new stl imports into the slicer and gives an object with the hole. So meshmixer disliked something in the mesh and fixed it, and made prusaslicer happy, too. meshmixerrepair.zip Loading to meshmixer then exporting the mesh from your original 3mf file does not make the hole reappear.
Very interesting! I could reproduce this behaviour with Meshmixer.
When exporting the meshmixer stl in ASCII format and comparing it to the original, it seems like Meshmixer did a few different things:
1) rounded floating point numbers 2) turned floats into integers wherever possible 3) added indentation 4) changed all normals...
I'm not quite understanding the changed normals. For the first facet all vertices are at the same height z=4. Therefore I'd expect the normal to be pointing upwards, i.e. (0,0,1), but it is pointing into the y-direction with (0,1,0).
I guess it ingested the original file into its own binary data structures, and that's it's standard output format? The normals - no ideas yet. At face value (aha) they're nonsensical, but here we are with a working mesh...
Description of the bug
This stl file contains a large hole:
However, when importing into PrusaSlicer, this hole is ignored:
This can also be seen when performing a cut through the part:
In other slicer, namely Simplify3D and Cura this seems to work.
Could this be related to PrusaSlicer auto-fixing and thereby filling the hole?
I've checked the normals of the hole and they are pointing towards the inside as expected.
Project file & How to reproduce
bridging_test.3mf.zip
Checklist of files included above
Version of PrusaSlicer
2.8.1+MacOS-arm64
Operating system
MacOS 13.2.1 and Windows 11
Printer model
Prusa XL 5T