Artifacts and inconsistent layers

[alranel]

Reported by @napter:

I found a similar issue where all the layers are not consistent. I'm not sure if it's the same issue, this is a weird one. Slice the model and it prints with the issues in the top right picture - missing parts of layers and extra blobs in the GCode. Then rotate the model, as you can see the orientation in the bottom set is rotated 180 degrees, and the issues go away and it slices and prints perfectly. config file and STL file

[DanielJoyce]

Shouldn't there be yellow top fill on top of the pink areas too?

[lordofhyphens]

Yellow is always perimeters. On Mar 16, 2016 11:42 PM, "Daniel" notifications@github.com wrote:

Shouldn't there be yellow top fill on top of the pink areas too?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/alexrj/Slic3r/issues/2948#issuecomment-197699186

[alranel]

This issue is still present as of current master and can be reproduced with default settings.

[alranel]

Interesting. A few edges are missing from the Voronoi diagram:

[alranel]

Simpler model that reproduces the issue: fence_cut.stl.zip SVG file of the Voronoi diagram of last layer (default settings): voronoi.svg.zip

[alranel]

Reported to the upstream maintainers: https://svn.boost.org/trac/boost/ticket/12707 I'm afraid Boost Voronoi is unmaintained. I wish @asydorchuk could take a look at those two pending bugs...

[lordofhyphens]

I can look at its usage and perhaps converting to a different library? My quick search turned up a couple other OS voronoi tesselation implementations: http://math.lbl.gov/voro++/ is one and it's BSD-licensed.

There's been some significant changes as well to the Boost build system since 1.60 IIRC, at least I had problems getting it built on Win32, I think that either the syntax changed or that building with mingw broke at some point. I will have to look at it again though to be sure.

[alranel]

That Voro++ looks even less maintained :) and it's 3D so I'm not sure it fits our environment.

I actually like Boost Voronoi because it's numerically robust, fast, nicely coded and documented, and uses our native types thanks to traits. And so far I had never found a bug :-(

[bubnikv]

The simplest polygon with nice rounded numbers to evoke such a boost::polygon::voronoi issue is the following, which I distilled from the example provided by @alranel

    {       0, 10000000},
    {  700000,        1}, // it has to be 1, higher number, zero or -1 work.
    {  700000,  9000000},
    { 9100000,  9000000},
    { 9100000,        0},
    {10000000, 10000000}

There is not much in the documentation about that, but the Voronoi library does not ensure topological correctness due to rounding of the Voronoi circle events, see https://www.youtube.com/watch?v=80kDK0VwBP4

Also there is another video by the author https://www.youtube.com/watch?v=80kDK0VwBP4&t=192s though this one does not capture slides well and I find the first one more informative, especially on the Circle event robustness.

[bubnikv]

I have created another issue with the minimal test case. https://github.com/boostorg/polygon/issues/43

Interestingly enough, the library seems to be pretty stable, the only other real issue I was able to find on the Internet is https://svn.boost.org/trac10/ticket/12067 There may be no Voronoi edges produced for the 1st and last sweep line position, which is not really an issue for Slic3r (maybe for the path planner, not for the gap fill). Other issues reported are due to intersections in the input data.

[asydorchuk]

Hi, I am going to have a look at this issue this weekend, somehow missed the initial reference back in 2016.