Slic3r: Feature Request: Try to detect/fix more common STL/Model issues

[lordofhyphens]

A question of "how far do we go to try to fix garbage models" or detect problem cases and alert the user.

• Inverted faces - see #3224 for an example
• Weird single faces - see #3560

This issue is to collect suggestions.

[Tinchus2009]

My opinion is that slic3r should stay somehow basic about this. Fixing eror in stls a lot of time is somehow that requires user intervention. For example: useing netfabb, wich could be considered a powerfull tool, like 50% of times the automatic repair scripts are not capable of completly fixing common errors in the stls and a final user intervention is required. SO I think slic3r should stay in the area of fixing common/simple errors like: manifold/not manifold, inverted faces (this can be tricky to fix sometimes), fix/invert normals as required for the user, intersecting shells. What it would be usefull would be visual warnings, so we can see in wich part of the models there are errors and that way we could more quickly see the area we need to fix. Also, related to this and takeing the #3560 as example, I have printed myself those models and remembred that I face the problem of slic3r not slicing them properly, but the problem is not slic3r but the way the models are modelled

[NateTG]

Yesterday I made an STL with 0 thickness double sided internal walls, just to see what the slicer would do. IIRC slic3r ignored them, which is a reasonable behavior. It would also have been reasonable to print the walls as single perimeters, or to reject the mesh for being malformed. Even in simple cases it's ambiguous what should happen.

[gege2b]

I think user need to be warned that his model is problematic (trying to figure out what is the problem can be great, be it's certainly a lot of work)
Make the warning more visible than actually can be a good deal (i.e. a message box, and/or a red shaded object instead of yellow, I don't know)

Slic3r can try to slice it, but the user will know that weird things COULD occurs
As @NateTG say, there are cases where a model can be fixed/interpreted in different ways, choosing one path over another will make a percentage of user to be disapointed

The goal of a slicer is to slice good STLs (and it's not always a simple thing to do), miracles is something that's not in the scope of slicer softwares

[hovissimo]

I advocate for simplicity, and not including advanced repair features.

Bad STL is a result of bad modeling, and STL repair should happen before it gets to the slicer. I think Slic3r SHOULD provide friendly, details depictions of the errors in the STL to help educate the user - but it shouldn't support anything more than trivial repair attempts (and I'd prefer not even those!).

"Fixing" STL is going to be a losing game because eventually you have to guess at what the user wants, and you can't guess right all the time. Better to not guess, and help educate the user on how to prevent the problem in the first place.

There are plenty of other slicing softwares out there that focus on holding the user's hand and trying to make the whole thing easy. As a Slic3r user, I'm much more interested in taking responsibility for my input files so that I can have a simpler, faster, and more predictable slicing software.

If we really need a repair tool built into Slic3r, perhaps the best way to accomplish that is as a plugin.

[NateTG]

Is it even possible to reliably detect malformed STL? This stl has a vertex 'kissing' the inside of one of the faces. I can imagine that the vertex changes which side of the face it's on depending on floating point stuff as it gets scaled and moved.

vertex_in_face.zip

[cerdeira]

I believe you should concentrate your efforts to produce a good and reliable sw that is able to do what it was designed for: slice objects and provide the user with the gcode file.

Warning the user of errors found and simple stl fixing would be more than enough for a regular user like me. If it needs important stl fixings thats because you need to go back and fix the design.

In my opinion it is more important to allocate resources and efforts to solve actual issues and improve support material generation.

[foreachthing]

"how far do we go to try to fix garbage models"

Nowhere. We have Blender, Meshlab, Meshmixer, etc to fix STLs. I use SolidWorks to create my models and if the STL comes out bad, then it's because I did something wrong in SolidWorks. If I get a reliable preview of the gcode, I'm good!

[TheCodeSharman]

I'm new to Slic3r and 3d printing in general so perhaps a new users perspective on this could be helpful:

The "bad mesh should be fixed" argument is very understandable. But I've also been trying to print the 3dlabprint models like #3560, and although it was possible to fix them via Blender, it was very time consuming.

My initial thought was that as a general principle, software that is tolerant to bad input is considered good design (see for example https://en.wikipedia.org/wiki/Robustness_principle). When something is brittle to the non-expert user it drives away potential new users to other software which is less brittle, so it could help Slic3r to attract more users if it is more tolerant.

But I'd understand if Slic3r's primary objective is to be a slicing engine rather than focus on usability - leaving that to other projects (e.g. Prusa Control) which could integrate a mesh fixing component.

I also appreciate the potentially massive amount of testing and rework that this could require - yes a plugin or a preprocessing tool would be a great option and this could then be used with any slicer and would keep the mesh fixing code isolated from the slicing code.

I note that even though Cura allegedly handles the 3dlabprint files in reality it struggles when multiple parts are placed on a single bed see for example https://3dlabprint.com/forums/topic/cura-doesnt-slice-with-miltiple-objects/

The immediate response is for people to blame the slicing software and go and buy Simplify3D - I know that this is totally unfair because (I imagine) the 3dlabprint STL was designed and built specifically around working in Simplify3D.

It would be really helpful if errors in the STL could be visually indicated and some pointers given as to how to fix them. Currently the non manifold wing skin is treated as a solid and the internal structure is simply removed - it was not obvious to me initially that the problem was with the mesh although a little research quickly made it clear what I needed to do to fix the mesh.

[lordofhyphens]

Limited development resources. Unless you or someone else is interested in
this problem formulation (hint: it is a really really hard problem
formulation, especially with STL meshes because they suck as a file
format), it isn't going to get done. Full stop.

If it ever did get done by a primary developer then it is either by
accident (switching to some other libraries that happen to have good repair
capabilities) or it will be after everything else is done.

Unrelated note: we do accept pull requests for useful functions. ;)

On Aug 27, 2017 10:53 PM, "Michael Sharman" [e-mail]
wrote:

I'm new to Slic3r and 3d printing in general so perhaps a new users
perspective on this could be helpful:

The "bad mesh should be fixed" argument is very understandable. But I've
also been trying to print the 3dlabprint models like #3560
https://github.com/alexrj/Slic3r/issues/3560, and although it was
possible to fix them via Blender, it was very time consuming.

My initial thought was that as a general principle, software that is
tolerant to bad input is considered good design (see for example
https://en.wikipedia.org/wiki/Robustness_principle). When something is
brittle to the non-expert user it drives away potential new users to other
software which is less brittle, so it could help Slic3r to attract more
users if it is more tolerant.

But I'd understand if Slic3r's primary objective is to be a slicing engine
rather than focus on usability - leaving that to other projects (e.g. Prusa
Control) which could integrate a mesh fixing component.

I also appreciate the potentially massive amount of testing and rework
that this could require - yes a plugin or a preprocessing tool would be a
great option and this could then be used with any slicer and would keep the
mesh fixing code isolated from the slicing code.

I note that even though Cura allegedly handles the 3dlabprint files in
reality it struggles when multiple parts are placed on a single bed see for
example https://3dlabprint.com/forums/topic/cura-doesnt-slice-with-
miltiple-objects/

The immediate response is for people to blame the slicing software and go
and buy Simplify3D - I know that this is totally unfair because (I imagine)
the 3dlabprint STL was designed and built specifically around working in
Simplify3D.

It would be really helpful if errors in the STL could be visually
indicated and some pointers given as to how to fix them. Currently the non
manifold wing skin is treated as a solid an the internal structure is
simply removed - it was not obvious to me initially that the problem was
with the mesh although a little research quickly made it clear what I
needed to do to fix the mesh.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alexrj/Slic3r/issues/3817#issuecomment-325254084, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8CvNI0JCyeQZBd7YxKsl-6E1wIE1-ks5scjmegaJpZM4Mr6Fu
.