How Do Tool Path Algorithms Decide Which Direction to Print a Closed-Loop Polygon












2












$begingroup$


I understand how slicer programs create sets of closed-loop polygons to print on a layer-by-layer basis. For a given closed loop polygon which needs to be printed, the tool path generator will know the coordinates and how those coordinates are connected to each other, such that traversing a set of segments in that order will bring the extruder head back to the first coordinate to complete the closed loop.



My question is: By what mechanism does the tool path generator decide which direction to traverse the closed loop? As it is a loop, that loop could be printed "clockwise" or "counter-clockwise", as it were. Any details, and links to further explanations of how some of the big-name slicer programs determine this is much appreciated.










share|improve this question











$endgroup$

















    2












    $begingroup$


    I understand how slicer programs create sets of closed-loop polygons to print on a layer-by-layer basis. For a given closed loop polygon which needs to be printed, the tool path generator will know the coordinates and how those coordinates are connected to each other, such that traversing a set of segments in that order will bring the extruder head back to the first coordinate to complete the closed loop.



    My question is: By what mechanism does the tool path generator decide which direction to traverse the closed loop? As it is a loop, that loop could be printed "clockwise" or "counter-clockwise", as it were. Any details, and links to further explanations of how some of the big-name slicer programs determine this is much appreciated.










    share|improve this question











    $endgroup$















      2












      2








      2





      $begingroup$


      I understand how slicer programs create sets of closed-loop polygons to print on a layer-by-layer basis. For a given closed loop polygon which needs to be printed, the tool path generator will know the coordinates and how those coordinates are connected to each other, such that traversing a set of segments in that order will bring the extruder head back to the first coordinate to complete the closed loop.



      My question is: By what mechanism does the tool path generator decide which direction to traverse the closed loop? As it is a loop, that loop could be printed "clockwise" or "counter-clockwise", as it were. Any details, and links to further explanations of how some of the big-name slicer programs determine this is much appreciated.










      share|improve this question











      $endgroup$




      I understand how slicer programs create sets of closed-loop polygons to print on a layer-by-layer basis. For a given closed loop polygon which needs to be printed, the tool path generator will know the coordinates and how those coordinates are connected to each other, such that traversing a set of segments in that order will bring the extruder head back to the first coordinate to complete the closed loop.



      My question is: By what mechanism does the tool path generator decide which direction to traverse the closed loop? As it is a loop, that loop could be printed "clockwise" or "counter-clockwise", as it were. Any details, and links to further explanations of how some of the big-name slicer programs determine this is much appreciated.







      slicing






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited 5 hours ago







      Thetravellingfool

















      asked 7 hours ago









      ThetravellingfoolThetravellingfool

      1186




      1186






















          1 Answer
          1






          active

          oldest

          votes


















          3












          $begingroup$

          Math



          In math, there is a way how a path is to be followed, and that is usually counterclockwise:



          Assuming a perimeter path of a circle with $r=1$ around $(2,2)$, then the path can be defined as $f(p)={{cos(p)+2}choose{sin(p)+2}}$ - where $p$ is the path parameter, in this case an angle of 0 to 360°, and just increasing the angle rotates right hand around. If we had the same path but a different starting point, a shift by $theta$, then the path would read $f(p)={{cos(p+theta)+2}choose{sin(p+theta)+2}}$. So math is usually counterclockwise.



          Slicers



          Now, any slicer is applied math. As far as I can tell, Cura does slice with the result of a clockwise path, which is always performed. However, that does not invalidate the math at all, since solving a path with $p=0°to360°$ and solving it $p=360°to0°$ results in producing the exact same print, just opposed print direction of the perimeter.



          As long as the perimeter of an object is solved as being done as one closed loop, the perimeter will need to have just one, prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly solves its calculations. Since both directions are equally valid, it is a programmer's decision. Some options might be:




          • Solving the path correctly counterclockwise and putting the slicing into a FILO memory, resulting in a clockwise operation starting from the last solved point.

          • Solving counterclockwise and saving into FIFO, running counterclockwise.

          • Solving deliberately clockwise for arbitrary reasons.


          Conclusion



          Slicers for 3D printing have a hard-coded direction that is followed when producing gcode. Any and all perimeters will be printed, starting from some arbitrary point, into that direction. In the end, it is a choice of the programmer of the slicing engine that determines if the path is to be run down "forward" or "backward" in mathematical sense.






          share|improve this answer











          $endgroup$













          • $begingroup$
            Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            @Thetravellingfool good remark, had to look it up, I mixed it up, fixed
            $endgroup$
            – Trish
            5 hours ago










          • $begingroup$
            Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            Trish, your answer is much appreciated. Is there a source you could provide for the information you gave?
            $endgroup$
            – Thetravellingfool
            48 mins ago











          Your Answer





          StackExchange.ifUsing("editor", function () {
          return StackExchange.using("mathjaxEditing", function () {
          StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
          StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["$", "$"], ["\\(","\\)"]]);
          });
          });
          }, "mathjax-editing");

          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "640"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          noCode: true, onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2f3dprinting.stackexchange.com%2fquestions%2f7971%2fhow-do-tool-path-algorithms-decide-which-direction-to-print-a-closed-loop-polygo%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          3












          $begingroup$

          Math



          In math, there is a way how a path is to be followed, and that is usually counterclockwise:



          Assuming a perimeter path of a circle with $r=1$ around $(2,2)$, then the path can be defined as $f(p)={{cos(p)+2}choose{sin(p)+2}}$ - where $p$ is the path parameter, in this case an angle of 0 to 360°, and just increasing the angle rotates right hand around. If we had the same path but a different starting point, a shift by $theta$, then the path would read $f(p)={{cos(p+theta)+2}choose{sin(p+theta)+2}}$. So math is usually counterclockwise.



          Slicers



          Now, any slicer is applied math. As far as I can tell, Cura does slice with the result of a clockwise path, which is always performed. However, that does not invalidate the math at all, since solving a path with $p=0°to360°$ and solving it $p=360°to0°$ results in producing the exact same print, just opposed print direction of the perimeter.



          As long as the perimeter of an object is solved as being done as one closed loop, the perimeter will need to have just one, prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly solves its calculations. Since both directions are equally valid, it is a programmer's decision. Some options might be:




          • Solving the path correctly counterclockwise and putting the slicing into a FILO memory, resulting in a clockwise operation starting from the last solved point.

          • Solving counterclockwise and saving into FIFO, running counterclockwise.

          • Solving deliberately clockwise for arbitrary reasons.


          Conclusion



          Slicers for 3D printing have a hard-coded direction that is followed when producing gcode. Any and all perimeters will be printed, starting from some arbitrary point, into that direction. In the end, it is a choice of the programmer of the slicing engine that determines if the path is to be run down "forward" or "backward" in mathematical sense.






          share|improve this answer











          $endgroup$













          • $begingroup$
            Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            @Thetravellingfool good remark, had to look it up, I mixed it up, fixed
            $endgroup$
            – Trish
            5 hours ago










          • $begingroup$
            Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            Trish, your answer is much appreciated. Is there a source you could provide for the information you gave?
            $endgroup$
            – Thetravellingfool
            48 mins ago
















          3












          $begingroup$

          Math



          In math, there is a way how a path is to be followed, and that is usually counterclockwise:



          Assuming a perimeter path of a circle with $r=1$ around $(2,2)$, then the path can be defined as $f(p)={{cos(p)+2}choose{sin(p)+2}}$ - where $p$ is the path parameter, in this case an angle of 0 to 360°, and just increasing the angle rotates right hand around. If we had the same path but a different starting point, a shift by $theta$, then the path would read $f(p)={{cos(p+theta)+2}choose{sin(p+theta)+2}}$. So math is usually counterclockwise.



          Slicers



          Now, any slicer is applied math. As far as I can tell, Cura does slice with the result of a clockwise path, which is always performed. However, that does not invalidate the math at all, since solving a path with $p=0°to360°$ and solving it $p=360°to0°$ results in producing the exact same print, just opposed print direction of the perimeter.



          As long as the perimeter of an object is solved as being done as one closed loop, the perimeter will need to have just one, prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly solves its calculations. Since both directions are equally valid, it is a programmer's decision. Some options might be:




          • Solving the path correctly counterclockwise and putting the slicing into a FILO memory, resulting in a clockwise operation starting from the last solved point.

          • Solving counterclockwise and saving into FIFO, running counterclockwise.

          • Solving deliberately clockwise for arbitrary reasons.


          Conclusion



          Slicers for 3D printing have a hard-coded direction that is followed when producing gcode. Any and all perimeters will be printed, starting from some arbitrary point, into that direction. In the end, it is a choice of the programmer of the slicing engine that determines if the path is to be run down "forward" or "backward" in mathematical sense.






          share|improve this answer











          $endgroup$













          • $begingroup$
            Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            @Thetravellingfool good remark, had to look it up, I mixed it up, fixed
            $endgroup$
            – Trish
            5 hours ago










          • $begingroup$
            Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            Trish, your answer is much appreciated. Is there a source you could provide for the information you gave?
            $endgroup$
            – Thetravellingfool
            48 mins ago














          3












          3








          3





          $begingroup$

          Math



          In math, there is a way how a path is to be followed, and that is usually counterclockwise:



          Assuming a perimeter path of a circle with $r=1$ around $(2,2)$, then the path can be defined as $f(p)={{cos(p)+2}choose{sin(p)+2}}$ - where $p$ is the path parameter, in this case an angle of 0 to 360°, and just increasing the angle rotates right hand around. If we had the same path but a different starting point, a shift by $theta$, then the path would read $f(p)={{cos(p+theta)+2}choose{sin(p+theta)+2}}$. So math is usually counterclockwise.



          Slicers



          Now, any slicer is applied math. As far as I can tell, Cura does slice with the result of a clockwise path, which is always performed. However, that does not invalidate the math at all, since solving a path with $p=0°to360°$ and solving it $p=360°to0°$ results in producing the exact same print, just opposed print direction of the perimeter.



          As long as the perimeter of an object is solved as being done as one closed loop, the perimeter will need to have just one, prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly solves its calculations. Since both directions are equally valid, it is a programmer's decision. Some options might be:




          • Solving the path correctly counterclockwise and putting the slicing into a FILO memory, resulting in a clockwise operation starting from the last solved point.

          • Solving counterclockwise and saving into FIFO, running counterclockwise.

          • Solving deliberately clockwise for arbitrary reasons.


          Conclusion



          Slicers for 3D printing have a hard-coded direction that is followed when producing gcode. Any and all perimeters will be printed, starting from some arbitrary point, into that direction. In the end, it is a choice of the programmer of the slicing engine that determines if the path is to be run down "forward" or "backward" in mathematical sense.






          share|improve this answer











          $endgroup$



          Math



          In math, there is a way how a path is to be followed, and that is usually counterclockwise:



          Assuming a perimeter path of a circle with $r=1$ around $(2,2)$, then the path can be defined as $f(p)={{cos(p)+2}choose{sin(p)+2}}$ - where $p$ is the path parameter, in this case an angle of 0 to 360°, and just increasing the angle rotates right hand around. If we had the same path but a different starting point, a shift by $theta$, then the path would read $f(p)={{cos(p+theta)+2}choose{sin(p+theta)+2}}$. So math is usually counterclockwise.



          Slicers



          Now, any slicer is applied math. As far as I can tell, Cura does slice with the result of a clockwise path, which is always performed. However, that does not invalidate the math at all, since solving a path with $p=0°to360°$ and solving it $p=360°to0°$ results in producing the exact same print, just opposed print direction of the perimeter.



          As long as the perimeter of an object is solved as being done as one closed loop, the perimeter will need to have just one, prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly solves its calculations. Since both directions are equally valid, it is a programmer's decision. Some options might be:




          • Solving the path correctly counterclockwise and putting the slicing into a FILO memory, resulting in a clockwise operation starting from the last solved point.

          • Solving counterclockwise and saving into FIFO, running counterclockwise.

          • Solving deliberately clockwise for arbitrary reasons.


          Conclusion



          Slicers for 3D printing have a hard-coded direction that is followed when producing gcode. Any and all perimeters will be printed, starting from some arbitrary point, into that direction. In the end, it is a choice of the programmer of the slicing engine that determines if the path is to be run down "forward" or "backward" in mathematical sense.







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited 1 hour ago

























          answered 6 hours ago









          TrishTrish

          5,086938




          5,086938












          • $begingroup$
            Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            @Thetravellingfool good remark, had to look it up, I mixed it up, fixed
            $endgroup$
            – Trish
            5 hours ago










          • $begingroup$
            Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            Trish, your answer is much appreciated. Is there a source you could provide for the information you gave?
            $endgroup$
            – Thetravellingfool
            48 mins ago


















          • $begingroup$
            Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            @Thetravellingfool good remark, had to look it up, I mixed it up, fixed
            $endgroup$
            – Trish
            5 hours ago










          • $begingroup$
            Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
            $endgroup$
            – Thetravellingfool
            5 hours ago










          • $begingroup$
            Trish, your answer is much appreciated. Is there a source you could provide for the information you gave?
            $endgroup$
            – Thetravellingfool
            48 mins ago
















          $begingroup$
          Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
          $endgroup$
          – Thetravellingfool
          5 hours ago




          $begingroup$
          Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
          $endgroup$
          – Thetravellingfool
          5 hours ago












          $begingroup$
          @Thetravellingfool good remark, had to look it up, I mixed it up, fixed
          $endgroup$
          – Trish
          5 hours ago




          $begingroup$
          @Thetravellingfool good remark, had to look it up, I mixed it up, fixed
          $endgroup$
          – Trish
          5 hours ago












          $begingroup$
          Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
          $endgroup$
          – Thetravellingfool
          5 hours ago




          $begingroup$
          Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
          $endgroup$
          – Thetravellingfool
          5 hours ago












          $begingroup$
          Trish, your answer is much appreciated. Is there a source you could provide for the information you gave?
          $endgroup$
          – Thetravellingfool
          48 mins ago




          $begingroup$
          Trish, your answer is much appreciated. Is there a source you could provide for the information you gave?
          $endgroup$
          – Thetravellingfool
          48 mins ago


















          draft saved

          draft discarded




















































          Thanks for contributing an answer to 3D Printing Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          Use MathJax to format equations. MathJax reference.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2f3dprinting.stackexchange.com%2fquestions%2f7971%2fhow-do-tool-path-algorithms-decide-which-direction-to-print-a-closed-loop-polygo%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          How to make a Squid Proxy server?

          Is this a new Fibonacci Identity?

          Touch on Surface Book