written a logic note for reference https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf

I took a quick look at your document and am really confused. It appears that you take what is basically one case----find a circle tangent into a corner defined by two lines----and somehow explode it into 9 (?) cases. I can't figure out what the difference is in the cases. It makes the task of rounding corners appear much more complicated than it is. Really what you need to do is at a corner where you want to round, find the center of the circle and the tangent points where the circle meets the lines. Simple formulas give these values generically. Then you add an arc there. You need one function that computes an arc at centerpoint P, starting at point Q1 and ending at point Q2. The case of CW vs CCW is automatically handled and is not a special consideration. The only way in which the rounding radii for two consecutive points matters is if they are too big and interfere. In my opinion, this is an error, though the RoundAnything library tries to modify your input to produce a result in this case---this means you don't get the rounding you asked for, so then if you try to tune the rounding it doesn't behave predictably. See https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > written a logic note for reference > > > https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

Initially, I also thought the same way, but check the condition on point p3, where it is essential to calculate the cross tangent and the points of arc will not lie on any of the lines of the section. I missed 1 point in this logic and will correct that I.e. When both the points are cw or ccw and both have radius specified, only in this case if the sum of radius is greater than the length of the line, an error needs to be raised, rest of the conditions there are no issues whatsoever if the size of the radius. On Sun, 1 Oct, 2023, 8:46 pm Adrian Mariano, <avm4@cornell.edu> wrote: > I took a quick look at your document and am really confused. It appears > that you take what is basically one case----find a circle tangent into a > corner defined by two lines----and somehow explode it into 9 (?) cases. I > can't figure out what the difference is in the cases. It makes the task of > rounding corners appear much more complicated than it is. Really what you > need to do is at a corner where you want to round, find the center of the > circle and the tangent points where the circle meets the lines. Simple > formulas give these values generically. Then you add an arc there. You > need one function that computes an arc at centerpoint P, starting at point > Q1 and ending at point Q2. The case of CW vs CCW is automatically handled > and is not a special consideration. > > The only way in which the rounding radii for two consecutive points > matters is if they are too big and interfere. In my opinion, this is an > error, though the RoundAnything library tries to modify your input to > produce a result in this case---this means you don't get the rounding you > asked for, so then if you try to tune the rounding it doesn't behave > predictably. > > See > https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners > > On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar < > sprabhakar2006@gmail.com> wrote: > >> written a logic note for reference >> >> >> https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf >> >> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

I think I finally understand after some pondering, what you are talking about. Your document is completely unclear at explaining the interesting point that you are making, unfortunately. There are two cases. The normal case is that the circles don't interfere. All situations where the circles don't interfere are described by one method with one simple solution that involves clipping back the segments based on where the circle tangent points are and adding the appropriate arcs. Now there's another case that maybe has a different solution if you allow it. It's not clear that this solution necessarily needs to be permitted or that it is a good/valid solution, but it does provide a way to "round" cases with interfering circles as long as the arc direction reverses. It adds a lot of complexity to the approach because you can have an arbitrarily long sequence of corners where no original points from the polygon are retained. That seems to complicate the code. Why did I put "round" in quotes? Well, this other approach means constructing the circles and then finding the SECOND line that is tangent to both circles (a point missing from your writeup---the original polygon is already a line parallel to both circles and the diagrams don't show that you are getting the other one). You can now construct a "rounding" where you start at one polygon segment, then have an arc section, then you have the cross-tangent (the new one), then transition to the arc of the other circle, and then back to the polygon. The reason this is possibly questionable as a "rounding" method is that it is introducing a new straight line segment that was not part of the original polygon. If you do this with very large radii then the result is actually almost entirely the new cross-tangent and almost no arc, so calling it a "rounding" may be misleading. Note also that there will still be some impossible cases that arise when the cross tangents cross each other from a sequence of polygon vertices, so there is still some condition where it is impossible---just harder to identify. And right before that case the "rounding" is actually going to only replace the initial polygon with a new polygon because no curved arc section remains, just the cross tangent. On Sun, Oct 1, 2023 at 11:27 AM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > Initially, I also thought the same way, but check the condition on point > p3, where it is essential to calculate the cross tangent and the points of > arc will not lie on any of the lines of the section. > > I missed 1 point in this logic and will correct that > I.e. > When both the points are cw or ccw and both have radius specified, only in > this case if the sum of radius is greater than the length of the line, an > error needs to be raised, rest of the conditions there are no issues > whatsoever if the size of the radius. > > > > On Sun, 1 Oct, 2023, 8:46 pm Adrian Mariano, <avm4@cornell.edu> wrote: > >> I took a quick look at your document and am really confused. It appears >> that you take what is basically one case----find a circle tangent into a >> corner defined by two lines----and somehow explode it into 9 (?) cases. I >> can't figure out what the difference is in the cases. It makes the task of >> rounding corners appear much more complicated than it is. Really what you >> need to do is at a corner where you want to round, find the center of the >> circle and the tangent points where the circle meets the lines. Simple >> formulas give these values generically. Then you add an arc there. You >> need one function that computes an arc at centerpoint P, starting at point >> Q1 and ending at point Q2. The case of CW vs CCW is automatically handled >> and is not a special consideration. >> >> The only way in which the rounding radii for two consecutive points >> matters is if they are too big and interfere. In my opinion, this is an >> error, though the RoundAnything library tries to modify your input to >> produce a result in this case---this means you don't get the rounding you >> asked for, so then if you try to tune the rounding it doesn't behave >> predictably. >> >> See >> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners >> >> On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> written a logic note for reference >>> >>> >>> https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf >>> >>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

There could be some cases where the radius specified is unnecessarily too big and may not make any sense. Apart from that this method will provide a good solution for rounding the corners. As far as the lines not part of the initial segment, then all the rounding is not part of the initial segment e.g. consider the image below [image: Screenshot 2023-10-01 at 9.51.28 PM.png] and how would you do something like the image below in the concept you mentioned. Probably you need to extend the line length which may not be the design intent and you have to go around different methods to achieve this. [image: Screenshot 2023-10-01 at 9.54.33 PM.png] As per me this gives a better merging of roundings and would suggest implementing the similar method if not the same in your library. On Sun, 1 Oct 2023 at 21:35, Adrian Mariano <avm4@cornell.edu> wrote: > I think I finally understand after some pondering, what you are talking > about. Your document is completely unclear at explaining the interesting > point that you are making, unfortunately. > > There are two cases. The normal case is that the circles don't > interfere. All situations where the circles don't interfere are described > by one method with one simple solution that involves clipping back the > segments based on where the circle tangent points are and adding the > appropriate arcs. > > Now there's another case that maybe has a different solution if you allow > it. It's not clear that this solution necessarily needs to be permitted or > that it is a good/valid solution, but it does provide a way to "round" > cases with interfering circles as long as the arc direction reverses. It > adds a lot of complexity to the approach because you can have an > arbitrarily long sequence of corners where no original points from the > polygon are retained. That seems to complicate the code. > > Why did I put "round" in quotes? Well, this other approach means > constructing the circles and then finding the SECOND line that is tangent > to both circles (a point missing from your writeup---the original polygon > is already a line parallel to both circles and the diagrams don't show that > you are getting the other one). You can now construct a "rounding" where > you start at one polygon segment, then have an arc section, then you have > the cross-tangent (the new one), then transition to the arc of the other > circle, and then back to the polygon. > > The reason this is possibly questionable as a "rounding" method is that it > is introducing a new straight line segment that was not part of the > original polygon. If you do this with very large radii then the result is > actually almost entirely the new cross-tangent and almost no arc, so > calling it a "rounding" may be misleading. > > Note also that there will still be some impossible cases that arise when > the cross tangents cross each other from a sequence of polygon vertices, so > there is still some condition where it is impossible---just harder to > identify. And right before that case the "rounding" is actually going to > only replace the initial polygon with a new polygon because no curved arc > section remains, just the cross tangent. > > > > > On Sun, Oct 1, 2023 at 11:27 AM Sanjeev Prabhakar < > sprabhakar2006@gmail.com> wrote: > >> Initially, I also thought the same way, but check the condition on point >> p3, where it is essential to calculate the cross tangent and the points of >> arc will not lie on any of the lines of the section. >> >> I missed 1 point in this logic and will correct that >> I.e. >> When both the points are cw or ccw and both have radius specified, only >> in this case if the sum of radius is greater than the length of the line, >> an error needs to be raised, rest of the conditions there are no issues >> whatsoever if the size of the radius. >> >> >> >> On Sun, 1 Oct, 2023, 8:46 pm Adrian Mariano, <avm4@cornell.edu> wrote: >> >>> I took a quick look at your document and am really confused. It appears >>> that you take what is basically one case----find a circle tangent into a >>> corner defined by two lines----and somehow explode it into 9 (?) cases. I >>> can't figure out what the difference is in the cases. It makes the task of >>> rounding corners appear much more complicated than it is. Really what you >>> need to do is at a corner where you want to round, find the center of the >>> circle and the tangent points where the circle meets the lines. Simple >>> formulas give these values generically. Then you add an arc there. You >>> need one function that computes an arc at centerpoint P, starting at point >>> Q1 and ending at point Q2. The case of CW vs CCW is automatically handled >>> and is not a special consideration. >>> >>> The only way in which the rounding radii for two consecutive points >>> matters is if they are too big and interfere. In my opinion, this is an >>> error, though the RoundAnything library tries to modify your input to >>> produce a result in this case---this means you don't get the rounding you >>> asked for, so then if you try to tune the rounding it doesn't behave >>> predictably. >>> >>> See >>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners >>> >>> On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar < >>> sprabhakar2006@gmail.com> wrote: >>> >>>> written a logic note for reference >>>> >>>> >>>> https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf >>>> >>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

a bigger radius like this would may still work [image: Screenshot 2023-10-01 at 10.09.42 PM.png] but this will not [image: Screenshot 2023-10-01 at 10.10.19 PM.png] but for these cases an error message can be raised On Sun, 1 Oct 2023 at 21:59, Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > There could be some cases where the radius specified is unnecessarily too > big and may not make any sense. > > Apart from that this method will provide a good solution for rounding the > corners. > > As far as the lines not part of the initial segment, then all the rounding > is not part of the initial segment e.g. consider the image below > > [image: Screenshot 2023-10-01 at 9.51.28 PM.png] > > and how would you do something like the image below in the concept you > mentioned. Probably you need to extend the line length which may not be the > design intent and you have to go around different methods to achieve this. > [image: Screenshot 2023-10-01 at 9.54.33 PM.png] > > As per me this gives a better merging of roundings and would suggest > implementing the similar method if not the same in your library. > > > On Sun, 1 Oct 2023 at 21:35, Adrian Mariano <avm4@cornell.edu> wrote: > >> I think I finally understand after some pondering, what you are talking >> about. Your document is completely unclear at explaining the interesting >> point that you are making, unfortunately. >> >> There are two cases. The normal case is that the circles don't >> interfere. All situations where the circles don't interfere are described >> by one method with one simple solution that involves clipping back the >> segments based on where the circle tangent points are and adding the >> appropriate arcs. >> >> Now there's another case that maybe has a different solution if you allow >> it. It's not clear that this solution necessarily needs to be permitted or >> that it is a good/valid solution, but it does provide a way to "round" >> cases with interfering circles as long as the arc direction reverses. It >> adds a lot of complexity to the approach because you can have an >> arbitrarily long sequence of corners where no original points from the >> polygon are retained. That seems to complicate the code. >> >> Why did I put "round" in quotes? Well, this other approach means >> constructing the circles and then finding the SECOND line that is tangent >> to both circles (a point missing from your writeup---the original polygon >> is already a line parallel to both circles and the diagrams don't show that >> you are getting the other one). You can now construct a "rounding" where >> you start at one polygon segment, then have an arc section, then you have >> the cross-tangent (the new one), then transition to the arc of the other >> circle, and then back to the polygon. >> >> The reason this is possibly questionable as a "rounding" method is that >> it is introducing a new straight line segment that was not part of the >> original polygon. If you do this with very large radii then the result is >> actually almost entirely the new cross-tangent and almost no arc, so >> calling it a "rounding" may be misleading. >> >> Note also that there will still be some impossible cases that arise when >> the cross tangents cross each other from a sequence of polygon vertices, so >> there is still some condition where it is impossible---just harder to >> identify. And right before that case the "rounding" is actually going to >> only replace the initial polygon with a new polygon because no curved arc >> section remains, just the cross tangent. >> >> >> >> >> On Sun, Oct 1, 2023 at 11:27 AM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> Initially, I also thought the same way, but check the condition on point >>> p3, where it is essential to calculate the cross tangent and the points of >>> arc will not lie on any of the lines of the section. >>> >>> I missed 1 point in this logic and will correct that >>> I.e. >>> When both the points are cw or ccw and both have radius specified, only >>> in this case if the sum of radius is greater than the length of the line, >>> an error needs to be raised, rest of the conditions there are no issues >>> whatsoever if the size of the radius. >>> >>> >>> >>> On Sun, 1 Oct, 2023, 8:46 pm Adrian Mariano, <avm4@cornell.edu> wrote: >>> >>>> I took a quick look at your document and am really confused. It >>>> appears that you take what is basically one case----find a circle tangent >>>> into a corner defined by two lines----and somehow explode it into 9 (?) >>>> cases. I can't figure out what the difference is in the cases. It makes >>>> the task of rounding corners appear much more complicated than it is. >>>> Really what you need to do is at a corner where you want to round, find the >>>> center of the circle and the tangent points where the circle meets the >>>> lines. Simple formulas give these values generically. Then you add an arc >>>> there. You need one function that computes an arc at centerpoint P, >>>> starting at point Q1 and ending at point Q2. The case of CW vs CCW is >>>> automatically handled and is not a special consideration. >>>> >>>> The only way in which the rounding radii for two consecutive points >>>> matters is if they are too big and interfere. In my opinion, this is an >>>> error, though the RoundAnything library tries to modify your input to >>>> produce a result in this case---this means you don't get the rounding you >>>> asked for, so then if you try to tune the rounding it doesn't behave >>>> predictably. >>>> >>>> See >>>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners >>>> >>>> On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar < >>>> sprabhakar2006@gmail.com> wrote: >>>> >>>>> written a logic note for reference >>>>> >>>>> >>>>> https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> >

In your first example, the rounding adds two arcs and each arc starts and ends on the original polygon, so all arc endpoints remain on the shape. With the approach you describe, it is possible to have a sequence of arcs in which NO arc endpoints are on the original curve. This isn't intrinsically bad, but I think makes the implementation more complicated. Your second case example is a good example for a situation where your method is a good one. I would have to decrease the size of one of the circles in this case. But as the interfering circles grow larger, I think the results as I said before become questionable as a rounding. The example you show in a later message where the second circle is very large is exactly the point I'm thinking of. It no longer looks like a rounding. Rather, two corners have been removed and replaced by a single line segment. (Yes, I know there are slight arcs at the end, but hardly noticeable.) Does your code correctly handle the case of a stairstep with varying oversized radii where no points lie on the original polygon? I feel like the payoff for implementing this feature is too small for its added complexity. On Sun, Oct 1, 2023 at 12:32 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > There could be some cases where the radius specified is unnecessarily too > big and may not make any sense. > > Apart from that this method will provide a good solution for rounding the > corners. > > As far as the lines not part of the initial segment, then all the rounding > is not part of the initial segment e.g. consider the image below > > [image: Screenshot 2023-10-01 at 9.51.28 PM.png] > > and how would you do something like the image below in the concept you > mentioned. Probably you need to extend the line length which may not be the > design intent and you have to go around different methods to achieve this. > [image: Screenshot 2023-10-01 at 9.54.33 PM.png] > > As per me this gives a better merging of roundings and would suggest > implementing the similar method if not the same in your library. > > > On Sun, 1 Oct 2023 at 21:35, Adrian Mariano <avm4@cornell.edu> wrote: > >> I think I finally understand after some pondering, what you are talking >> about. Your document is completely unclear at explaining the interesting >> point that you are making, unfortunately. >> >> There are two cases. The normal case is that the circles don't >> interfere. All situations where the circles don't interfere are described >> by one method with one simple solution that involves clipping back the >> segments based on where the circle tangent points are and adding the >> appropriate arcs. >> >> Now there's another case that maybe has a different solution if you allow >> it. It's not clear that this solution necessarily needs to be permitted or >> that it is a good/valid solution, but it does provide a way to "round" >> cases with interfering circles as long as the arc direction reverses. It >> adds a lot of complexity to the approach because you can have an >> arbitrarily long sequence of corners where no original points from the >> polygon are retained. That seems to complicate the code. >> >> Why did I put "round" in quotes? Well, this other approach means >> constructing the circles and then finding the SECOND line that is tangent >> to both circles (a point missing from your writeup---the original polygon >> is already a line parallel to both circles and the diagrams don't show that >> you are getting the other one). You can now construct a "rounding" where >> you start at one polygon segment, then have an arc section, then you have >> the cross-tangent (the new one), then transition to the arc of the other >> circle, and then back to the polygon. >> >> The reason this is possibly questionable as a "rounding" method is that >> it is introducing a new straight line segment that was not part of the >> original polygon. If you do this with very large radii then the result is >> actually almost entirely the new cross-tangent and almost no arc, so >> calling it a "rounding" may be misleading. >> >> Note also that there will still be some impossible cases that arise when >> the cross tangents cross each other from a sequence of polygon vertices, so >> there is still some condition where it is impossible---just harder to >> identify. And right before that case the "rounding" is actually going to >> only replace the initial polygon with a new polygon because no curved arc >> section remains, just the cross tangent. >> >> >> >> >> On Sun, Oct 1, 2023 at 11:27 AM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> Initially, I also thought the same way, but check the condition on point >>> p3, where it is essential to calculate the cross tangent and the points of >>> arc will not lie on any of the lines of the section. >>> >>> I missed 1 point in this logic and will correct that >>> I.e. >>> When both the points are cw or ccw and both have radius specified, only >>> in this case if the sum of radius is greater than the length of the line, >>> an error needs to be raised, rest of the conditions there are no issues >>> whatsoever if the size of the radius. >>> >>> >>> >>> On Sun, 1 Oct, 2023, 8:46 pm Adrian Mariano, <avm4@cornell.edu> wrote: >>> >>>> I took a quick look at your document and am really confused. It >>>> appears that you take what is basically one case----find a circle tangent >>>> into a corner defined by two lines----and somehow explode it into 9 (?) >>>> cases. I can't figure out what the difference is in the cases. It makes >>>> the task of rounding corners appear much more complicated than it is. >>>> Really what you need to do is at a corner where you want to round, find the >>>> center of the circle and the tangent points where the circle meets the >>>> lines. Simple formulas give these values generically. Then you add an arc >>>> there. You need one function that computes an arc at centerpoint P, >>>> starting at point Q1 and ending at point Q2. The case of CW vs CCW is >>>> automatically handled and is not a special consideration. >>>> >>>> The only way in which the rounding radii for two consecutive points >>>> matters is if they are too big and interfere. In my opinion, this is an >>>> error, though the RoundAnything library tries to modify your input to >>>> produce a result in this case---this means you don't get the rounding you >>>> asked for, so then if you try to tune the rounding it doesn't behave >>>> predictably. >>>> >>>> See >>>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners >>>> >>>> On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar < >>>> sprabhakar2006@gmail.com> wrote: >>>> >>>>> written a logic note for reference >>>>> >>>>> >>>>> https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf >>>>> >>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

is this what you are looking for? [image: Screenshot 2023-10-01 at 10.28.44 PM.png] On Sun, 1 Oct 2023 at 22:20, Adrian Mariano <avm4@cornell.edu> wrote: > In your first example, the rounding adds two arcs and each arc starts and > ends on the original polygon, so all arc endpoints remain on the shape. > With the approach you describe, it is possible to have a sequence of arcs > in which NO arc endpoints are on the original curve. This isn't > intrinsically bad, but I think makes the implementation more complicated. > > Your second case example is a good example for a situation where your > method is a good one. I would have to decrease the size of one of the > circles in this case. But as the interfering circles grow larger, I think > the results as I said before become questionable as a rounding. The > example you show in a later message where the second circle is very large > is exactly the point I'm thinking of. It no longer looks like a rounding. > Rather, two corners have been removed and replaced by a single line > segment. (Yes, I know there are slight arcs at the end, but hardly > noticeable.) > > Does your code correctly handle the case of a stairstep with varying > oversized radii where no points lie on the original polygon? I feel like > the payoff for implementing this feature is too small for its added > complexity. > > On Sun, Oct 1, 2023 at 12:32 PM Sanjeev Prabhakar < > sprabhakar2006@gmail.com> wrote: > >> There could be some cases where the radius specified is unnecessarily too >> big and may not make any sense. >> >> Apart from that this method will provide a good solution for rounding the >> corners. >> >> As far as the lines not part of the initial segment, then all the >> rounding is not part of the initial segment e.g. consider the image below >> >> [image: Screenshot 2023-10-01 at 9.51.28 PM.png] >> >> and how would you do something like the image below in the concept you >> mentioned. Probably you need to extend the line length which may not be the >> design intent and you have to go around different methods to achieve this. >> [image: Screenshot 2023-10-01 at 9.54.33 PM.png] >> >> As per me this gives a better merging of roundings and would suggest >> implementing the similar method if not the same in your library. >> >> >> On Sun, 1 Oct 2023 at 21:35, Adrian Mariano <avm4@cornell.edu> wrote: >> >>> I think I finally understand after some pondering, what you are talking >>> about. Your document is completely unclear at explaining the interesting >>> point that you are making, unfortunately. >>> >>> There are two cases. The normal case is that the circles don't >>> interfere. All situations where the circles don't interfere are described >>> by one method with one simple solution that involves clipping back the >>> segments based on where the circle tangent points are and adding the >>> appropriate arcs. >>> >>> Now there's another case that maybe has a different solution if you >>> allow it. It's not clear that this solution necessarily needs to be >>> permitted or that it is a good/valid solution, but it does provide a way to >>> "round" cases with interfering circles as long as the arc direction >>> reverses. It adds a lot of complexity to the approach because you can have >>> an arbitrarily long sequence of corners where no original points from the >>> polygon are retained. That seems to complicate the code. >>> >>> Why did I put "round" in quotes? Well, this other approach means >>> constructing the circles and then finding the SECOND line that is tangent >>> to both circles (a point missing from your writeup---the original polygon >>> is already a line parallel to both circles and the diagrams don't show that >>> you are getting the other one). You can now construct a "rounding" where >>> you start at one polygon segment, then have an arc section, then you have >>> the cross-tangent (the new one), then transition to the arc of the other >>> circle, and then back to the polygon. >>> >>> The reason this is possibly questionable as a "rounding" method is that >>> it is introducing a new straight line segment that was not part of the >>> original polygon. If you do this with very large radii then the result is >>> actually almost entirely the new cross-tangent and almost no arc, so >>> calling it a "rounding" may be misleading. >>> >>> Note also that there will still be some impossible cases that arise when >>> the cross tangents cross each other from a sequence of polygon vertices, so >>> there is still some condition where it is impossible---just harder to >>> identify. And right before that case the "rounding" is actually going to >>> only replace the initial polygon with a new polygon because no curved arc >>> section remains, just the cross tangent. >>> >>> >>> >>> >>> On Sun, Oct 1, 2023 at 11:27 AM Sanjeev Prabhakar < >>> sprabhakar2006@gmail.com> wrote: >>> >>>> Initially, I also thought the same way, but check the condition on >>>> point p3, where it is essential to calculate the cross tangent and the >>>> points of arc will not lie on any of the lines of the section. >>>> >>>> I missed 1 point in this logic and will correct that >>>> I.e. >>>> When both the points are cw or ccw and both have radius specified, only >>>> in this case if the sum of radius is greater than the length of the line, >>>> an error needs to be raised, rest of the conditions there are no issues >>>> whatsoever if the size of the radius. >>>> >>>> >>>> >>>> On Sun, 1 Oct, 2023, 8:46 pm Adrian Mariano, <avm4@cornell.edu> wrote: >>>> >>>>> I took a quick look at your document and am really confused. It >>>>> appears that you take what is basically one case----find a circle tangent >>>>> into a corner defined by two lines----and somehow explode it into 9 (?) >>>>> cases. I can't figure out what the difference is in the cases. It makes >>>>> the task of rounding corners appear much more complicated than it is. >>>>> Really what you need to do is at a corner where you want to round, find the >>>>> center of the circle and the tangent points where the circle meets the >>>>> lines. Simple formulas give these values generically. Then you add an arc >>>>> there. You need one function that computes an arc at centerpoint P, >>>>> starting at point Q1 and ending at point Q2. The case of CW vs CCW is >>>>> automatically handled and is not a special consideration. >>>>> >>>>> The only way in which the rounding radii for two consecutive points >>>>> matters is if they are too big and interfere. In my opinion, this is an >>>>> error, though the RoundAnything library tries to modify your input to >>>>> produce a result in this case---this means you don't get the rounding you >>>>> asked for, so then if you try to tune the rounding it doesn't behave >>>>> predictably. >>>>> >>>>> See >>>>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners >>>>> >>>>> On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar < >>>>> sprabhakar2006@gmail.com> wrote: >>>>> >>>>>> written a logic note for reference >>>>>> >>>>>> >>>>>> https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

Yes, that's it. In looking at it I can see that the arcs can still be potentially isolated because the cross tangent intersects the polygon segment, so that intersection point could be taken as the end of the arc. On Sun, Oct 1, 2023 at 1:01 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > is this what you are looking for? > [image: Screenshot 2023-10-01 at 10.28.44 PM.png] > > On Sun, 1 Oct 2023 at 22:20, Adrian Mariano <avm4@cornell.edu> wrote: > >> In your first example, the rounding adds two arcs and each arc starts and >> ends on the original polygon, so all arc endpoints remain on the shape. >> With the approach you describe, it is possible to have a sequence of arcs >> in which NO arc endpoints are on the original curve. This isn't >> intrinsically bad, but I think makes the implementation more complicated. >> >> Your second case example is a good example for a situation where your >> method is a good one. I would have to decrease the size of one of the >> circles in this case. But as the interfering circles grow larger, I think >> the results as I said before become questionable as a rounding. The >> example you show in a later message where the second circle is very large >> is exactly the point I'm thinking of. It no longer looks like a rounding. >> Rather, two corners have been removed and replaced by a single line >> segment. (Yes, I know there are slight arcs at the end, but hardly >> noticeable.) >> >> Does your code correctly handle the case of a stairstep with varying >> oversized radii where no points lie on the original polygon? I feel like >> the payoff for implementing this feature is too small for its added >> complexity. >> >> On Sun, Oct 1, 2023 at 12:32 PM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> There could be some cases where the radius specified is unnecessarily >>> too big and may not make any sense. >>> >>> Apart from that this method will provide a good solution for rounding >>> the corners. >>> >>> As far as the lines not part of the initial segment, then all the >>> rounding is not part of the initial segment e.g. consider the image below >>> >>> [image: Screenshot 2023-10-01 at 9.51.28 PM.png] >>> >>> and how would you do something like the image below in the concept you >>> mentioned. Probably you need to extend the line length which may not be the >>> design intent and you have to go around different methods to achieve this. >>> [image: Screenshot 2023-10-01 at 9.54.33 PM.png] >>> >>> As per me this gives a better merging of roundings and would suggest >>> implementing the similar method if not the same in your library. >>> >>> >>> On Sun, 1 Oct 2023 at 21:35, Adrian Mariano <avm4@cornell.edu> wrote: >>> >>>> I think I finally understand after some pondering, what you are talking >>>> about. Your document is completely unclear at explaining the interesting >>>> point that you are making, unfortunately. >>>> >>>> There are two cases. The normal case is that the circles don't >>>> interfere. All situations where the circles don't interfere are described >>>> by one method with one simple solution that involves clipping back the >>>> segments based on where the circle tangent points are and adding the >>>> appropriate arcs. >>>> >>>> Now there's another case that maybe has a different solution if you >>>> allow it. It's not clear that this solution necessarily needs to be >>>> permitted or that it is a good/valid solution, but it does provide a way to >>>> "round" cases with interfering circles as long as the arc direction >>>> reverses. It adds a lot of complexity to the approach because you can have >>>> an arbitrarily long sequence of corners where no original points from the >>>> polygon are retained. That seems to complicate the code. >>>> >>>> Why did I put "round" in quotes? Well, this other approach means >>>> constructing the circles and then finding the SECOND line that is tangent >>>> to both circles (a point missing from your writeup---the original polygon >>>> is already a line parallel to both circles and the diagrams don't show that >>>> you are getting the other one). You can now construct a "rounding" where >>>> you start at one polygon segment, then have an arc section, then you have >>>> the cross-tangent (the new one), then transition to the arc of the other >>>> circle, and then back to the polygon. >>>> >>>> The reason this is possibly questionable as a "rounding" method is that >>>> it is introducing a new straight line segment that was not part of the >>>> original polygon. If you do this with very large radii then the result is >>>> actually almost entirely the new cross-tangent and almost no arc, so >>>> calling it a "rounding" may be misleading. >>>> >>>> Note also that there will still be some impossible cases that arise >>>> when the cross tangents cross each other from a sequence of polygon >>>> vertices, so there is still some condition where it is impossible---just >>>> harder to identify. And right before that case the "rounding" is actually >>>> going to only replace the initial polygon with a new polygon because no >>>> curved arc section remains, just the cross tangent. >>>> >>>> >>>> >>>> >>>> On Sun, Oct 1, 2023 at 11:27 AM Sanjeev Prabhakar < >>>> sprabhakar2006@gmail.com> wrote: >>>> >>>>> Initially, I also thought the same way, but check the condition on >>>>> point p3, where it is essential to calculate the cross tangent and the >>>>> points of arc will not lie on any of the lines of the section. >>>>> >>>>> I missed 1 point in this logic and will correct that >>>>> I.e. >>>>> When both the points are cw or ccw and both have radius specified, >>>>> only in this case if the sum of radius is greater than the length of the >>>>> line, an error needs to be raised, rest of the conditions there are no >>>>> issues whatsoever if the size of the radius. >>>>> >>>>> >>>>> >>>>> On Sun, 1 Oct, 2023, 8:46 pm Adrian Mariano, <avm4@cornell.edu> wrote: >>>>> >>>>>> I took a quick look at your document and am really confused. It >>>>>> appears that you take what is basically one case----find a circle tangent >>>>>> into a corner defined by two lines----and somehow explode it into 9 (?) >>>>>> cases. I can't figure out what the difference is in the cases. It makes >>>>>> the task of rounding corners appear much more complicated than it is. >>>>>> Really what you need to do is at a corner where you want to round, find the >>>>>> center of the circle and the tangent points where the circle meets the >>>>>> lines. Simple formulas give these values generically. Then you add an arc >>>>>> there. You need one function that computes an arc at centerpoint P, >>>>>> starting at point Q1 and ending at point Q2. The case of CW vs CCW is >>>>>> automatically handled and is not a special consideration. >>>>>> >>>>>> The only way in which the rounding radii for two consecutive points >>>>>> matters is if they are too big and interfere. In my opinion, this is an >>>>>> error, though the RoundAnything library tries to modify your input to >>>>>> produce a result in this case---this means you don't get the rounding you >>>>>> asked for, so then if you try to tune the rounding it doesn't behave >>>>>> predictably. >>>>>> >>>>>> See >>>>>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#function-round_corners >>>>>> >>>>>> On Sun, Oct 1, 2023 at 10:15 AM Sanjeev Prabhakar < >>>>>> sprabhakar2006@gmail.com> wrote: >>>>>> >>>>>>> written a logic note for reference >>>>>>> >>>>>>> >>>>>>> https://github.com/sprabhakar2006/openSCAD/blob/main/explanation%20of%20approaches/logic%20note%20for%20creating%202d%20section%20from%20points.pdf >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>>>> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>>> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>>> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>>> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org >>> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

something like this is possible and many more [image: Screenshot 2023-10-01 at 10.48.15 PM.png] I think this can handle the regular cases along with the complex ones