<p>Your model is not printable the way you &quot;intuitively&quot; think it is:</p>
<blockquote>
<p>I would expect the slicer to trace the diagonal lines one after the other, e.g., from left to right, and then follow up with the perpendicular ones.</p>
</blockquote>
<p>Once one direction of diagonal lines was finished, the other direction could only be drawn by &quot;picking up the pen&quot; over and over to draw each broken-up segment one at a time. Such a strategy has <strong>a lot</strong> of travel/retraction, and is thereby slow/inefficient and also higher risk for print errors. A pattern that snakes around in a continuous path, avoiding self-crossing as long as it can, is preferable.</p>
<p>However, the slicer doesn't even have that much high level reasoning at its disposal to choose between &quot;these two options&quot;. It's just solving for a decent best effort at an optimization problem for covering all the perimeters which need to be printed, which is something akin to the <a href="https://en.wikipedia.org/wiki/Travelling_salesman_problem" rel="nofollow noreferrer">travelling salesman problem</a> or similar graph theoretic problems which are <a href="https://en.wikipedia.org/wiki/NP-completeness" rel="nofollow noreferrer">NP complete</a> and thereby do not admit any efficient search for an optimal solution.</p>
<p>As an aside, you may notice that grid infill doesn't have this &quot;problem&quot;. It prints the way you intuitively expected it to. This is because <strong>the slicer cheats</strong> and prints all of the crossing points twice. That often works out okay for infill, where it won't be visible, although lots of users, especially when printing at high speeds, run into problems with &quot;self-intersecting infill patterns&quot; where the sudden nozzle occlusion and resulting change in backpressure create broken extrusions and material sticking up past the layer height and colliding with subsequent layers. This kind of problem makes such a strategy a bad idea for the actual outer geometry of your print. But even if it weren't a bad idea, the slicer simply doesn't have a way of knowing &quot;these features are ones the user wants me to print like infill&quot;. It's just solving the general problem of &quot;print the perimeters for these polygonal regions&quot;, and in general, the solution doesn't look like an infill-specific hack.</p>

CC BY-SA 4.0
2023-08-25T16:26:25.133Z
2023-08-25T16:26:25.133Z
R.. GitHub STOP HELPING ICE
<p>I'm using an original Prusa MK3S and the PrusaSlicer as my slicing software. <br>
I want to print this net shape with only one layer and a thickness of 0.3mm.</p>
<img src="https://i.sstatic.net/OlICi.png" width="400">
<p>Intuitively, I would expect the slicer to trace the diagonal lines one after the other, e.g., from left to right, and then follow up with the perpendicular ones.</p>
<p>But when sliced with the PrusaSlicer, it traces the individual squares of the net in a seemingly random ordering.</p>
<p><img src="https://i.sstatic.net/vym11.png" width="200"> <img src="https://i.sstatic.net/zq77E.png" width="200"> <img src="https://i.sstatic.net/IneC5.png" width="200"></p>
<p>I'm using all the default settings and a layer height of 0.3mm. Any ideas why the slicer does that?
Printing the squares instead of the lines is probably more prone to breaking when bent.</p>

<prusaslicer>
Why does the PrusaSlicer trace random squares instead of the straight lines?
vincirist
# Why does the PrusaSlicer trace random squares instead of the straight lines?

(Asked by: username_0 on 2023-08-25)

I'm using an original Prusa MK3S and the PrusaSlicer as my slicing software.   
I want to print this net shape with only one layer and a thickness of 0.3mm.

![](https://i.sstatic.net/OlICi.png)

Intuitively, I would expect the slicer to trace the diagonal lines one after the other, e.g., from left to right, and then follow up with the perpendicular ones.

But when sliced with the PrusaSlicer, it traces the individual squares of the net in a seemingly random ordering.

![](https://i.sstatic.net/vym11.png) ![](https://i.sstatic.net/zq77E.png) ![](https://i.sstatic.net/IneC5.png)

I'm using all the default settings and a layer height of 0.3mm. Any ideas why the slicer does that?
Printing the squares instead of the lines is probably more prone to breaking when bent.

**Tags:** prusaslicer


---

## 1 answers

### Answer by username_1 on 2023-08-25. Score: 1 | Accepted answer

Your model is not printable the way you "intuitively" think it is:

> I would expect the slicer to trace the diagonal lines one after the other, e.g., from left to right, and then follow up with the perpendicular ones.

Once one direction of diagonal lines was finished, the other direction could only be drawn by "picking up the pen" over and over to draw each broken-up segment one at a time. Such a strategy has **a lot** of travel/retraction, and is thereby slow/inefficient and also higher risk for print errors. A pattern that snakes around in a continuous path, avoiding self-crossing as long as it can, is preferable.

However, the slicer doesn't even have that much high level reasoning at its disposal to choose between "these two options". It's just solving for a decent best effort at an optimization problem for covering all the perimeters which need to be printed, which is something akin to the [travelling salesman problem](https://en.wikipedia.org/wiki/Travelling_salesman_problem) or similar graph theoretic problems which are [NP complete](https://en.wikipedia.org/wiki/NP-completeness) and thereby do not admit any efficient search for an optimal solution.

As an aside, you may notice that grid infill doesn't have this "problem". It prints the way you intuitively expected it to. This is because **the slicer cheats** and prints all of the crossing points twice. That often works out okay for infill, where it won't be visible, although lots of users, especially when printing at high speeds, run into problems with "self-intersecting infill patterns" where the sudden nozzle occlusion and resulting change in backpressure create broken extrusions and material sticking up past the layer height and colliding with subsequent layers. This kind of problem makes such a strategy a bad idea for the actual outer geometry of your print. But even if it weren't a bad idea, the slicer simply doesn't have a way of knowing "these features are ones the user wants me to print like infill". It's just solving the general problem of "print the perimeters for these polygonal regions", and in general, the solution doesn't look like an infill-specific hack.


---

