On 1/21/2023 1:24 PM, Steve Lelievre wrote: > I like the cones because they only involve the one perimeter at the > wide end so the shape produced is completely 'correct' in geometrical > terms. OK, thanks. Do note that it only works if the two are aligned so that the points of the cones fall inside the other end's polygon.

The points of the cones can be very close to the base so they are close to being a flat disk. As long as they are inside the hull they get discarded. On Sat, 21 Jan 2023 at 22:11, Jordan Brown <openscad@jordan.maileater.net> wrote: > On 1/21/2023 1:24 PM, Steve Lelievre wrote: > > I like the cones because they only involve the one perimeter at the wide > end so the shape produced is completely 'correct' in geometrical terms. > > > OK, thanks. > > Do note that it only works if the two are aligned so that the points of > the cones fall inside the other end's polygon. > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

It is possible to write a generic extruder for the convex case using cones, but there are a couple things that limit this. For most interesting cases, you need many slices to produce the correct form and to avoid producing artifacts on the curved faces that arise. (See Jordan's example.) Where will these slices come from? Note that even with convex endcaps, the resulting shape need not be convex. You will need the point list of the data in order to produce the many needed slices, most likely, since no mechanism for "averaging" geometry exists. Given that you have a point list, simply computing the desired shape as a polyhedron is much more efficient than computing it as the union of 100 overlapping cones. The version I implemented (convex_offset_extrude in BOSL2) flips the cones around to handle the ends, extrema, whether the shape is increasing or decreasing. This all requires access to the actual point list. Note that the direct computation of the polyhedron also already exists in libraries (it's also here now). Many examples can be seen here (though the animated examples look really bad right now for some reason): https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com> wrote: > The points of the cones can be very close to the base so they are close to > being a flat disk. As long as they are inside the hull they get discarded. > > On Sat, 21 Jan 2023 at 22:11, Jordan Brown <openscad@jordan.maileater.net> > wrote: > >> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >> >> I like the cones because they only involve the one perimeter at the wide >> end so the shape produced is completely 'correct' in geometrical terms. >> >> >> OK, thanks. >> >> Do note that it only works if the two are aligned so that the points of >> the cones fall inside the other end's polygon. >> >> _______________________________________________ >> 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 >

nearest point approach will be produce this result: [image: Screenshot 2023-01-22 at 6.32.31 AM.png] rays emanating from center and intersection approach will produce this result: [image: Screenshot 2023-01-22 at 6.35.04 AM.png] in the 2nd approach 360 lines were intersected in the example. morelines will produce much refined results and should work in most of the cases On Sun, 22 Jan 2023 at 05:41, Adrian Mariano <avm4@cornell.edu> wrote: > It is possible to write a generic extruder for the convex case using > cones, but there are a couple things that limit this. For most > interesting cases, you need many slices to produce the correct form and to > avoid producing artifacts on the curved faces that arise. (See Jordan's > example.) Where will these slices come from? Note that even with convex > endcaps, the resulting shape need not be convex. You will need the point > list of the data in order to produce the many needed slices, most likely, > since no mechanism for "averaging" geometry exists. Given that you have a > point list, simply computing the desired shape as a polyhedron is much more > efficient than computing it as the union of 100 overlapping cones. The > version I implemented (convex_offset_extrude in BOSL2) flips the cones > around to handle the ends, extrema, whether the shape is increasing or > decreasing. This all requires access to the actual point list. > > Note that the direct computation of the polyhedron also already exists in > libraries (it's also here now). > > Many examples can be seen here (though the animated examples look really > bad right now for some reason): > > https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin > > On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com> wrote: > >> The points of the cones can be very close to the base so they are close >> to being a flat disk. As long as they are inside the hull they get >> discarded. >> >> On Sat, 21 Jan 2023 at 22:11, Jordan Brown <openscad@jordan.maileater.net> >> wrote: >> >>> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >>> >>> I like the cones because they only involve the one perimeter at the wide >>> end so the shape produced is completely 'correct' in geometrical terms. >>> >>> >>> OK, thanks. >>> >>> Do note that it only works if the two are aligned so that the points of >>> the cones fall inside the other end's polygon. >>> >>> _______________________________________________ >>> 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 >

The first approach to me looks much better, but you need to add a bunch of horizontal slices to correctly capture the curvature of the faces. As shown you have faces that are not coplanar. I personally do not like the look of the second approach, where an edge is split. Personal preference. But also, I think this model is bad because it has lots of very long skinny triangles. You can model more efficiently and the result is better, in my opinion, when the triangles are as close to equilateral as possible. Models like the above produce moire effects and can be hard to view, and if you decrease the triangle count, you get rippling across the surfaces. The rippling never goes away---just gets smaller as you shrink the triangles. A horizontal section of such a model will show zig-zag edges. But I guess the question is what point are you trying to make? Rogier suggested we should have a built-in OpenSCAD module that does things like this (maybe?). Another poster suggested joining convex shapes using convex hulls of cones as a claim that the desired feature already can be implemented partially. I have argued that a full implementation is complex because there are multiple way to align shapes and no single correct way, so you need different algorithms for alignment. I don't see any evidence to the contrary shown here. My point is not that the problem cannot be solved in many interesting and useful cases---I have done it. My point is that the problem is complicated, and it cannot be solved in all cases, so that makes a built-in seem unlikely to occur. Furthermore, a solution is necessarily complex in terms of its interface, since there are several ways we can imagine aligning points. This also makes a built-in seem unlikely. We can do lots of nice things with existing libraries and without a built in, though of course there is the limitation due to the inability to extract geometrical data from OpenSCAD objects. *THAT* may actually be fixed in a future version, so that seems like the path forward towards a generic solution to this kind of model that can work on geometry instead of path lists. On Sat, Jan 21, 2023 at 8:10 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > nearest point approach will be produce this result: > [image: Screenshot 2023-01-22 at 6.32.31 AM.png] > > > rays emanating from center and intersection approach will produce this > result: > [image: Screenshot 2023-01-22 at 6.35.04 AM.png] > > in the 2nd approach 360 lines were intersected in the example. morelines > will produce much refined results and should work in most of the cases > > > > > On Sun, 22 Jan 2023 at 05:41, Adrian Mariano <avm4@cornell.edu> wrote: > >> It is possible to write a generic extruder for the convex case using >> cones, but there are a couple things that limit this. For most >> interesting cases, you need many slices to produce the correct form and to >> avoid producing artifacts on the curved faces that arise. (See Jordan's >> example.) Where will these slices come from? Note that even with convex >> endcaps, the resulting shape need not be convex. You will need the point >> list of the data in order to produce the many needed slices, most likely, >> since no mechanism for "averaging" geometry exists. Given that you have a >> point list, simply computing the desired shape as a polyhedron is much more >> efficient than computing it as the union of 100 overlapping cones. The >> version I implemented (convex_offset_extrude in BOSL2) flips the cones >> around to handle the ends, extrema, whether the shape is increasing or >> decreasing. This all requires access to the actual point list. >> >> Note that the direct computation of the polyhedron also already exists in >> libraries (it's also here now). >> >> Many examples can be seen here (though the animated examples look really >> bad right now for some reason): >> >> https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin >> >> On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com> wrote: >> >>> The points of the cones can be very close to the base so they are close >>> to being a flat disk. As long as they are inside the hull they get >>> discarded. >>> >>> On Sat, 21 Jan 2023 at 22:11, Jordan Brown < >>> openscad@jordan.maileater.net> wrote: >>> >>>> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >>>> >>>> I like the cones because they only involve the one perimeter at the >>>> wide end so the shape produced is completely 'correct' in geometrical terms. >>>> >>>> >>>> OK, thanks. >>>> >>>> Do note that it only works if the two are aligned so that the points of >>>> the cones fall inside the other end's polygon. >>>> >>>> _______________________________________________ >>>> 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 >

I think a. if both the sections are convex the nearest point mapping approach should work b. if one section is convex and the other section is concave again the first approach should work where concave shape should be the primary one c. when both the shapes are concave the 2nd approach should be used when the shape is so concave like an "S" shape, I have a feeling that it would be extremely difficult or may be impossible to match without intersecting lines. You can still do it by matching the number of points, but it may not make any sense of the shape. On Sun, 22 Jan 2023 at 06:58, Adrian Mariano <avm4@cornell.edu> wrote: > The first approach to me looks much better, but you need to add a bunch of > horizontal slices to correctly capture the curvature of the faces. As > shown you have faces that are not coplanar. > > I personally do not like the look of the second approach, where an edge is > split. Personal preference. But also, I think this model is bad because > it has lots of very long skinny triangles. You can model more efficiently > and the result is better, in my opinion, when the triangles are as close to > equilateral as possible. Models like the above produce moire effects and > can be hard to view, and if you decrease the triangle count, you get > rippling across the surfaces. The rippling never goes away---just gets > smaller as you shrink the triangles. A horizontal section of such a model > will show zig-zag edges. > > But I guess the question is what point are you trying to make? Rogier > suggested we should have a built-in OpenSCAD module that does things like > this (maybe?). Another poster suggested joining convex shapes using convex > hulls of cones as a claim that the desired feature already can be > implemented partially. I have argued that a full implementation is complex > because there are multiple way to align shapes and no single correct way, > so you need different algorithms for alignment. I don't see any evidence > to the contrary shown here. My point is not that the problem cannot be > solved in many interesting and useful cases---I have done it. My point is > that the problem is complicated, and it cannot be solved in all cases, so > that makes a built-in seem unlikely to occur. Furthermore, a solution is > necessarily complex in terms of its interface, since there are several ways > we can imagine aligning points. This also makes a built-in seem unlikely. > > We can do lots of nice things with existing libraries and without a built > in, though of course there is the limitation due to the inability to > extract geometrical data from OpenSCAD objects. *THAT* may actually be > fixed in a future version, so that seems like the path forward towards a > generic solution to this kind of model that can work on geometry instead of > path lists. > > > On Sat, Jan 21, 2023 at 8:10 PM Sanjeev Prabhakar < > sprabhakar2006@gmail.com> wrote: > >> nearest point approach will be produce this result: >> [image: Screenshot 2023-01-22 at 6.32.31 AM.png] >> >> >> rays emanating from center and intersection approach will produce this >> result: >> [image: Screenshot 2023-01-22 at 6.35.04 AM.png] >> >> in the 2nd approach 360 lines were intersected in the example. morelines >> will produce much refined results and should work in most of the cases >> >> >> >> >> On Sun, 22 Jan 2023 at 05:41, Adrian Mariano <avm4@cornell.edu> wrote: >> >>> It is possible to write a generic extruder for the convex case using >>> cones, but there are a couple things that limit this. For most >>> interesting cases, you need many slices to produce the correct form and to >>> avoid producing artifacts on the curved faces that arise. (See Jordan's >>> example.) Where will these slices come from? Note that even with convex >>> endcaps, the resulting shape need not be convex. You will need the point >>> list of the data in order to produce the many needed slices, most likely, >>> since no mechanism for "averaging" geometry exists. Given that you have a >>> point list, simply computing the desired shape as a polyhedron is much more >>> efficient than computing it as the union of 100 overlapping cones. The >>> version I implemented (convex_offset_extrude in BOSL2) flips the cones >>> around to handle the ends, extrema, whether the shape is increasing or >>> decreasing. This all requires access to the actual point list. >>> >>> Note that the direct computation of the polyhedron also already exists >>> in libraries (it's also here now). >>> >>> Many examples can be seen here (though the animated examples look really >>> bad right now for some reason): >>> >>> https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin >>> >>> On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com> wrote: >>> >>>> The points of the cones can be very close to the base so they are close >>>> to being a flat disk. As long as they are inside the hull they get >>>> discarded. >>>> >>>> On Sat, 21 Jan 2023 at 22:11, Jordan Brown < >>>> openscad@jordan.maileater.net> wrote: >>>> >>>>> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >>>>> >>>>> I like the cones because they only involve the one perimeter at the >>>>> wide end so the shape produced is completely 'correct' in geometrical terms. >>>>> >>>>> >>>>> OK, thanks. >>>>> >>>>> Do note that it only works if the two are aligned so that the points >>>>> of the cones fall inside the other end's polygon. >>>>> >>>>> _______________________________________________ >>>>> 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 >

I think you need to think carefully and define what you mean by "nearest point mapping". It will NOT always work for convex shapes if by nearest point you mean take one shape (one with more points) and map every point to the nearest point. Trivial example: square in right half plane map to a shape in the left half plane: all the points of the right hand shape map to the single right-most point of the left hand shape. You don't get a valid mapping. To make this concept rigorous you need to assure that you use all the points of both shapes. I did this in my skin() method by looking for the mapping that maps all points from the larger shape onto the points of the smaller shape while assuring that every point in the smaller shape is covered. But now you no longer have a simple concept like "nearest point" to do the mapping. Instead a complicated optimization arises. This optimization is solved in my skin() algorithm. But as I am saying, it's complicated. When I started trying to write skin() I had no idea how complicated it was going to end up being. This optimization produces great results, I think, as long as the shapes are "discrete", like polygons with few edges. If you want to map two curved shapes to each other, the results are not great, and the run time also becomes uncomfortably long, since the algorithm has O(N^3) run time. For your second concept, given two polygons located in 3-space, perhaps not parallel to each other, how do you define the rays? I don't know how to do that. I did devise a method maybe sort of like what you are imagining that involves tangent planes. It produces reasonable results for continuous shapes, though I think very often results that can also be easily produced by other means. You are overlooking the case which I think tends to be best when a smooth curves is involved: connect them by arc length. This in my experience, often produces the best result. You have to somehow align them to decide on the starting point. Then you resample them by arc length to have the same number of points (or generate them that way) and then simply line up the points. This can often handle a concave shape, depending on how different the shapes are, and it tends to produce a nicer form than the tangent plane method. Depending on how you line things up you may get a twist---which could be a desirable outcome. On Sat, Jan 21, 2023 at 8:50 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > I think > a. if both the sections are convex the nearest point mapping > approach should work > > b. if one section is convex and the other section is concave again the > first approach should work where concave shape should be the primary one > > c. when both the shapes are concave the 2nd approach should be used > > when the shape is so concave like an "S" shape, I have a feeling that it > would be extremely difficult or may be impossible to match without > intersecting lines. You can still do it by matching the number of points, > but it may not make any sense of the shape. > > > > On Sun, 22 Jan 2023 at 06:58, Adrian Mariano <avm4@cornell.edu> wrote: > >> The first approach to me looks much better, but you need to add a bunch >> of horizontal slices to correctly capture the curvature of the faces. As >> shown you have faces that are not coplanar. >> >> I personally do not like the look of the second approach, where an edge >> is split. Personal preference. But also, I think this model is bad >> because it has lots of very long skinny triangles. You can model more >> efficiently and the result is better, in my opinion, when the triangles are >> as close to equilateral as possible. Models like the above produce moire >> effects and can be hard to view, and if you decrease the triangle count, >> you get rippling across the surfaces. The rippling never goes away---just >> gets smaller as you shrink the triangles. A horizontal section of such a >> model will show zig-zag edges. >> >> But I guess the question is what point are you trying to make? Rogier >> suggested we should have a built-in OpenSCAD module that does things like >> this (maybe?). Another poster suggested joining convex shapes using convex >> hulls of cones as a claim that the desired feature already can be >> implemented partially. I have argued that a full implementation is complex >> because there are multiple way to align shapes and no single correct way, >> so you need different algorithms for alignment. I don't see any evidence >> to the contrary shown here. My point is not that the problem cannot be >> solved in many interesting and useful cases---I have done it. My point is >> that the problem is complicated, and it cannot be solved in all cases, so >> that makes a built-in seem unlikely to occur. Furthermore, a solution is >> necessarily complex in terms of its interface, since there are several ways >> we can imagine aligning points. This also makes a built-in seem unlikely. >> >> We can do lots of nice things with existing libraries and without a built >> in, though of course there is the limitation due to the inability to >> extract geometrical data from OpenSCAD objects. *THAT* may actually be >> fixed in a future version, so that seems like the path forward towards a >> generic solution to this kind of model that can work on geometry instead of >> path lists. >> >> >> On Sat, Jan 21, 2023 at 8:10 PM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> nearest point approach will be produce this result: >>> [image: Screenshot 2023-01-22 at 6.32.31 AM.png] >>> >>> >>> rays emanating from center and intersection approach will produce this >>> result: >>> [image: Screenshot 2023-01-22 at 6.35.04 AM.png] >>> >>> in the 2nd approach 360 lines were intersected in the example. morelines >>> will produce much refined results and should work in most of the cases >>> >>> >>> >>> >>> On Sun, 22 Jan 2023 at 05:41, Adrian Mariano <avm4@cornell.edu> wrote: >>> >>>> It is possible to write a generic extruder for the convex case using >>>> cones, but there are a couple things that limit this. For most >>>> interesting cases, you need many slices to produce the correct form and to >>>> avoid producing artifacts on the curved faces that arise. (See Jordan's >>>> example.) Where will these slices come from? Note that even with convex >>>> endcaps, the resulting shape need not be convex. You will need the point >>>> list of the data in order to produce the many needed slices, most likely, >>>> since no mechanism for "averaging" geometry exists. Given that you have a >>>> point list, simply computing the desired shape as a polyhedron is much more >>>> efficient than computing it as the union of 100 overlapping cones. The >>>> version I implemented (convex_offset_extrude in BOSL2) flips the cones >>>> around to handle the ends, extrema, whether the shape is increasing or >>>> decreasing. This all requires access to the actual point list. >>>> >>>> Note that the direct computation of the polyhedron also already exists >>>> in libraries (it's also here now). >>>> >>>> Many examples can be seen here (though the animated examples look >>>> really bad right now for some reason): >>>> >>>> https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin >>>> >>>> On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com> wrote: >>>> >>>>> The points of the cones can be very close to the base so they are >>>>> close to being a flat disk. As long as they are inside the hull they get >>>>> discarded. >>>>> >>>>> On Sat, 21 Jan 2023 at 22:11, Jordan Brown < >>>>> openscad@jordan.maileater.net> wrote: >>>>> >>>>>> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >>>>>> >>>>>> I like the cones because they only involve the one perimeter at the >>>>>> wide end so the shape produced is completely 'correct' in geometrical terms. >>>>>> >>>>>> >>>>>> OK, thanks. >>>>>> >>>>>> Do note that it only works if the two are aligned so that the points >>>>>> of the cones fall inside the other end's polygon. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >

for nearest points mapping center of the 2 sections should almost match in case of convex shapes arc lengths i think is a very complicated idea. here is an example of 2 concave shapes joined with points with approach 2 mentioned in my previous post. [image: Screenshot 2023-01-22 at 8.24.24 AM.png] this is made by intersection of 720 rays and around 100 slices execution time is 1.5 sec in python, i dont know how long will it take in pure openscad code. On Sun, 22 Jan 2023 at 07:47, Adrian Mariano <avm4@cornell.edu> wrote: > I think you need to think carefully and define what you mean by "nearest > point mapping". It will NOT always work for convex shapes if by nearest > point you mean take one shape (one with more points) and map every point to > the nearest point. Trivial example: square in right half plane map to a > shape in the left half plane: all the points of the right hand shape map > to the single right-most point of the left hand shape. You don't get a > valid mapping. > > To make this concept rigorous you need to assure that you use all the > points of both shapes. I did this in my skin() method by looking for the > mapping that maps all points from the larger shape onto the points of the > smaller shape while assuring that every point in the smaller shape is > covered. But now you no longer have a simple concept like "nearest point" > to do the mapping. Instead a complicated optimization arises. This > optimization is solved in my skin() algorithm. But as I am saying, it's > complicated. When I started trying to write skin() I had no idea how > complicated it was going to end up being. This optimization produces great > results, I think, as long as the shapes are "discrete", like polygons with > few edges. If you want to map two curved shapes to each other, the results > are not great, and the run time also becomes uncomfortably long, since the > algorithm has O(N^3) run time. > > For your second concept, given two polygons located in 3-space, perhaps > not parallel to each other, how do you define the rays? I don't know how > to do that. I did devise a method maybe sort of like what you are > imagining that involves tangent planes. It produces reasonable results for > continuous shapes, though I think very often results that can also be > easily produced by other means. > > You are overlooking the case which I think tends to be best when a smooth > curves is involved: connect them by arc length. This in my experience, > often produces the best result. You have to somehow align them to decide > on the starting point. Then you resample them by arc length to have the > same number of points (or generate them that way) and then simply line up > the points. This can often handle a concave shape, depending on how > different the shapes are, and it tends to produce a nicer form than the > tangent plane method. Depending on how you line things up you may get a > twist---which could be a desirable outcome. > > On Sat, Jan 21, 2023 at 8:50 PM Sanjeev Prabhakar < > sprabhakar2006@gmail.com> wrote: > >> I think >> a. if both the sections are convex the nearest point mapping >> approach should work >> >> b. if one section is convex and the other section is concave again the >> first approach should work where concave shape should be the primary one >> >> c. when both the shapes are concave the 2nd approach should be used >> >> when the shape is so concave like an "S" shape, I have a feeling that it >> would be extremely difficult or may be impossible to match without >> intersecting lines. You can still do it by matching the number of points, >> but it may not make any sense of the shape. >> >> >> >> On Sun, 22 Jan 2023 at 06:58, Adrian Mariano <avm4@cornell.edu> wrote: >> >>> The first approach to me looks much better, but you need to add a bunch >>> of horizontal slices to correctly capture the curvature of the faces. As >>> shown you have faces that are not coplanar. >>> >>> I personally do not like the look of the second approach, where an edge >>> is split. Personal preference. But also, I think this model is bad >>> because it has lots of very long skinny triangles. You can model more >>> efficiently and the result is better, in my opinion, when the triangles are >>> as close to equilateral as possible. Models like the above produce moire >>> effects and can be hard to view, and if you decrease the triangle count, >>> you get rippling across the surfaces. The rippling never goes away---just >>> gets smaller as you shrink the triangles. A horizontal section of such a >>> model will show zig-zag edges. >>> >>> But I guess the question is what point are you trying to make? Rogier >>> suggested we should have a built-in OpenSCAD module that does things like >>> this (maybe?). Another poster suggested joining convex shapes using convex >>> hulls of cones as a claim that the desired feature already can be >>> implemented partially. I have argued that a full implementation is complex >>> because there are multiple way to align shapes and no single correct way, >>> so you need different algorithms for alignment. I don't see any evidence >>> to the contrary shown here. My point is not that the problem cannot be >>> solved in many interesting and useful cases---I have done it. My point is >>> that the problem is complicated, and it cannot be solved in all cases, so >>> that makes a built-in seem unlikely to occur. Furthermore, a solution is >>> necessarily complex in terms of its interface, since there are several ways >>> we can imagine aligning points. This also makes a built-in seem unlikely. >>> >>> We can do lots of nice things with existing libraries and without a >>> built in, though of course there is the limitation due to the inability to >>> extract geometrical data from OpenSCAD objects. *THAT* may actually be >>> fixed in a future version, so that seems like the path forward towards a >>> generic solution to this kind of model that can work on geometry instead of >>> path lists. >>> >>> >>> On Sat, Jan 21, 2023 at 8:10 PM Sanjeev Prabhakar < >>> sprabhakar2006@gmail.com> wrote: >>> >>>> nearest point approach will be produce this result: >>>> [image: Screenshot 2023-01-22 at 6.32.31 AM.png] >>>> >>>> >>>> rays emanating from center and intersection approach will produce this >>>> result: >>>> [image: Screenshot 2023-01-22 at 6.35.04 AM.png] >>>> >>>> in the 2nd approach 360 lines were intersected in the example. >>>> morelines will produce much refined results and should work in most of the >>>> cases >>>> >>>> >>>> >>>> >>>> On Sun, 22 Jan 2023 at 05:41, Adrian Mariano <avm4@cornell.edu> wrote: >>>> >>>>> It is possible to write a generic extruder for the convex case using >>>>> cones, but there are a couple things that limit this. For most >>>>> interesting cases, you need many slices to produce the correct form and to >>>>> avoid producing artifacts on the curved faces that arise. (See Jordan's >>>>> example.) Where will these slices come from? Note that even with convex >>>>> endcaps, the resulting shape need not be convex. You will need the point >>>>> list of the data in order to produce the many needed slices, most likely, >>>>> since no mechanism for "averaging" geometry exists. Given that you have a >>>>> point list, simply computing the desired shape as a polyhedron is much more >>>>> efficient than computing it as the union of 100 overlapping cones. The >>>>> version I implemented (convex_offset_extrude in BOSL2) flips the cones >>>>> around to handle the ends, extrema, whether the shape is increasing or >>>>> decreasing. This all requires access to the actual point list. >>>>> >>>>> Note that the direct computation of the polyhedron also already exists >>>>> in libraries (it's also here now). >>>>> >>>>> Many examples can be seen here (though the animated examples look >>>>> really bad right now for some reason): >>>>> >>>>> https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin >>>>> >>>>> On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com> wrote: >>>>> >>>>>> The points of the cones can be very close to the base so they are >>>>>> close to being a flat disk. As long as they are inside the hull they get >>>>>> discarded. >>>>>> >>>>>> On Sat, 21 Jan 2023 at 22:11, Jordan Brown < >>>>>> openscad@jordan.maileater.net> wrote: >>>>>> >>>>>>> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >>>>>>> >>>>>>> I like the cones because they only involve the one perimeter at the >>>>>>> wide end so the shape produced is completely 'correct' in geometrical terms. >>>>>>> >>>>>>> >>>>>>> OK, thanks. >>>>>>> >>>>>>> Do note that it only works if the two are aligned so that the points >>>>>>> of the cones fall inside the other end's polygon. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >

Jumping in the middle here, but... This is an old problem. I wrote several papers on this in the previous century. A seminal paper is by Fuchs, Kedem & Uselton (CACM, perhaps Nov. 1977). You can find a few small conference papers with my name on them - and one major paper that handled all sorts of stuff you probably con't care about. Start here: https://scholar.google.com/citations?view_op=view_citation&hl=en&user=elhUt8QAAAAJ&citation_for_view=elhUt8QAAAAJ:u-x6o8ySG0sC Most of what you need is in the references found there. A lot depends on your assumptions, and how much attention you want to pay to "features" in the two shapes. When faced with a new instance of this problem, I usually start with a simple method: a) find one "obvious" match between a point on A and a point on B b) normalize the two 2D curves to have length 1.0, with both 0.0 and 1.0 at the matching points found in a) c) connect a point on A to the point on B which is closest in normalized arc length This method does a better job of handling non-convex shapes than the method you seem to be using here (also an old, well-known, method). As a classic example of how assumptions matter, consider two shapes which are both perfect circles, with one small bump - but the bump is rotated by 30 degrees in A compared with the orientation in B. Do you want the resulting shape to have a single bump in A which disappears as you move to B, while a different bump appears? Or, to you want a cylinder with a smaller cylinder wrapped around it? In your example, suppose you have 2 5-pointed stars, but they are rotated slightly with respect to each other. Do you want the points of the stars to connect? or not? And so on... -- Kenneth Sloan KennethRSloan@gmail.com Vision is the art of seeing what is invisible to others. > On Jan 21, 2023, at 21:09, Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > > for nearest points mapping center of the 2 sections should almost match in case of convex shapes > > arc lengths i think is a very complicated idea. > > here is an example of 2 concave shapes joined with points with approach 2 mentioned in my previous post. > > <Screenshot 2023-01-22 at 8.24.24 AM.png> > > this is made by intersection of 720 rays and around 100 slices > execution time is 1.5 sec in python, i dont know how long will it take in pure openscad code. > > On Sun, 22 Jan 2023 at 07:47, Adrian Mariano <avm4@cornell.edu <mailto:avm4@cornell.edu>> wrote: >> I think you need to think carefully and define what you mean by "nearest point mapping". It will NOT always work for convex shapes if by nearest point you mean take one shape (one with more points) and map every point to the nearest point. Trivial example: square in right half plane map to a shape in the left half plane: all the points of the right hand shape map to the single right-most point of the left hand shape. You don't get a valid mapping. >> >> To make this concept rigorous you need to assure that you use all the points of both shapes. I did this in my skin() method by looking for the mapping that maps all points from the larger shape onto the points of the smaller shape while assuring that every point in the smaller shape is covered. But now you no longer have a simple concept like "nearest point" to do the mapping. Instead a complicated optimization arises. This optimization is solved in my skin() algorithm. But as I am saying, it's complicated. When I started trying to write skin() I had no idea how complicated it was going to end up being. This optimization produces great results, I think, as long as the shapes are "discrete", like polygons with few edges. If you want to map two curved shapes to each other, the results are not great, and the run time also becomes uncomfortably long, since the algorithm has O(N^3) run time. >> >> For your second concept, given two polygons located in 3-space, perhaps not parallel to each other, how do you define the rays? I don't know how to do that. I did devise a method maybe sort of like what you are imagining that involves tangent planes. It produces reasonable results for continuous shapes, though I think very often results that can also be easily produced by other means. >> >> You are overlooking the case which I think tends to be best when a smooth curves is involved: connect them by arc length. This in my experience, often produces the best result. You have to somehow align them to decide on the starting point. Then you resample them by arc length to have the same number of points (or generate them that way) and then simply line up the points. This can often handle a concave shape, depending on how different the shapes are, and it tends to produce a nicer form than the tangent plane method. Depending on how you line things up you may get a twist---which could be a desirable outcome. >> >> On Sat, Jan 21, 2023 at 8:50 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com <mailto:sprabhakar2006@gmail.com>> wrote: >>> I think >>> a. if both the sections are convex the nearest point mapping approach should work >>> >>> b. if one section is convex and the other section is concave again the first approach should work where concave shape should be the primary one >>> >>> c. when both the shapes are concave the 2nd approach should be used >>> >>> when the shape is so concave like an "S" shape, I have a feeling that it would be extremely difficult or may be impossible to match without intersecting lines. You can still do it by matching the number of points, but it may not make any sense of the shape. >>> >>> >>> >>> On Sun, 22 Jan 2023 at 06:58, Adrian Mariano <avm4@cornell.edu <mailto:avm4@cornell.edu>> wrote: >>>> The first approach to me looks much better, but you need to add a bunch of horizontal slices to correctly capture the curvature of the faces. As shown you have faces that are not coplanar. >>>> >>>> I personally do not like the look of the second approach, where an edge is split. Personal preference. But also, I think this model is bad because it has lots of very long skinny triangles. You can model more efficiently and the result is better, in my opinion, when the triangles are as close to equilateral as possible. Models like the above produce moire effects and can be hard to view, and if you decrease the triangle count, you get rippling across the surfaces. The rippling never goes away---just gets smaller as you shrink the triangles. A horizontal section of such a model will show zig-zag edges. >>>> >>>> But I guess the question is what point are you trying to make? Rogier suggested we should have a built-in OpenSCAD module that does things like this (maybe?). Another poster suggested joining convex shapes using convex hulls of cones as a claim that the desired feature already can be implemented partially. I have argued that a full implementation is complex because there are multiple way to align shapes and no single correct way, so you need different algorithms for alignment. I don't see any evidence to the contrary shown here. My point is not that the problem cannot be solved in many interesting and useful cases---I have done it. My point is that the problem is complicated, and it cannot be solved in all cases, so that makes a built-in seem unlikely to occur. Furthermore, a solution is necessarily complex in terms of its interface, since there are several ways we can imagine aligning points. This also makes a built-in seem unlikely. >>>> >>>> We can do lots of nice things with existing libraries and without a built in, though of course there is the limitation due to the inability to extract geometrical data from OpenSCAD objects. *THAT* may actually be fixed in a future version, so that seems like the path forward towards a generic solution to this kind of model that can work on geometry instead of path lists. >>>> >>>> >>>> On Sat, Jan 21, 2023 at 8:10 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com <mailto:sprabhakar2006@gmail.com>> wrote: >>>>> nearest point approach will be produce this result: >>>>> <Screenshot 2023-01-22 at 6.32.31 AM.png> >>>>> >>>>> >>>>> rays emanating from center and intersection approach will produce this result: >>>>> <Screenshot 2023-01-22 at 6.35.04 AM.png> >>>>> >>>>> in the 2nd approach 360 lines were intersected in the example. morelines will produce much refined results and should work in most of the cases >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, 22 Jan 2023 at 05:41, Adrian Mariano <avm4@cornell.edu <mailto:avm4@cornell.edu>> wrote: >>>>>> It is possible to write a generic extruder for the convex case using cones, but there are a couple things that limit this. For most interesting cases, you need many slices to produce the correct form and to avoid producing artifacts on the curved faces that arise. (See Jordan's example.) Where will these slices come from? Note that even with convex endcaps, the resulting shape need not be convex. You will need the point list of the data in order to produce the many needed slices, most likely, since no mechanism for "averaging" geometry exists. Given that you have a point list, simply computing the desired shape as a polyhedron is much more efficient than computing it as the union of 100 overlapping cones. The version I implemented (convex_offset_extrude in BOSL2) flips the cones around to handle the ends, extrema, whether the shape is increasing or decreasing. This all requires access to the actual point list. >>>>>> >>>>>> Note that the direct computation of the polyhedron also already exists in libraries (it's also here now). >>>>>> >>>>>> Many examples can be seen here (though the animated examples look really bad right now for some reason): >>>>>> >>>>>> https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin >>>>>> >>>>>> On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com <mailto:nop.head@gmail.com>> wrote: >>>>>>> The points of the cones can be very close to the base so they are close to being a flat disk. As long as they are inside the hull they get discarded. >>>>>>> >>>>>>> On Sat, 21 Jan 2023 at 22:11, Jordan Brown <openscad@jordan.maileater.net <mailto:openscad@jordan.maileater.net>> wrote: >>>>>>>> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >>>>>>>>> I like the cones because they only involve the one perimeter at the wide end so the shape produced is completely 'correct' in geometrical terms. >>>>>>>> >>>>>>>> OK, thanks. >>>>>>>> >>>>>>>> Do note that it only works if the two are aligned so that the points of the cones fall inside the other end's polygon. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> OpenSCAD mailing list >>>>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> >>>>>>> _______________________________________________ >>>>>>> OpenSCAD mailing list >>>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> >>>>>> _______________________________________________ >>>>>> OpenSCAD mailing list >>>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> >>>>> _______________________________________________ >>>>> OpenSCAD mailing list >>>>> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> >>>> _______________________________________________ >>>> OpenSCAD mailing list >>>> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> >>> _______________________________________________ >>> OpenSCAD mailing list >>> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> >> _______________________________________________ >> OpenSCAD mailing list >> To unsubscribe send an email to discuss-leave@lists.openscad.org <mailto:discuss-leave@lists.openscad.org> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org

I would consider that connection a poor one. The point of the star maps unnaturally to an arbitrary point in the middle of the curve, for example. The long protrusion maps oddly to a small segment of the star. It doesn't look good to me. However, I do think that mapping a discrete shape like the star to a continuous shape may be the more difficult case to produce a nice looking result, especially in the example you show where the continuous curve is actually a rounded version of a discrete curve. For discrete shapes I think the best result is obtained when the mapping is done before the shape is subsampled, so in the case of the star, you map the 10 points somewhere, and then I am not sure what you mean by "nearest points mapping centers of the 2 sections should almost match". If you are talking about dealing with offset shapes, I can tell you that you get a different result when you shift shapes around using my optimization. There is no "almost" because it's a discrete map. If you shift the shapes around, the edges you get change, so the resulting shape is completely different. You didn't say anything about how rays are defined for non-parallel shapes. Actually I think arc length is the simplest idea of the ones mentioned. Of course, "arc length" is approximate: is just the sum of the lengths of segments comprising the path. It is easy to compute and a simple matter to resample curves based on arc length to produce an alignment. Or, as I said, construct the curves originally to align based on length. I think for the case above probably the only way to get a good alignment is to manually choose alignment points between the curves and then sample by arc length between the alignment points. It's a little hard to be sure because I have no idea what the bottom curve is. On Sat, Jan 21, 2023 at 10:10 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote: > for nearest points mapping center of the 2 sections should almost match in > case of convex shapes > > arc lengths i think is a very complicated idea. > > here is an example of 2 concave shapes joined with points with approach 2 > mentioned in my previous post. > > [image: Screenshot 2023-01-22 at 8.24.24 AM.png] > > this is made by intersection of 720 rays and around 100 slices > execution time is 1.5 sec in python, i dont know how long will it take in > pure openscad code. > > On Sun, 22 Jan 2023 at 07:47, Adrian Mariano <avm4@cornell.edu> wrote: > >> I think you need to think carefully and define what you mean by "nearest >> point mapping". It will NOT always work for convex shapes if by nearest >> point you mean take one shape (one with more points) and map every point to >> the nearest point. Trivial example: square in right half plane map to a >> shape in the left half plane: all the points of the right hand shape map >> to the single right-most point of the left hand shape. You don't get a >> valid mapping. >> >> To make this concept rigorous you need to assure that you use all the >> points of both shapes. I did this in my skin() method by looking for the >> mapping that maps all points from the larger shape onto the points of the >> smaller shape while assuring that every point in the smaller shape is >> covered. But now you no longer have a simple concept like "nearest point" >> to do the mapping. Instead a complicated optimization arises. This >> optimization is solved in my skin() algorithm. But as I am saying, it's >> complicated. When I started trying to write skin() I had no idea how >> complicated it was going to end up being. This optimization produces great >> results, I think, as long as the shapes are "discrete", like polygons with >> few edges. If you want to map two curved shapes to each other, the results >> are not great, and the run time also becomes uncomfortably long, since the >> algorithm has O(N^3) run time. >> >> For your second concept, given two polygons located in 3-space, perhaps >> not parallel to each other, how do you define the rays? I don't know how >> to do that. I did devise a method maybe sort of like what you are >> imagining that involves tangent planes. It produces reasonable results for >> continuous shapes, though I think very often results that can also be >> easily produced by other means. >> >> You are overlooking the case which I think tends to be best when a smooth >> curves is involved: connect them by arc length. This in my experience, >> often produces the best result. You have to somehow align them to decide >> on the starting point. Then you resample them by arc length to have the >> same number of points (or generate them that way) and then simply line up >> the points. This can often handle a concave shape, depending on how >> different the shapes are, and it tends to produce a nicer form than the >> tangent plane method. Depending on how you line things up you may get a >> twist---which could be a desirable outcome. >> >> On Sat, Jan 21, 2023 at 8:50 PM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> I think >>> a. if both the sections are convex the nearest point mapping >>> approach should work >>> >>> b. if one section is convex and the other section is concave again the >>> first approach should work where concave shape should be the primary one >>> >>> c. when both the shapes are concave the 2nd approach should be used >>> >>> when the shape is so concave like an "S" shape, I have a feeling that it >>> would be extremely difficult or may be impossible to match without >>> intersecting lines. You can still do it by matching the number of points, >>> but it may not make any sense of the shape. >>> >>> >>> >>> On Sun, 22 Jan 2023 at 06:58, Adrian Mariano <avm4@cornell.edu> wrote: >>> >>>> The first approach to me looks much better, but you need to add a bunch >>>> of horizontal slices to correctly capture the curvature of the faces. As >>>> shown you have faces that are not coplanar. >>>> >>>> I personally do not like the look of the second approach, where an edge >>>> is split. Personal preference. But also, I think this model is bad >>>> because it has lots of very long skinny triangles. You can model more >>>> efficiently and the result is better, in my opinion, when the triangles are >>>> as close to equilateral as possible. Models like the above produce moire >>>> effects and can be hard to view, and if you decrease the triangle count, >>>> you get rippling across the surfaces. The rippling never goes away---just >>>> gets smaller as you shrink the triangles. A horizontal section of such a >>>> model will show zig-zag edges. >>>> >>>> But I guess the question is what point are you trying to make? Rogier >>>> suggested we should have a built-in OpenSCAD module that does things like >>>> this (maybe?). Another poster suggested joining convex shapes using convex >>>> hulls of cones as a claim that the desired feature already can be >>>> implemented partially. I have argued that a full implementation is complex >>>> because there are multiple way to align shapes and no single correct way, >>>> so you need different algorithms for alignment. I don't see any evidence >>>> to the contrary shown here. My point is not that the problem cannot be >>>> solved in many interesting and useful cases---I have done it. My point is >>>> that the problem is complicated, and it cannot be solved in all cases, so >>>> that makes a built-in seem unlikely to occur. Furthermore, a solution is >>>> necessarily complex in terms of its interface, since there are several ways >>>> we can imagine aligning points. This also makes a built-in seem unlikely. >>>> >>>> We can do lots of nice things with existing libraries and without a >>>> built in, though of course there is the limitation due to the inability to >>>> extract geometrical data from OpenSCAD objects. *THAT* may actually be >>>> fixed in a future version, so that seems like the path forward towards a >>>> generic solution to this kind of model that can work on geometry instead of >>>> path lists. >>>> >>>> >>>> On Sat, Jan 21, 2023 at 8:10 PM Sanjeev Prabhakar < >>>> sprabhakar2006@gmail.com> wrote: >>>> >>>>> nearest point approach will be produce this result: >>>>> [image: Screenshot 2023-01-22 at 6.32.31 AM.png] >>>>> >>>>> >>>>> rays emanating from center and intersection approach will produce this >>>>> result: >>>>> [image: Screenshot 2023-01-22 at 6.35.04 AM.png] >>>>> >>>>> in the 2nd approach 360 lines were intersected in the example. >>>>> morelines will produce much refined results and should work in most of the >>>>> cases >>>>> >>>>> >>>>> >>>>> >>>>> On Sun, 22 Jan 2023 at 05:41, Adrian Mariano <avm4@cornell.edu> wrote: >>>>> >>>>>> It is possible to write a generic extruder for the convex case using >>>>>> cones, but there are a couple things that limit this. For most >>>>>> interesting cases, you need many slices to produce the correct form and to >>>>>> avoid producing artifacts on the curved faces that arise. (See Jordan's >>>>>> example.) Where will these slices come from? Note that even with convex >>>>>> endcaps, the resulting shape need not be convex. You will need the point >>>>>> list of the data in order to produce the many needed slices, most likely, >>>>>> since no mechanism for "averaging" geometry exists. Given that you have a >>>>>> point list, simply computing the desired shape as a polyhedron is much more >>>>>> efficient than computing it as the union of 100 overlapping cones. The >>>>>> version I implemented (convex_offset_extrude in BOSL2) flips the cones >>>>>> around to handle the ends, extrema, whether the shape is increasing or >>>>>> decreasing. This all requires access to the actual point list. >>>>>> >>>>>> Note that the direct computation of the polyhedron also already >>>>>> exists in libraries (it's also here now). >>>>>> >>>>>> Many examples can be seen here (though the animated examples look >>>>>> really bad right now for some reason): >>>>>> >>>>>> https://github.com/revarbat/BOSL2/wiki/skin.scad#functionmodule-skin >>>>>> >>>>>> On Sat, Jan 21, 2023 at 5:27 PM nop head <nop.head@gmail.com> wrote: >>>>>> >>>>>>> The points of the cones can be very close to the base so they are >>>>>>> close to being a flat disk. As long as they are inside the hull they get >>>>>>> discarded. >>>>>>> >>>>>>> On Sat, 21 Jan 2023 at 22:11, Jordan Brown < >>>>>>> openscad@jordan.maileater.net> wrote: >>>>>>> >>>>>>>> On 1/21/2023 1:24 PM, Steve Lelievre wrote: >>>>>>>> >>>>>>>> I like the cones because they only involve the one perimeter at the >>>>>>>> wide end so the shape produced is completely 'correct' in geometrical terms. >>>>>>>> >>>>>>>> >>>>>>>> OK, thanks. >>>>>>>> >>>>>>>> Do note that it only works if the two are aligned so that the >>>>>>>> points of the cones fall inside the other end's polygon. >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >