Vase mode not working for objects with "islands" inside

[KissmanCZ]

Version

1.41.0+win64

Operating system type + version

Win 10 64b

Behavior

Vase mode not working for objects with "islands" inside

Expected:

Actual:

STL/Config (.ZIP) where problem occurs

stl.zip

[Sebastianv650]

Vase mode is per definition a print mode which only has one start point of extrusion and one end (except solid first layers). So you can't use vase mode for models like that with islands.

Which plane are you printing? Just curious as I'm also flying printed planes.

[KissmanCZ]

First (expected) screenshot is vase mode too! S3D can slice this properly in vase mode.

[supermerill]

Something like that? (available in my fork if you enable the "looping perimeter" parameter, but the "connection" will not be extruded, it's only a "travel move").

Note: a seam will be visible, it's impossible to avoid it, even with s3D.

[KissmanCZ]

Yes, something like this, but actually i need extrusion over "connections". Seam is expected. Here is photo from S3D printing...

[bubnikv]

BTW what is the benefit of such a print compared to the normal print?

…

On Mon, Oct 29, 2018 at 1:34 PM Jan Pichrt ***@***.***> wrote: Yes, something like this, but actually i need extrusion over "connections". Seam is expected. Here is photo from S3D printing... [image: img_0974] <https://user-images.githubusercontent.com/13331823/47650013-3ae1b480-db7f-11e8-9c64-7ce2f1072f2d.jpeg> — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj5I0dMaHgcIh3XoZidq4BfkCz7X2zPks5upvXYgaJpZM4X-DFY> .

[KissmanCZ]

Speed & quality

[supermerill]

I think what KissmanCZ want is the option to have the holes joined with the shell by the perimeter when infill is set to 0%.

[KissmanCZ]

And basically, it is simple vase mode... just with "shape"...

[supermerill]

The "vase" has a specific feature : increase the Z gradually to avoid seam. You don't need that, you can just put infill to 0% , 1 perimeter and no top layers.

[KissmanCZ]

There will be seam, lot of retraction problems and very slow printing speed...

I have no my Slicer with me now, so please excuse my bad drawing skill but what is wrong to do vase with this shape? It is one line without interruption.

btw. Cura can slice this correctly too (tested yesterday).

[supermerill]

The problem is, i think, you don't need the vase mode, as you don't want to avoid a seam.
You want 1 perimeter, no top, no infill, and a looping perimeter that join with inner holes, right?

[KissmanCZ]

Basically yes, you are right. But power of vase here is faster print speeds and less quality issues. Standard printing layer by layer with 1 perimeter is very settings sensitive.

[KissmanCZ]

And as second, is seam and seam :) seam in vase mode (in this model) is created by horizontal connect betwen same layer and because space betwen cut out is so small by design. Seam in standard print without vase mode is created by horizontal AND vertical connect betwen two different layers.

[Sebastianv650]

@KissmanCZ I had a deeper look into your stl and I now understand your point and also the confusion here.
What we don't know was that there is a intended connection between the outer shell and the "pipes" inside it inside the stl. Instead, it looked like the conections are some "he wants vase mode, so we do some magic things to make it possible" modes of other slicers.

A Meshmixer screenshot with a plane cut should make it obvious:

The "thickness" of this gap is 0.05mm if I measured it right. Slic3r seems to ignore this tiny gap during the slicing process. So yes, I would say that's a "bug" but most likely due to some repair functions?

[Sebastianv650]

If this is self-disigned, can you increase the gap to 0.1mm for testing purposes?

Edit: I tested this by scaling the model. Slic3r generates the right geometry if scale is 200% or bigger.

[KissmanCZ]

Sorry, not my design :( is possible to increase "resolution" of Slic3r for this? Probably as "improvement" or "feature request"?

[bubnikv]

Now I understand, the connection line is already there in the model. This is really a duplicate of
#520

[Sebastianv650]

I need to print an stl where I run into the exact same problem as @KissmanCZ here. I will try to compile with the value lowered, but if we realy need this check a configurable value would be nice.

[KissmanCZ]

Any news regarding this @bubnikv ?

[Sebastianv650]

As @bubnikv stated today, there are a lot of issues and only a limited number of people at Prusa who can work on them. Maybe we can make this issue a little bit more "attractive" to them by providing more data or a possible solution.

I did a bit of research, this parameter was added to fill tiny holes in the walls of stl files which otherwise would lead to errors in the slicing process. But it looks like a not so perfect solution, as it's value was only lowered along time, and every "auto closing" function will ruin delicate files which have such features intentionaly.
Most information about it can be found here: slic3r/Slic3r#959

As Cura doesn't use such a repeair function at all and it's working fine for the users, I would tend to remove this parameter completely. Especialy as it's not doing what it was intended for in the beginning: Closing small holes in stl shells. It's instead also deleting geometry in perfect watertight stl files.

Or maybe they are able to fix the compile problems on Windows first, with a working compile howto it would be easy to change that on our own.

[supermerill]

Or maybe they are able to fix the compile problems on Windows first, with a working compile howto it would be easy to change that on our own.

I can compile in windows. If you tell me what line to modify, i can build a fork and say here how to get it.

[Sebastianv650]

@supermerill that would be great!
Inside /src/libslic3r/TriangleMesh.cpp, line 1584:
double safety_offset = scale_(0.0499); needs to be commented and line 1586 needs to be uncommented (double safety_offset = scale_(0.0001);). Or just change the value without commenting / uncommenting.

[bubnikv]

thanks, reference to the original issue that triggered implementation of the "closing" operation certainly helps. We have changed the slicing logic a lot this year towards robustness in handling meshes with cracks, so we may remove this hole closing heuristics, which will also make the slicing process a bit faster. Food for thought.

…

On Tue, Nov 27, 2018, 18:32 Sebastianv650 ***@***.*** wrote: @supermerill <https://github.com/supermerill> that would be great! Inside /src/libslic3r/TriangleMesh.cpp, line 1584: double safety_offset = scale_(0.0499); needs to be commented and line 1586 needs to be uncommented (double safety_offset = scale_(0.0001);). Or just change the value without commenting / uncommenting. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFj5IzzNrqcg1y8oIFV4wY8AIW_p92tdks5uzXcmgaJpZM4X-DFY> .

[supermerill]

@Sebastianv650 you can download it in my fork (https://github.com/supermerill/Slic3r), the latest release.

warn: This fork isn't supported by prusa, it's my own personal initiative (me as a random guy in internet). If you encounter a bug, please report it on the fork's issue tracker, not here.

[Sebastianv650]

@supermerill I tried you version and it works perfectly! Thank you very much!
I see there are some more intresting new features and modification in this fork 👍

[KissmanCZ]

@supermerill thanks :) it works perfectly... can I contact you directly? I have another "idea" regarding vase mode (need to have option to print bottom layers in vase mode only on bed and not in "air").

[supermerill]

@KissmanCZ you can open an issue in my fork.

[bubnikv]

By the way, I have introduced a new parameter "slice_closing_radius", which is set to 0.049 by default, leading to the same results as in 1.41.3. If you need to maintain the thin gaps, starting with Slic3r-1.42.0-alpha7 you will need to lower the new "slice_closing_radius" value.

Implemented with e3cba0a

This parameter and the return to the 1.41.3 behavior by default was made as we have discovered some models with cracks, which were handled correctly by 1.41.3, but which were full of spurious perimeters in 1.42.0-alpha5. We find it safer to revert to the 1.41.3 behavior while giving you the parameter to tinker with.