Curaengine: Draw all perimeters one feature at a time.

[nallenscott]

Moved from daid/Cura#1319:

Cura is drawing one or two perimeters on a feature, then leaving to draw one or two on another feature and so on, until it eventually gets all the perimeters drawn for the entire layer. The resulting perimeters are pretty sloppy due to the starting / stopping (especially on smaller features). Is it possible to force Cura to draw all of the perimeters one feature at a time?

Response to @BagelOrb:

To clarify, let's say we have a part with a few through holes, and a shell thickness (3x) the nozzle diameter so that Cura will draw (3) perimeter lines around the various features of the part. When Cura draws perimeters for a layer, it jumps around between features drawing one or two perimeter lines on each one until all the perimeters for that layer are finished.

This probably isn't a big deal if you're printing figurines. But if you need functional parts, then having features with clean / contiguous shells could be very important. I have another printer with proprietary software that draws all of the perimeter lines for a layer one feature at a time, and draws them in such a way that results in a nice solid shell around each feature.

Drawing perimeters for a layer one feature at a time ( i.e. finish all perimeter lines for a feature before moving to the next feature ) would improve the consistency and contiguity of individual feature shells, and therefore the mechanics and aesthetic of the entire part. Slic3r does this, and I use it for certain parts, but I would prefer to see this behavior in Cura.

[CCS86]

I totally agree

On Thu, Jul 23, 2015, 9:16 AM Nathan Allen [email protected] wrote:

Moved from daid/Cura#1319 https://github.com/daid/Cura/issues/1319:

Cura is drawing one or two perimeters on a feature, then leaving to draw
one or two on another feature and so on, until it eventually gets all the
perimeters drawn for the entire layer. The resulting perimeters are pretty
sloppy due to the starting / stopping (especially on smaller features). Is
it possible to force Cura to draw all of the perimeters one feature at a
time?

Response to @BagelOrb https://github.com/BagelOrb:

To clarify, let's say we have a part with a few through holes, and a shell
thickness (3x) the nozzle diameter so that Cura will draw (3) perimeter
lines around the various features of the part. When Cura draws perimeters
for a layer, it jumps around between features drawing one or two perimeter
lines on each one until all the perimeters for that layer are finished.

This probably isn't a big deal if you're printing figurines. But if you
need functional parts, then having features with clean / contiguous shells
could be very important. I have another printer with proprietary software
that draws all of the perimeter lines for a layer one feature at a time,
and draws them in such a way that results in a nice solid shell around each
feature.

Drawing perimeters for a layer one feature at a time ( i.e. finish all
perimeter lines for a feature before moving to the next feature ) would
improve the consistency and contiguity of individual feature shells, and
therefore the mechanics and aesthetic of the entire part. Slic3r does this,
and I use it for certain parts, but I would prefer to see this behavior in
Cura.

—
Reply to this email directly or view it on GitHub
https://github.com/Ultimaker/CuraEngine/issues/225.

[BagelOrb]

Ah now I understand.

This problem is more difficult than you might think, because while the first perimeter might consist of multiple parts, the second can consist of a single polygon. It would require a bit more computation time to group perimeters which belong together.

[JustAnother1]

+1
Slicing speed is not as crucial as quality. Especially for functional parts. Having this enabled as optional feature could be a solution that fits all users.

[BagelOrb]

It is on the agenda...

Perhaps you guys can help me think of a good algorithm?

I was thinking something along the following lines:

• Perform an inset/outset on each polygon separately
• For each combination of two polygons that might intersect (based on bounding boxes for example):
  
  
  
  • If they intersect, group* these polygons
  
  

printing:

• for each group*
  
  
  
  • for each inset number (wall 2, wall 3, outer wall)
  
  
  • print all insets of the given number for all polygons in the group
  
  

---

most likely polygons won't intersect, but checking each combination is computationally very expensive. We could put the polygons in some data structure which which knows of spatial localization so that we don't have to check _each_ combination of polygons; an axis aligned bounding box tree for example. Still computation will be slowed down considerable, since this has to be done on each layer for multiple inset numbers.

[JustAnother1]

If I understand @nallenscott then instead of re grouping the polygons the issue is more related to the sequence of printing the shell lines. My understanding is:
current situation:
Curaengine picks polygons and draws the first shell line. is continues with this until all polygons have one line. It then starts over and draws the second line on all polygons. In this process the engine must already combine the polygons that intersect.
new situation:
The engine picks the first polygon draws the first shell line (thereby combines intersecting polygons) and then draw all the other shell lines for this polygon. It then selects the next polygon and draws all lines for that polygon. This goes on until all polygons are finished.

For the optimization of the infill (I addressed this before in a different issue) It would probably be a good solution to only look at the polygons that are close by.

Besides the position of the polygon it probably makes sense to take the position of the nozzle after printing the last polygon into account.

Is there a good documentation of how the engine works? I would like to help implementing this, but after looking at the source I have no Idea where to start. I think an overview of the applied algorithms and steps in the process would help people like me to understand the source better. Maybe something like that could be created in the Wiki so that the community can help create it and keep it up to date. A documentation which states which data is available in which phases of the process would help discussions like this (finding the best algorithm). Because also users that can not code could give Ideas based on the documentation. Right now I feel lost. I'm not sure my Ideas make sense, as I don't know if the needed input data is available.

[nallenscott]

@JustAnother1 Correct, and +1 for documentation.

[BagelOrb]

The image below exemplifies why and how perimeters should be grouped.

Note that these are round holes in an object.
When printing the outer perimeter first, both inner circles (=outer perimeter) should be printed before the second perimeter is printed.

[vikbez]

:+1: this is messing my functional parts

[pmbdk]

Is anyone looking at this currently? I wouldn't mind trying to implement it, but some documentation of the source is really needed for me to get started. This issue can really mess up an otherwise good quality functional print with lots of holes in it.

[nallenscott]

I've since moved on. The majority of parts I work with contain hole patterns on the first layer, and Cura struggles with these by skipping around from hole to hole, making a sloppy mess of some or leaving incomplete perimeters around others. Other slicers don't have this problem. Simplify3D, Slic3r, KISSlicer, MatterControl, all render clean, contiguous, bugger-free hole patterns. When/if team Ultimaker tackle a solution, I will happily return to Cura.

[BagelOrb]

@pmbdk
Most of our team is on vacation these days (I just returned) and we have some quite big issues to tackle, so I'm sorry to inform you that we aren't looking into this issue.

If you are willing to implement this, then by all means. We love a nice pull request!
I've been adding lot's of documentation to the code since I've started working on the project, but perhaps not those functions which are of interest for this problem.

You should have a look at FffGcodeWriter::processInsets
Currently it processes each inset consecutively, based on the number of the inset.
The issue could be fixed by working recursively on a ClipperLib::PolyNode instead of a list. That would mean you would have to change the type of SliceLayerPart::insets to a PolyTree, rather than a list of Polygons.

I hope this helps and you are still willing to help implementing this feature.

[Ghostkeeper]

This is implemented through the "Optimize Wall Printing Order" setting.