Honeycomb Infill draws unsupported border lines.

[lordofhyphens]

Version

4db029c

Behavior

Honeycomb infill bordering on the perimeters draws unsupported lines. This makes these areas have a weak binding to the rest of the infill and to the perimeters.

Suggested solution: Incorporate the snippets for the borders into the draw pattern for honeycomb.

STL/Config (.ZIP) where problem occurs

model_and_config.zip

[lordofhyphens]

Confirming that this behavior is also present in the prusa3d fork, fyi @bubnikv

@AndKe fyi

[supermerill]

I was thinking it was made to remove many wipes moves and so to increase the speed of the infill. I've added the same in the gyroid one, should i disable it?

[AndKe]

it certainly does nothing good as-is.

[xoan]

All the infill patterns do the same.

As @supermerill says, it removes a lot of wipe and retract moves, mainly in convex corners like the one above.

Don't remember when this was commited, but I think it was a huge improvement in speed and printability

@lordofhyphens what are the downside of it?

[bubnikv]

All the infill patterns do the same.

Roughly, yes.

None of the infill types try to place the connecting lines (the pieces of perimeter) one over the above. I don't think this is even feasible.

The grid infill has yet another issue, where the pieces of perimeter for the two directions in a single layer may overlap, creating over extrusion. If there is enough space inside the object, then this is usually not a problem as the over extrusion is spread inside, but it may be issue for narrow objects. The stars / triangles / cubic infill has the same issue.

There is some difference between the honeycomb and the grid/stars/cubic/triangles infill in the way how the infill lines are connected by the perimeter pieces. The grid/stars/cubic/triangles try to connect the infill lines into a continuous sweep, while the honeycomb infill creates loops. Naturally the first is better, and the honeycomb creates loops by incidence: The honeycomb infill lines are trimmed by the polygonal boundary using a clipper library, and the clipper library creates these loops. The clipper library may be switched to not connect the infill lines with the perimeter pieces at all, but the clipper is not able to generate a continuous sweep by itself, and the continuous sweep would require significant changes of the honeycomb infill algorithm.

Is not having the perimeter pieces supported an issue? With enough infill / perimeter overlap these pieces are supposed to be sufficiently fused to the inner perimeter.

On Tue, Apr 3, 2018 at 5:18 PM, Xoan Sampaiño notifications@github.com wrote:

All the infill patterns do the same.

[image: captura de pantalla_2018-04-03_17-03-22] https://user-images.githubusercontent.com/288246/38257923-83e39580-3761-11e8-9b10-f5559c27d7f9.png

As @supermerill https://github.com/supermerill says, it removes a lot of wipe and retract moves, mainly in convex corners like the one above.

Don't remember when this was commited, but I think it was a huge improvement in speed and printability

@lordofhyphens https://github.com/lordofhyphens what are the downside of it?

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

[xoan]

Totally agree.

[lordofhyphens]

Doesn't the modified rectilinear create loops? I don't have the system in front of me.

[lordofhyphens]

As an aside, I created the issue for @AndKe.

I think that the current system is a decent tradeoff myself and some infill patterns are better than others for every N.