skin thickness and transition layer between infill and solid

[BillyQuiet]

I use 1.2.6 and I am quite satisfied but why not add two (very) useful functions ?

1 - skin thickness (as in kisslicer and others) to avoid the weakness especially at the top of spherical shapes

2 - Addition of a layer between infill and solid as a layer of denser infill, a kind of transition layer ( as in kisslicer)

If this has already been asked or has nothing to do there, thank you to delete the message or ignore

Sorry i'm fench and i do not speak English very well even with the help of google :)

[lordofhyphens]

"Do it like XXXX" isn't a reason to implement something. Unless you're programming it yourself, a strong reason for implementing a feature is necessary.

Also, the thickness of perimeters is controllable in Advanced options, or you can increase the number of shells in Print Options.

2) What problems does this solve? Need concrete examples of problems that are would be fixed by this.

[BillyQuiet]

I understand your answer, and unfortunately I do not program myself :( I referred to Kisslicer because I also use it and find that it manages well these two aspect

1 - Skin thinkness:

I know that Slic3r add permetres where it is needed, but I find that it is not enough sometimes. I know I can put ten or more perimeters but throughout the parts, even when there is not strictly necessary. (see photo)

2 - transition layer between infill and solid:

I know I can add solid layers at the top. With a slight infill when we move to solid layer it may causes defect on the surface.I have already 4 layers on top (see photo)

I realize that may also be due to misconfiguration of my printer or my parameters in slic3r.

In conclusion I made these proposal if a programmer of this project does not know what to do more, which I doubt :)

[alranel]

Shell thickness expressed in mm is just a different way for setting the number of perimeters (which is an option in Slic3r) and top/bottom solid layers (which is a pair of options in Slic3r). Setting shell thickness as millimeters or as number of traces produces the same effect.

Slic3r treats the first solid layer above sparse infill as a bridge layer, so it already has special handling for that case. You are supposed to set more than a single top solid layer. Using just one top solid layer produces bad quality. If you set at least 2, the first one above infill will be printed as a bridge.

[BillyQuiet]

thank you for your reply.

I will review my settings for number 2 I am pretty sure my issue it comes from the bridge layer parameter or my printer

Slic3r has many more parameters than Kisslicer but slic3r has not (to my knowledge) skin thickness parameter / feature which is different from the numbers / thickness perimeters (please see image attached for exemple)

I know this is a very hard work that has been done and I thank you all

[alranel]

You didn't read my previous message carefully. I'll paste it again and highlight the part you missed:

Shell thickness expressed in mm is just a different way for setting the number of perimeters (which is an option in Slic3r) and top/bottom solid layers (which is a pair of options in Slic3r).

[bubnikv]

Shell thickness expressed in mm is just a different way for setting the number of perimeters (which is an option in Slic3r) and top/bottom solid layers (which is a pair of options in Slic3r).

Not exactly. Slic3r "extra perimeters" adds some full perimeters to the print. For some objects, it may be ok, for some objects this may not add enough of vertical wall thickness to close the top surfaces. Also if the slope varies along the perimeter, this feature adds too much material at the non-sloping side of the perimeter.

Cura, Kisslicer or Simplify3D handle the vertical wall thickness differently by placing a solid zig-zag infill. This ensures the vertical wall thickness while adding a minimal amount of excess material with the downside of introducing resonances into the machine as it tries to do the zig-zag movements. I have implemented this feature into the Prusa3D fork, it could be enabled by checking the "ensure vertical wall thickness" check box. It certainly works.

Slic3r treats the first solid layer above sparse infill as a bridge layer, so it already has special handling for that case. You are supposed to set more than a single top solid layer. Using just one top solid layer produces bad quality. If you set at least 2, the first one above infill will be printed as a bridge.

I love the way Kisslicer handles the top layers over infill as well. I plan to implment this into the Prusa3D fork. It is a one line change to set the bridging over infill spacing to 50%. I believe this makes a lot sense, because the bridges are drawn more reliably if the threads don't touch. I would rather do this in an extra layer though.

[BillyQuiet]

HI, Happy to read your message. I expect the next release :) (because I am unable to compile anything)

Thank

[lordofhyphens]

As I've said repeatedly, https://bintray.com/lordofhyphens/Slic3r/slic3r_dev has Windows builds of the current latest -dev for Slic3r.

https://bintray.com/lordofhyphens/Slic3r/Slic3r_Branches contains proposed additions to Slic3r (pull requests).

"Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

On Wed, Oct 26, 2016 at 3:21 PM, BillyQuiet notifications@github.com wrote:

HI, Happy to read your message. I expect the next release :) (because I am unable to compile anything)

Thank

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/2750#issuecomment-256465471, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB8CrAp3xOZTV15cwKh7qkvo-DwbZRGks5q37ZQgaJpZM4DxqAA .

[bubnikv]

As I've said repeatedly, https://bintray.com/lordofhyphens/Slic3r/slic3r_dev has Windows builds of the current latest -dev for Slic3r.

but the feature @BillyQuiet is waiting for is not in the @alexrj slic3r, only in the Prusa3D fork.

[lordofhyphens]

I'd be interested in having the bridging over infill as an option myself (50% or 100%).

Although I think the advanced UI needs an overhaul and/or submenus.

"Nothing unreal exists." - Kiri-kin-tha's First Law of Metaphysics.

On Wed, Oct 26, 2016 at 12:47 PM, bubnikv notifications@github.com wrote:

Shell thickness expressed in mm is just a different way for setting the number of perimeters (which is an option in Slic3r) and top/bottom solid layers (which is a pair of options in Slic3r).

Not exactly. Slic3r "extra perimeters" adds some full perimeters to the print. For some objects, it may be ok, for some objects this may not add enough of vertical wall thickness to close the top surfaces. Also if the slope varies along the perimeter, this feature adds too much material at the non-sloping side of the perimeter.

Cura, Kisslicer or Simplify3D handle the vertical wall thickness differently by placing a solid zig-zag infill. This ensures the vertical wall thickness while adding a minimal amount of excess material with the downside of introducing resonances into the machine as it tries to do the zig-zag movements. I have implemented this feature into the Prusa3D fork, it could be enabled by checking the "ensure vertical wall thickness" check box. It certainly works.

Slic3r treats the first solid layer above sparse infill as a bridge layer, so it already has special handling for that case. You are supposed to set more than a single top solid layer. Using just one top solid layer produces bad quality. If you set at least 2, the first one above infill will be printed as a bridge.

I love the way Kisslicer handles the top layers over infill as well. I plan to implment this into the Prusa3D fork. It is a one line change to set the bridging over infill spacing to 50%. I believe this makes a lot sense, because the bridges are drawn more reliably if the threads don't touch. I would rather do this in an extra layer though.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/2750#issuecomment-256425093, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB8CiB7VS2HVnIb84o0sLUtOiy7kEKcks5q35I3gaJpZM4DxqAA .

[lordofhyphens]

Fair enough, it has been a hectic week. I look forward to getting this work prepared for merge On Oct 27, 2016 10:45 AM, "bubnikv" notifications@github.com wrote:

As I've said repeatedly, https://bintray.com/lordofhyphens/Slic3r/slic3r_ dev has Windows builds of the current latest -dev for Slic3r.

but the feature @BillyQuiet https://github.com/BillyQuiet is waiting for is not in the @alexrj https://github.com/alexrj slic3r, only in the Prusa3D fork.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/2750#issuecomment-256683018, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB8CsTVdw8C82f0K-4vka8I_JEuA5woks5q4MckgaJpZM4DxqAA .

[alranel]

@bubnikv, I'm not sure I understand the "ensure vertical wall thickness" thing.

Unless there are bugs, the current Slic3r implementation ensures that:

• for every ray intersecting the object along the X and Y axes, there are at least the configured number of perimeters forming a solid shell;
• for every ray intersecting the object along the Z axis, there are at least the configured number of solid top/bottom layers forming a solid shell.

(There's no check for diagonal rays.)

How does your "ensure vertical wall thickness" alter this behavior?

[bubnikv]

for every ray intersecting the object along the Z axis, there are at least the configured number of solid top/bottom layers forming a solid shell.

This is supposed to be ensured by the extra perimeters, but it cannot work reliably. First, the number of extra perimeters is limited, second the extra perimeters are drawn only if they are required for a fraction of the full perimeter length. Even if the extra perimeters are used to ensure the vertical shell thickness, they are drawn over the complete perimeter length, therefore adding extra weight and consuming unnecessary material.

The "ensure vertical wall thickness" I have implemented and our customers are happily using, ensures the vertical wall thickness always, with the disadvantage of adding zig-zag shaking movement to the prints and sometimes causing the print head to move over the overhangs too often, re-heating the print. Currently one has to choose between the two bads. Ideally the software would use partial perimeters instead of the zig-zag infills wherever possible.

[alranel]

This is supposed to be ensured by the extra perimeters

Not true. This is unrelated to extra perimeters. Even if you disable extra perimeters, Slic3r generates solid rectilinear regions whenever necessary to ensure that at least the configured top/bottom solid layers are crossed by any Z ray.

(Extra perimeters are an optional optimization which replaces those rectilinear regions with linear extrusions -perimeters- whenever they're too narrow and would shake the machine.)

So my question is: how does your "ensure vertical wall thickness" alter the default behavior of Slic3r? (i.e. without extra perimeters)? Did you ever find a failing case where the following statement is not true?

for every ray intersecting the object along the Z axis, there are at least the configured number of solid top/bottom layers forming a solid shell

[lordofhyphens]

The previous implementation of extra perimeters was broken; there was an infinite loop because the wrong variable was used when it was ported to C++.

I suggest re-evaluation (assuming you didn't also notice this bug and fixed it on your end separately), although the criticism of extra material would still be correct. I still think that avoiding mechanical zig zag movements very close to perimeters is a good tradeoff for extra material used.

Since we have variable width perimeters now, could we widen existing perimeters in the areas that prompted the need for extra perimeters instead?

[bubnikv]

[alranel]

If that happens, it violates the above statement so it's just a bug.

[alranel]

Okay, there was a regression. This is what Slic3r was doing (top_solid_layers = 3), similar to your drawing:

There were some gaps where the configured number (3) was not enforced, and there were only 2 solid shells. After a one-line fix, this is how it works now:

The configured number is correctly enforced. No need to change the algorithm, just a small fix.

(In the latter picture I also colored the extra perimeters to show that their purpose is not about creating solid shells -that's a wrong assumption- but it's for making the external solid shells more aesthetically pleasant when a very narrow rectilinear infill would be exposed otherwise.)

[bubnikv]

http://prusaprinters.org/wp-content/uploads/2016/11/IMG_5099.jpg

left - the @alexrj Slic3r without the changes of the last couple of days right - the prusa3d slic3r

A similar great test object is the famous tree frog http://www.thingiverse.com/thing:18479

The @alexrj slic3r does not close the back of the frog correctly.

On Mon, Dec 19, 2016 at 3:31 PM, Alessandro Ranellucci < notifications@github.com> wrote:

Okay, there was a regression. This is what Slic3r was doing (top_solid_layers = 3), similar to your drawing:

[image: schermata 2016-12-19 alle 15 18 16] https://cloud.githubusercontent.com/assets/594957/21316088/7bec358c-c5ff-11e6-818d-37a5f51140a9.png

There were some gaps where the configured number (3) was not enforced, and there were only 2 solid shells. After a one-line fix, this is how it works now:

[image: schermata 2016-12-19 alle 15 23 02] https://cloud.githubusercontent.com/assets/594957/21316102/96a3c4f8-c5ff-11e6-838e-c35e7e96d043.png

The configured number is correctly enforced. No need to change the algorithm, just a small fix.

(In the latter picture I also colored the extra perimeters to show that their purpose is not about creating solid shells -that's a wrong assumption- but it's for making the external solid shells more aesthetically pleasant when a very narrow rectilinear infill would be exposed otherwise.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/2750#issuecomment-267977507, or mute the thread https://github.com/notifications/unsubscribe-auth/AFj5I9Mrdjz4SwH2ypEkjXp2xLRnR_loks5rJpU9gaJpZM4DxqAA .

[alranel]

@bubnikv, as explained in my previous comment, it was just a regression which I fixed two hours ago by changing one line in 11ed3d8cf3fd1713b465604535a3a0403cd6d0ad

[lordofhyphens]

@alexrj if I'm reading the original request correctly, we can close when #3627 is merged as it should be covered by that and 11ed3d8. @BillyQuiet is this correct?

[BillyQuiet]

Hello everyone and thank you for the work provided on this case. I think you can close when #3627 is merged.