No top layer generated...

[MartinMajewski]

Version

1.31.5

Operating system type + version

macOS Sierra 10.12.2 Beta 3 (16C48b)

Behavior

This issue relates to the stl files found here: http://www.thingiverse.com/thing:1646474

1. Starting a fresh slic3r session and loading the mentioned STL with settings seen in picture 1 everything is okay. The settings set 2 perimeters and the top layer generation goes well as seen in picture 2.

2. Rising the perimeters on 4 or more as seen in picture 3 makes the top layers in the middle of an object disappear as seen in picture 4.

3. Lowering the perimeters or changing anything else does reverse the effect as seen in picture5.

4. Starting slic3r anew with 4 perimeters set from the beginning goes well also, as seen in picture 6.

So I assume there is no problem with the model itself but with the intermediate solid layer generation routine.

[MartinMajewski]

In addition to my initial posting:

Lowering the perimeters count from 4 to 2 seems to work, but rising it up again makes the problem appear again.

The layer preview shows also the solid layer problem as seen in picture 7 and picture 7b at a layer height of 1.80 mm. Interestingly there is an opaque layer just above it at layer 2.00 as seen in picture 8

[bubnikv]

Martin,

do you see any problem, if you enable the "ensure vertical wall thickness" feature? It seems that if I enable this feature, I cannot reproduce this problem anymore. If it is so, then at least I have identified a function, where this problem happens.

Thanks, Vojtech

[bubnikv]

I went through the OSX builds and found the culprit check-in. https://github.com/prusa3d/Slic3r/commit/4460b5ce50c7160cd922972a190c27bf4381ffbd

I can reproduce it on OSX, but not on Windows. This drives me crazy. Thanks for the catch anyway.

[bubnikv]

So this bug has something to do with the technique Alessandro used to not having to restart calculation from scratch if some parameter changes. The idea is good, but the implementation has some rough edges, one of them being the way some polygonal slices are reconstructed after they were split to pieces by classification into top/bottom/inside regions. Unfortunately with the Clipper library this will never get you the initial polygon. The only real fix is to keep the initial polygon saved, or to restart the calculation from the scratch. To keep the initial polygon is also important for future parallelization.

There is a quick fix for a single extruder print settings.

[MartinMajewski]

Sorry, haven't got any notification of your response, so I missed it. The "Watching" / "Subscribe" feature of github is somehow suboptimal...

Thank you for your efforts to investigate on this on your own! 👍

I will try your quick fix as soon as a new build is available (I gave up on building slicer on my mac due to all the perl-wx-struggle).

[Sebastianv650]

I think I got the same result today with Windows. After loading the model, I changed the "Top solid infill width". After the recalculation, layers affected by this setting disappeared. Changing the width back to the orig. setting doesn't bring the missing layers back. So I deleted the model, changed the width and load it again. Now it's sliced correctly.

Model: http://www.thingiverse.com/thing:1703197

[bubnikv]

I have commited a quick fix for a single extruder no-modifier meshes case. I would like to push the release out to our customers as soon as possible, so I am considering to leave this issue open for now. With the upcoming parallelization, I will have to make more changes around the layer storage, so I would fix it along the way.

[bubnikv]

By the way, alexrj build exhibits another problem It leaves tiny tiny triangle gaps in the fill surfaces, which then cause issues with bridging for example. I believe I caused the current issue by fixing these tiny gaps, but as stated before, the real solution is to not try to reconstruct initial data from pre-processed slices as this could never be stable, at least with the Clipper library, which Sli3r heavily depends upon.

[bubnikv]

ok, so I verified that the quick fix, which is already comitted. I am happy that original issue by @MartinMajewski seems to be solved by the quick fix.

[JohnnyDeer]

This bug has already been solved. I will close this issue in framework of improving the clarity of the issues list.