Combing not crossing at location where two parts are closest together

[scottmudge]

Is your feature request related to a problem?

This is related to the combing feature. Even when it is set to "All", it still crosses the perimeters of the object when it must jump between two isolated "islands" on a layer.

I understand this, if there is no connection between to different areas of a slice, it has to jump between them at some point.

But in PrusaSlicer, the equivalent feature will avoid crossing the perimeter until it is as close as possible to the island it's trying to jump to. In Cura, it simply takes a straight line to the island from the end of the last toolpath.

See the image below. The line shoots straight through an inner circle to reach to the isolated part of the layer, which would lead to stringing. Instead, I propose that the Combing feature follows the internal geometry of the layer until it is as close as possible to the island it is trying to jump to (black line in this example).

Describe the solution you'd like

Instead of Cura forcing the tool to jump directly between two isolated "islands" in a layer without any attempt to reduce crossing perimeters, have it follow the internal geometry of the first island to get as close as possible to the second, before jumping. See image above.

Describe alternatives you've considered

I'm not sure how PrusaSlicer does this specifically, but it appears to get as close as possible before jumping. Perhaps the PS source code has an insight into this.

Affected users and/or printers

Presumably all users and printers.

Additional information & file uploads

See image above.

[Ghostkeeper]

What you're describing is actually expected behaviour. It is as written in the documentation here: https://github.com/Ultimaker/CuraEngine/blob/master/docs/generating_paths.md#travelling

It needs to travel through the first part to the location where the two parts are closest together, then cross over, and then travel through the second part to the final destination. If this doesn't happen, it may cross other walls unnecessarily and it'll have more time to ooze material outside of the print, leading to stringing.

Here is a video demonstrating that behaviour:

https://user-images.githubusercontent.com/2448634/134885136-7eb28ab1-27fd-45b5-9f14-de436a30d078.mp4

Do you have a model where this doesn't happen? Could you share a project file with us that reproduces the issue?

[scottmudge]

In the screenshot I provided, the blue travel line crossing the interior of the bore/cylinder is jumping to the "island" or disconnected portion of the slice at the top of the screen. You can see the same effect on the right hand side. This seems to occur throughout the entirety of the model at different vertical slices.

Instead, I would expect it to curve around, as with the black line I drew (and as the intended behavior should be).

Attached is an example model (the one in the screenshot). The bore is not a complete cylinder, it is broken by a small gap at the bottom. So the interior of the cylinder is possibly considered an "exterior".

example_file.zip

Does the slicing algorithm avoiding interior walls or interior parts of the model use the convex hull of the model to avoid this kind of behavior? Or does it simply use the exact exterior surface, even when concave cavities like this create an, effectively, interior pocket?

Regardless, I also tried modifying the model by placing a small bridge (0.4 mm in height) at the base of the model to "close" the cylindrical cavity. But the behavior of crossing the cavity instead of going around was the same.

The effect is increased stringing inside the cylindrical bore, which is somewhat annoying to clean out.

[Ghostkeeper]

Does the slicing algorithm avoiding interior walls or interior parts of the model use the convex hull of the model to avoid this kind of behavior? Or does it simply use the exact exterior surface, even when concave cavities like this create an, effectively, interior pocket?

Good thinking, but no. It uses two combing bounds, one "preferred" bound 1.5 line widths away from the border and a "minimum" bound 0.5 line widths away from the border. If the preferred bound has no path it should try the minimum bound. Neither of them are convex, but simply offsets of the input shape (with some optimisations to re-use the wall lines if generated earlier).

Sorry, but I loaded in your STL with Prusa's default settings but it doesn't reproduce the issue. Could you still share a project file, so that I have the same position and same settings as you? To save a project file, you go to File -> Save Project... The project file contains your models, their positions, and all profiles and settings you're using for that print. It allows precise reproduction of the g-code and allows us to debug why it's making certain choices.

This could be related to a fix I made last week for the Arachne version of Cura: https://github.com/Ultimaker/CuraEngine/pull/1503

[scottmudge]

Sure, I'll dig up the file when I get to my work office. When attempting to reproduce the issue, did you use a build from the 4.11 node, or were you using a build with the fix you mentioned merged in?

And indeed, it might be a good option to allow using a computed convex hull as the boundary for combing and related features. Not sure the full list of libraries being used, but I do know VCG has a method of computing a convex hull from a tri-mesh or quad-mesh. Perhaps you already have a method baked into the code, however.

[Ghostkeeper]

When attempting to reproduce the issue, did you use a build from the 4.11 node, or were you using a build with the fix you mentioned merged in?

I used current master, where that fix was not merged yet.

The bug I mentioned is fixed for the Arachne version of Cura, which is to become Cura 5.0. But we'll first release a 4.12 release without. If my fix indeed fixes your issue too, chances are that we won't want to backport that fix to 4.12, depending on how important my team thinks it is. But at least you'll then have a fix in 5.0, and in the third Arachne beta we're planning to release before that.

[Ghostkeeper]

And indeed, it might be a good option to allow using a computed convex hull as the boundary for combing and related features. Not sure the full list of libraries being used, but I do know VCG has a method of computing a convex hull from a tri-mesh or quad-mesh. Perhaps you already have a method baked into the code, however.

CuraEngine has a method for approximate convex hulls in 2D (used among others for the skirt). Cura's front-end uses the convex hull function from the Shapely library for both 2D and 3D convex hulls (used for the disallowed areas).

I don't think using the convex hull is a good idea here though, since you still want to avoid crossing the walls even if they are concave in the greater shape of the object. It would cause precisely the issue you're describing here.