Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
2 tasks done
ebeling-rump opened this issue Oct 15, 2024 · 6 comments
Open
2 tasks done

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

ebeling-rump opened this issue Oct 15, 2024 · 6 comments

Comments

@ebeling-rump
Copy link

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

  • Project file
  • Screenshot

Version of PrusaSlicer

2.8.1+MacOS-arm64

Operating system

MacOS 13.2.1 and Windows 11

Printer model

Prusa XL 5T

@u89djt
Copy link

u89djt commented Oct 15, 2024

(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
Copy link
Author

Hey Dave,

thanks for looking into this!

Here is the original stl, exported into ASCII format:

bridging_test.stl.zip

@u89djt
Copy link

u89djt commented Oct 15, 2024

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
Copy link

u89djt commented Oct 15, 2024

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
Copy link
Author

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
Copy link

u89djt commented Oct 16, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants