How Do Tool Path Algorithms Decide Which Direction to Print a Closed-Loop Polygon
$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.
slicing
$endgroup$
add a comment |
$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.
slicing
$endgroup$
add a comment |
$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.
slicing
$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
slicing
edited 2 hours ago
Thetravellingfool
asked 4 hours ago
ThetravellingfoolThetravellingfool
1136
1136
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
$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°$ is the exact same path, just passing the perimeter in the different direction.
I can not tell why or where the direction in the slicer is done, but as long as the perimeter of an object is solved as being done as one closed loop, any perimeter will be solved in just one prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly determines the perimeter direction.
$endgroup$
$begingroup$
Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
@Thetravellingfool good remark, had to look it up, I mixed it up, fixed
$endgroup$
– Trish
2 hours ago
$begingroup$
Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
My answer is it's hardcoded
$endgroup$
– Trish
52 mins ago
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
$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°$ is the exact same path, just passing the perimeter in the different direction.
I can not tell why or where the direction in the slicer is done, but as long as the perimeter of an object is solved as being done as one closed loop, any perimeter will be solved in just one prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly determines the perimeter direction.
$endgroup$
$begingroup$
Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
@Thetravellingfool good remark, had to look it up, I mixed it up, fixed
$endgroup$
– Trish
2 hours ago
$begingroup$
Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
My answer is it's hardcoded
$endgroup$
– Trish
52 mins ago
add a comment |
$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°$ is the exact same path, just passing the perimeter in the different direction.
I can not tell why or where the direction in the slicer is done, but as long as the perimeter of an object is solved as being done as one closed loop, any perimeter will be solved in just one prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly determines the perimeter direction.
$endgroup$
$begingroup$
Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
@Thetravellingfool good remark, had to look it up, I mixed it up, fixed
$endgroup$
– Trish
2 hours ago
$begingroup$
Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
My answer is it's hardcoded
$endgroup$
– Trish
52 mins ago
add a comment |
$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°$ is the exact same path, just passing the perimeter in the different direction.
I can not tell why or where the direction in the slicer is done, but as long as the perimeter of an object is solved as being done as one closed loop, any perimeter will be solved in just one prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly determines the perimeter direction.
$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°$ is the exact same path, just passing the perimeter in the different direction.
I can not tell why or where the direction in the slicer is done, but as long as the perimeter of an object is solved as being done as one closed loop, any perimeter will be solved in just one prescribed direction. This direction will be clockwise or counterclockwise depending on how the slicer exactly determines the perimeter direction.
edited 2 hours ago
answered 3 hours ago
TrishTrish
5,076938
5,076938
$begingroup$
Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
@Thetravellingfool good remark, had to look it up, I mixed it up, fixed
$endgroup$
– Trish
2 hours ago
$begingroup$
Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
My answer is it's hardcoded
$endgroup$
– Trish
52 mins ago
add a comment |
$begingroup$
Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
@Thetravellingfool good remark, had to look it up, I mixed it up, fixed
$endgroup$
– Trish
2 hours ago
$begingroup$
Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
My answer is it's hardcoded
$endgroup$
– Trish
52 mins ago
$begingroup$
Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
Assuming the circle begins at θ = 0, doesn't increasing the angle through 360 rotate counterclockwise?
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
@Thetravellingfool good remark, had to look it up, I mixed it up, fixed
$endgroup$
– Trish
2 hours ago
$begingroup$
@Thetravellingfool good remark, had to look it up, I mixed it up, fixed
$endgroup$
– Trish
2 hours ago
$begingroup$
Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
Thank you for your contribution to the discussion Trish. Unfortunately, my question still stands.
$endgroup$
– Thetravellingfool
2 hours ago
$begingroup$
My answer is it's hardcoded
$endgroup$
– Trish
52 mins ago
$begingroup$
My answer is it's hardcoded
$endgroup$
– Trish
52 mins ago
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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