Cura: [3.4.1] Wrong infill order with "Combing mode" enabled

[nightgryphon]

Application Version
3.4.1

Platform
Windows 8 64bit

Steps to Reproduce
Enable "Combing mode: all"
Slice the attached OBJ

Actual Results
Te model is sort of "C" shape with some infills at the ends.
At the inner layers gcode do:

• infill at the first infill area at the one end of "C" shape
• than head moved over the whole part to the other side skipping all infill areas on it's way to fill second small infill at the other end of "C" shape
• than head moves back over the whole part to fill area just near the first infill area
• etc moving back and forth...

Expected results
Infill areas sequentially selecting next area by the head travel distance (or by head travel time including z-hop) not the geometry distance. Choosing infill order by geometry distance is wrong.

Additional Information
The current behavior make a huge lot of unnecessary head free travels making print slow and unnecessary printer wear

camera_holder.zip

[smartavionics]

Hi, could you please save the project file, zip it up and attach to this issue so I can see exactly what you are referring to? Thanks.

[smartavionics]

BTW, until I see the project file I'm only guessing but you may find it useful to enable the "Infill Travel Optimization" setting.

[smartavionics]

Forget that comment about Infill Travel Optmization because I've just realised that you're talking about the inner walls and not infill at all. I'm looking into it.

[BagelOrb]

I'm confused as to what the problem is. Could you please attach a screenshot of the layer view with arrows to the regions for which the order is wrong?

[smartavionics]

Hi Tim, the problem is not with infill but with the inner walls. The ordering code for them is not using combing at all which is why they are coming out in a daft order. However, when I use combing to determine the ordering it gets it wrong! So I am currently investigating that. Here's a picture of the part anyway...

The problem is that it's not printing the green bits in a sensible order. Working on it!

[smartavionics]

Hi, I have a fix for this which I will submit in the future when some of my other PRs have been either merged or discarded.

[Ghostkeeper]

We are cautious with a fix for this because it could increase slicing time tenfold easily with some models. The distance calculation to go from one part to the next is purposely very naive because it's executed in a cubic part of the algorithm. If we make that more complex, the slicing time increases dramatically.

[nightgryphon]

Dear Ghostkeeper, for my opinion increasing slicing time is _dramatically_ better than dramatically increase print time and hardware wear. The current slicing time for most cases is not that big and increasing it even two times worth better result. Anywhere this optimization can be added as optional parameter so user can choose to use it or to skip for faster slicing.
Also i'm a bit curious why the optimization for inner walls take more time than optimization for infill which work correctly? Also if this is actually SO time consuming than let's combine it with infill optimization which already work fine.
PS hmm... may be combine printing inner wall than infill it contains than next inner wall + it's infill is also a good idea? instead of print all inner walls than print all infills

[Ghostkeeper]

Dear Ghostkeeper, for my opinion increasing slicing time is dramatically better than dramatically increase print time and hardware wear. The current slicing time for most cases is not that big and increasing it even two times worth better result. Anywhere this optimization can be added as optional parameter so user can choose to use it or to skip for faster slicing.

With dramatically I mean that we've previously seen a similar fix increase slice time from 2 minutes to 40 minutes on a particular type of model with many pieces, which was more than the time you'd save with the more optimal printing time. We are talking about a cubic order of magnitude which gets changed into quartic here, so the slicing time scales with the n^4 where n is the number of vertices on a layer. We consider slicing time more valuable than printing time since the user needs to actively wait for slicing to complete, but typically does other stuff while waiting for the printer to complete printing. This is more of a concern for novices and first impressions than for experienced people who streamlined their workflow already. An option to enable it could still result in confused people wondering why the slicing progress bar seems to freeze.

Also i'm a bit curious why the optimization for inner walls take more time than optimization for infill which work correctly? Also if this is actually SO time consuming than let's combine it with infill optimization which already work fine.

The optimization for infill is less of a concern because this goes wrong if you have lots of small pieces in your print, such as chain mail or fuzzy prints. When you have lots of pieces they also tend to be small enough that there is no infill. That is why we did accept that change.

PS hmm... may be combine printing inner wall than infill it contains than next inner wall + it's infill is also a good idea? instead of print all inner walls than print all infills

It should already do this right now. It prints all walls, infill and skin of one part before moving on to the next.

[nightgryphon]

Why that n^4 happens? It should be n^2. Also i expect there some search optimization should be possible to filter "inner wall loops" instead of every point.

[smartavionics]

As mentioned above, I have fixed this issue but I don't think the fix has been submitted as a PR yet. Trying to find my fix (LOL).

[smartavionics]

I found the fixes, I have been using these since July and haven't noticed any problems. With luck they will make it into a release within 6 months!

[Ghostkeeper]

Why that n^4 happens? It should be n^2.

We use nearest-neighbour to determine the closest inner wall line to print next. The N^4 comes from:

• For every endpoint where we ended a line...
• For every starting point where we can start the next line (every vertex of inner walls), we need to calculate the path to avoid collisions, so...
• For every segment in our combing path...
• We need to check collisions with every line segment to check if the path to the destination collides with it.

Also i expect there some search optimization should be possible to filter "inner wall loops" instead of every point.

Yes, for the first two points above we do check only the walls of a part, since we optimise the walls together.