CSG Operation Artifacts causing Errors During Slicing

[adamjvr]

Description of the bug

This model is causing slicing problems as seen in the screen shot https://cults3d.com/en/3d-model/home/skully-animatronic-skull

Screen shot:

I believe this is being caused by degenerate 0 area and the models having triangles in them which is a mathematical artifact of CSG operations.

Project file & How to reproduce

The Skull 3D object file found in this download is what's causing it https://cults3d.com/en/3d-model/home/skully-animatronic-skull

Checklist of files included above

• [ ] Project file
• [ ] Screenshot

Version of PrusaSlicer

2.60 Stable release

Operating system

Windows 10 latest updates

Printer model

Prusa MK3S+

[adamjvr]

This bug effects a huge amount of models, Cura doesn't have this problem but it lacks all the features that PrusaSlicer has, it would be wise if this bug was fixed in PrusaSlicer ASAP !

[FidelCapo]

This model is heavily broken. Slicer reports 2940 open edges and unfortunately it can't fix them by itself. But you can use "Fix through the Netfabb" on Win by right clicking on the model. After this fix, the object will slice correctly. I attach the fixed model. skull.zip

[JansenSmith]

PrusaSlicer lacking a compatibility layer to handle these sorts of models has also impacted my uploads. It'd be really nice if open edges could be handled natively.

[adamjvr]

Upon further inspection it appears Netfabb may have introduced more issues with the model, it won't sit flat on the print bed no matter what bottom surface is selected using the lay flat function. Further more its bad practice in terms of open source and free software ethics for the solution to the problems being Netfabb an Autodesk product.

[madhephaestus]

Hey there all!

I am happy to finally see this serious bug in PrusaSlicer addressed!

I am the developer of BowlerStudio, and the JavaCAD kernel that performs CSG operations in Java. I have observed this issue on nearly all of my CSG outputs and I actually know specifically what the issue is, and why this MUST be fixed in the slicer and can not validly be addressed by "mesh fixing" software.

Here is a perfectly cromulent STL file produced by pure CSG operations with no STL import from any Mesh-based artistic modelers nor any 3d scans. In this release, "BaseCone.stl"

https://github.com/Halloween2020TheChild/GroguMechanicsCad/releases/download/0.5.0/hephaestus-archive-0.5.0.zip

this part is sliced by Cura without issue or modification. PrusaSlicer fails by producing missing layers in the slice.

Now, lets discuss what is happening here, and why this happens to most if not all CSG systems (BowlerStudio, OpenSCAD, some fusion360 and tinkercad files as well). CSG operations can result in "degenerate triangles" AKA zero area triangles, AKA 3 collinear points in a polygon object. Per the STL spec this is "invalid", sure. BUT to fix this in the STL produces an STL that is now no longer water tight. That means the "fixed" STL's can not be imported by any software as a valid mesh for further CSG operations.

To say this should be fixed in the modeler (Despite Cura fixing this in-line) means the modelers can not produce artifacts that they themselves can import and work with. Therefor this correction layer should happen within the memory space of the Slicing system. To produce any artifact that had degenerates pruned would produce an invalid intermediate file that will then poison any CSG operation that ingests it.

This error is clearly and consistently demonstrable in PrusaSlicer, and totally absent from Cura.

Because of this bug, I have never been able to use PrusaSlicer in my production workflow. I would prefer to use PrusaSlicer with my Prusa mk3+'s, but for now i am entirely dependent on Cura.

[madhephaestus]

@supermerill You fixed #252 do you have any insight on this bug?

[madhephaestus]

This model is heavily broken. Slicer reports 2940 open edges and unfortunately it can't fix them by itself. But you can use "Fix through the Netfabb" on Win by right clicking on the model. After this fix, the object will slice correctly. I attach the fixed model. skull.zip

@FidelCapo per @adamjvr 's comment, using proprietary software is not acceptable under any circumstances, much less a solution. Especially when the provider is Autodesk. Absolutely unacceptable as a solution.

[madhephaestus]

I have compiled prusa-slicer from source at

commit 1a4a31e92992090948e64984479388d47797142e 

and have confirmed this bug exists in the current head of master as build from source.

[adamjvr]

This Ghost model found here causes the same failure mode/problems when slicing in spiral vase mode https://cults3d.com/en/3d-model/art/ghost

[adamjvr]

This paid model also causes the same failure mode https://cults3d.com/en/3d-model/art/3d-guitar-pedal-storage-box-alexaldridge

Netfabb can't fix this model without ruining it and making it unusable, it fills in open features. Netfabb can't even perform the fixes that it states it can and often introduces additional defects and problems that were no present with the original model.

[lukasmatena]

@madhephaestus @adamjvr

CSG operations can result in "degenerate triangles" [...] Per the STL spec this is "invalid", sure. [...] the "fixed" STL's can not be imported by any software as a valid mesh for further CSG operations.

I am sorry, but I don't follow the logic. You are basically saying that you know that the model is broken and not according to specs, but because you can only work with such broken models, you require others to "fix it" in their software. That is quite unorthodox. The fact that CSG operations are very difficult to do robustly does not change the fact that the resulting STL is not manifold.

Now let's have a look from slicer's perspective. Slicer cuts all the edges and extracts closed contours. If the mesh is not manifold, it cannot do it. It has no idea what are mistakes that should be removed, and which points it should chain artificially and in which direction. In these cases, slicers use some heuristics and guess what the ambiguous input was supposed to mean. Depending on the model, the result may be better or worse. When I explode your model in 3D-Tool Viewer, it is clearly seen how very "invalid" the model is, and quite clearly the heuristics in PrusaSlicer were unable to guess what the author intended.

This error is clearly and consistently demonstrable in PrusaSlicer, and totally absent from Cura.

That only means that in the case of this particular model (or a class of models), Cura's heuristics were better. With a different model, PrusaSlicer would "fix" it and Cura would miss layers. And Cura developers would tell you that your model is broken. See https://github.com/Ultimaker/Cura/issues/13467 or https://github.com/Ultimaker/Cura/issues/15514 where exactly that happened. We are trying to make PrusaSlicer able to slice even mangled geometries, but people don't realize that these STLs are actually missing information critical for the slicing process and that the "fix" that you require us to do is more or less a guessing game.

Netfabb can't fix this model without ruining it and making it unusable, it fills in open features.

The algorithm fills the open features, because it connects the stray edges in wrong direction. The contour has to be either cw od ccw and it can only choose one of them. There is not a reliable way to fix a model once you break it, and if you break it enough, even very good algorithms will not get it right.

using proprietary software is not acceptable under any circumstances, much less a solution. Especially when the provider is Autodesk. Absolutely unacceptable as a solution.

I understand, however in this case the problem is actually in the UI. Before NetFabb was acquired by AutoDesk, there was a free cloud service that was quite widely used in 3D printing community. In reality, PrusaSlicer does not use NetFabb for a long time, it actually uses this API provided in Windows SDK. The labels in the menus are what is incorrect, and they have been for a long time. We will fix this in the next release, thanks for pointing it out.

[madhephaestus]

Cura's heuristics were better. With a different model, PrusaSlicer would "fix" it and Cura would miss layers.

Can you show me an example of a model that slices correctly in PrusaSlicer but does not slice correctly in Cura (demonstrating its a trade off, as opposed to a bug in Prusaslicer)?

I downloaded the models from the 2 examples you gave and both of those models DO slice correctly in the binary release of Cura 5.4.0 . (Both of those issues are stale and should be closed, the current release of Cura does not have problems with either file)

The first example fails in PrusaSlicer, but the Dice Tower works is Prusa and Cura. I am not sure what these examples are meant to illustrate, as these examples actually seem to reinforce this issue.

Can we just add the heuristics from Cura to make PrusaSlicer better? Or is this failure mode a choice that is maintained to teach us CSG developers a lesson?

I am not demanding someone else do work that I can do, i am happy to dive in and help. I think, however, step one should be the core developers acknowledging this bug.

WRT the manifold nature of the STL, the STL i provided contains the zero area triangles and IS manifold, until the zero area triangles are removed, leaving a non manifold shape that can be exploded. I suspect 3d-tool-viewer is doing just that. I have only Ubuntu machines, so i can not run that tool to confirm.

actually uses this API provided in Windows SDK.

So does that mean that PrusaSlicer is not feature complete on Ubuntu/MacOS systems?

[madhephaestus]

@lukasmatena

The contour has to be either cw od ccw and it can only choose one of them.

This my be somewhere I can Help! I had a similar problem in JavaCAD just this past year so i am spooled up on the problem and its solution.

I had run into a problem that boiled down to this failing for some polygons based on how the polygon is oriented. I used the normal of the plane to reorient the whole polygon to the xy plane for processing, then transform the result back into place.

https://github.com/NeuronRobotics/JCSG/blob/development/src/main/java/eu/mihosoft/vrl/v3d/ext/org/poly2tri/PolygonUtil.java#L128

through

https://github.com/NeuronRobotics/JCSG/blob/development/src/main/java/eu/mihosoft/vrl/v3d/ext/org/poly2tri/PolygonUtil.java#L232

This resulted in the edge case polygons (ones that allign up and down, or in some other way tries to run the manifold detection and it fails) were able to be processed and for the CSG operation to continue without fault.

[lukasmatena]

Can you show me an example of a model that slices correctly in PrusaSlicer but does not slice correctly in Cura

I just tried the project from https://github.com/Ultimaker/Cura/issues/15514 and it failed for me in Cura 5.4.0, while it sliced without apparent errors in PrusaSlicer 2.6.1. I don't have time to check whether it changes with configuration. But the main point was that the impression that evil PrusaSlicer developers decided "not to fix it to teach CSG developers lessons" (???) is invalid, because exactly the same issues as this one are reported for Cura.

the STL i provided contains the zero area triangles and IS manifold, until the zero area triangles are removed, leaving a non manifold shape that can be exploded. I suspect 3d-tool-viewer is doing just that.

Please, open your STL in any mesh inspecting software instead of suspecting. Below is a screenshot from MeshMixer. If you want to claim that the mesh is manifold, there is probably nothing more to discuss.

So does that mean that PrusaSlicer is not feature complete on Ubuntu/MacOS systems?

It means that the (very good) mesh fixing algorithm is only available on Windows.

I used the normal of the plane to reorient the whole polygon to the xy plane

That's not what I meant. The polygon I was talking about is already in 2D, it is the result of slicing. Solid contours and holes are distinguished by its orientation.

[madhephaestus]

It means that the (very good) mesh fixing algorithm is only available on Windows.

Ah. ok, i guess that is nail in the coffin for me. I run only linux machines in my computer lab. I was hoping to someday use PrusaSlicer, but as you indicated, it is dependent on a proprietary Windows API.

[madhephaestus]

I suggest marking this issue as "wont fix" and amending the documentation to remove any reference to "FOSS", and removing references to it working on non windows systems. PrusaSlicer is apparently an extension of the Windows 3d printing API and is not fully functional without that proprietary blob.

For those that care about source access, it looks like Cura is the only option. Cura is the only fully functional cross-platform open FOSS slicer.

I am very disappointed in PrusaSlicer.