For an easier check it is enough to slice the YOLO flow calibration and watch how erratic is the sparse infill.

I think I found the culprit. By reversing PR #9407 the issue goes away.
@elektrohenk can you please take a look? Thank you.

Hi @kisslorand, This commit results in the described behavior. OrcaSlicer is not very smart in ordering the infill paths efficiently. For (aligned) rectilinear there is a special implementation that results in a more efficient infill path ordering. During implementation of #9407 this behavior was observed and enforced for solid infill. The special implementation however does not respect the infill anchor parameters. It will connect the lines if the parameter "Maximum length of the infill anchor" is higher than 0.05 mm and none at all if lower. You will see the same "fragmented" infill line order if the lines are not connected. Although the behavior/result is different, it obeys the print settings. In order to keep the print time low, would it be acceptable if the special implementation is enforced when "Maximum length of the infill anchor" is equal or higher than the infill line distance?

@elektrohenk

This commit results in the described behavior.

That commit is responsible for the rectilinear infill type only but the issue is persistent through all the infill type that user straight lines (ex. gyroid is OK).

For (aligned) rectilinear there is a special implementation that results in a more efficient infill path ordering.

Aligned rectilinear infill is borked also.

In order to keep the print time low, would it be acceptable if the special implementation is enforced when "Maximum length of the infill anchor" is equal or higher than the infill line distance?

The print time increase is the result of the issue, not the issue itself. I think everybody would agree that a non-erratic infill path is expected regardless of the settings for the infill anchor (as it was prior to PR #9407).

One pattern I observed though is that at the breakage of the infill path the infill anchor goes the other way, towards the already laid down infill lines, instead of its natural course to continue the infill path. Maybe this helps fixing the problem.

@kisslorand

That commit is responsible for the rectilinear infill type only but the issue is persistent through all the infill type that user straight lines (ex. gyroid is OK).

Aligned rectilinear infill is borked also.

The print time increase is the result of the issue, not the issue itself. I think everybody would agree that a non-erratic infill path is expected regardless of the settings for the infill anchor (as it was prior to PR #9407).

Show me an example where the infill path became erratic due to #9407 except for rectilinear and aligned rectilinear.

etc, etc

Later edit: I just checked the above examples and sadly they are broken in previous Orca versions also. So it seems PR #9407 didn't affected others than "Rectilinear" and "Aligned Rectilinear".

Have you done the same with 2.3.0? I'm not able to find different sparse infill path / printing times for sparse infill patterns other than rectilinear and aligned rectilinear between nightly and 2.3.0 using your Cube project.

I just literally finished editing my previous message while you posted the above.

Later edit: I just checked the above examples and sadly they are broken in previous Orca versions also. So it seems PR #9407 didn't affected others than "Rectilinear" and "Aligned Rectilinear".

Ok, good to agree on that. Now back to possible solutions.

The best solution would be to improve the path optimization. It seems that Fill::connect_infill() is inferior to ShortestPath::chain_polylines(). Suspicious: //FIXME improve the Traveling Salesman problem with 2-opt and 3-opt local optimization. I will quickly look into optimizing the infill path using ShortestPath::chain_polylines() before calling Fill::connect_infill().

Enforcing the "old" method for "Rectilinear" and "Aligned Rectilinear" when "Maximum length of the infill anchor" is long enough seems to be a need quick fix to me, already successfully tested this solution locally.

While you're at it, it would be just great if you could make all the infill patterns to be optimal (shortest path, shortest time).

Update: Ignore what I said about ShortestPath::chain_polylines() vs Fill::connect_infill(), both give similar results. FillRectilinear::traverse_graph_generate_polylines() makes the difference, it takes advantage from the properties of the simplified optimization problem for the "Rectilinear" infill pattern where all infill lines are always in the same direction.

Optimizing the path generation in Fill::connect_infill() will take a while. Therefore I will first improve the path generation for "Rectilinear" and "Aligned Rectilinear" when "Maximum length of the infill anchor" is long enough.