Slic3r support generator issues

[bubnikv]

1. When the number of interface layers > 0, slic3r generates a "circles" pattern. It may or may not be desirable under bridges, but I don't think this is useful below sloping surfaces. Please make that "circles pattern" configurable and / or apply it below the bridges only.

2. When supporting a bridge with a bridging perimeter, the checkbox "Detect bridging perimeters" shall be enabled. Otherwise the perimeter will be printed with a thin layer in the mid air above the supports and the bridges will have no perimeter to stick to. This shall be at least documented. Regarding the bridge flow above the supports, it may make sense to use a different bridging flow than in the mid air.

3. The adaptive layering has two goals: First to control the gap between the support and the print accurately, second to print thick layers to save time. But with sloping surfaces the interface layer is triggered nearly every layer and it is usually placed at a different height from the print layers, which in turn leads to too many very thin support surfaces with the current implementation. A complex solution would be to analyze the 3D topology of the supports and control the layer thickness separately per each support column. Without that, some prints would benefit of a settings, which would force the support layers to be synchronized with the print layers.

4. I believe the bottom gap between the support and the object is not respected correctly. Namely, the bottom layer of the support is printed with the normal flow, but with a bridging layer thickness. Instead, the bottom layer of the support shall be printed with a bridging flow.

5. A sheath is always generated for the main supports. This makes the supports difficult to remove. Make the sheath configurable as in Kisslicer. Simplify3D does not generate the sheath at all. This has been pushed into the Prusa3D fork.

6. Better infill algorithm. Current rectilinear algorithm connects the end points of the line segments by straight lines and it does that only if the straight lines do not cross the perimeter. The correct solution for the supports would be to let the connecting line follow the perimeters. This has been pushed into the Prusa3D fork (with a complete C++ implementation of all the infills), but it is not perfectly stable yet.

7. Supports are trimmed by the object at the interface layer and this trimmed polygon is then propagated downwards. This means the overhang is supported asymmetrically. It would be good to make the support symmetric in regard to the overhangs.

8. Support regions are quite jagged. Without the sheath, the support will benefit, if the non-touching contours of the supports are smoothed and filleted. The issue with the clipper implementation is it is very slow if a large diameter filleting is applied with the "jtRound" parameter. A better solution, which I believe kisslicer uses, is to use distance fields instead of the contours. I have implemented a distance field structure over Slic3r polygons in the EdgeGrid.cpp/hpp files of the Prusa3D fork, but the filleting has to be implemented yet.

Vojtech

[bubnikv]

9. Bridges over supports. Currently Slic3r tries to find the best orientation of bridges always, but if the bridges are over the supports, this may be counter-productive as the support has usually a constant orientation of the hatch and the bridges will better not be parallel with the support.

[bubnikv]

10. Pillars is a nice idea, but the current implementation is not usable. The pillars are built on a regular grid and then trimmed by the usual support volumes. This often trims the column to a thin slice, which has to support a large overhang. Such trimmed column often breaks. The solution is to place the columns adaptively, not on a regular grid.

[bubnikv]

11. Slic3r does not know about the volume / weight of the unsupported printed object. A cone at its tip will not get any support as long as the cone angle is sharp enough.

[lordofhyphens]

Is the distance field easy to find in your fork? That's largely mirrored my own thoughts on handling small support areas.

[bubnikv]

The distance field is implemented in EdgeGrid.cpp/hpp as mentioned before.

On Fri, Oct 7, 2016 at 9:01 PM, Joseph Lenox notifications@github.com
wrote:

Is the distance field easy to find in your fork? That's largely mirrored
my own thoughts on handling small support areas.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#3529 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5I5i2434Oa0zSSLAlDystaedAPecBks5qxpcMgaJpZM4KQv7j
.

[Patola]

What is EdgeGrid.cpp / hpp? Found no such files on slic3r or any other project for that matter...

[lordofhyphens]

It is in his fork, not the main branch of Slic3r. When I get some time I
will take a look at it and put together a branch for integration.
On Oct 7, 2016 4:46 PM, "Patola" notifications@github.com wrote:

What is EdgeGrid.cpp / hpp? Found no such files on slic3r or any other
project for that matter...

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3529 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8Cv26FND3Bi-DqD1gnvD78rp2uXPrks5qxr2kgaJpZM4KQv7j
.

[lordofhyphens]

Currently a work in progress; several methods used by the commits rely on other changes that were made. Been trying to tease out the relevant dependencies. I like having support in libslic3r, but it is definitely not fun to pull apart from everything else and integrate it into Slic3r master.

As I see more commits related to this, I'll add them to this branch.

https://github.com/lordofhyphens/slic3r/tree/support-integration

Next project is to incorporate the work that @bubnikv has done to improve code documentation.

[maukcc]

also important:
layer height of support material is 0.75x nozzle diameter. I want to put in my own layer height
"contact Z distance" value set to zero works correct, any other value is: nozzle diameter + that value ??? so with a 0.8 nozzle and 0.05mm contact Z distance, I get a distance of 0.85mm.That is a bit more then I need :)
checked with 1.3.0-dev

[bubnikv]

By the way, why does 0.75x nozle diameter not suit you?

On Tue, Oct 11, 2016 at 4:06 PM, MaukCC notifications@github.com wrote:

also important:
layer height of support material is 0.75x nozzle diameter. I want to put
in my own layer height
"contact Z distance" value set to zero works correct, any other value is:
nozzle diameter + that value ??? so with a 0.8 nozzle and 0.05mm contact Z
distance, I get a distance of 0.85mm.That is a bit more then I need :)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#3529 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AFj5I1lHItZgRfU2MVDTZ7qx8kyA1UlBks5qy5fagaJpZM4KQv7j
.

[maukcc]

I can live with it. although with a 1.2 nozzle having 0.9mm layers will have poor layer adhesion.
Also with larger layer height, you get the effect that at the end of extrusion and the nozzle starts traveling in a direction, it tends to pull the material in that direction.
But I just want to control it myself, I checked "expert" at "preferences/mode" for a reason :)
Or at least make a note of it on the "support material" page, so people are aware of it. Otherwise people will think that the support is doing random/strange/uncontrollable things.

[lordofhyphens]

There is a pull request open to handle the support z distance default
On Oct 11, 2016 9:40 AM, "MaukCC" notifications@github.com wrote:

I can live with it. although with a 1.2 nozzle having 0.9mm layers will
have poor layer adhesion.
Also with larger layer height, you get the effect that at the end of
extrusion and the nozzle starts traveling in a direction, it tends to pull
the material in that direction.
But I just want to control it myself, I checked "expert" at
"preferences/mode" for a reason :)
Or at least make a note of it on the "support material" page, so people
are aware of it. Otherwise people will think that the support is doing
random/strange/uncontrollable things.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#3529 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAB8Cj3zP0CZqSrovZ09J3QezWlGxoh5ks5qy5_qgaJpZM4KQv7j
.