prusa3d / PrusaSlicer

G-code generator for 3D printers (RepRap, Makerbot, Ultimaker etc.)
https://www.prusa3d.com/prusaslicer/
GNU Affero General Public License v3.0
7.74k stars 1.93k forks source link

Large hole in part ignored (auto-fix issue?) #13488

Open ebeling-rump opened 4 weeks ago

ebeling-rump commented 4 weeks ago

Description of the bug

This stl file contains a large hole:

Screenshot 2024-10-15 at 11 37 32

However, when importing into PrusaSlicer, this hole is ignored: Screenshot 2024-10-15 at 10 35 47

This can also be seen when performing a cut through the part: Screenshot 2024-10-15 at 11 34 17

In other slicer, namely Simplify3D and Cura this seems to work. Screenshot 2024-10-15 at 10 23 41

Screenshot 2024-10-15 at 10 22 40

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.

Screenshot 2024-10-15 at 11 52 23

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

u89djt commented 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: image 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.)

ebeling-rump commented 4 weeks ago

Hey Dave,

thanks for looking into this!

Here is the original stl, exported into ASCII format:

bridging_test.stl.zip

u89djt commented 4 weeks ago

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.

u89djt commented 4 weeks ago

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.

ebeling-rump commented 3 weeks ago

Very interesting! I could reproduce this behaviour with Meshmixer.

Screenshot 2024-10-16 at 22 27 33

When exporting the meshmixer stl in ASCII format and comparing it to the original, it seems like Meshmixer did a few different things:

Screenshot 2024-10-16 at 22 30 09

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

u89djt commented 3 weeks ago

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