ul. +100 Roger. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page

ound 1 sec to compute > > and display the results > > I hope this helps > > Thanks for your nice explanation of the algorithm. > > But what happens if I try to fillet this with radius of about 5: > > cube ([40,40,10]); > translate ([0,20,12]) rotate ([0,90,0]) cylinder (d1=15, d2=0, h=40); > > ? > > At x=0... the intersection line is not a line, but a plane. Or the > curve is not closed as you expect. > > Near x=0, there is probably no problem. > > But as x increases... ehh actually, directly from the start: the > bezier will partially lie INSIDE the orginal object. This means that > if you take that curve instead of the original object you'll have > taken material AWAY from the object. That is something that you don't > want to happen with a fillet.Think of adding a fillet as adding putty > to the sharp corner between the objects. This only ADDS to the > objects, never subtracts. > > > > > Roger. > > > On Sun, 23 Jul 2023 at 22:43, Sanjeev Prabhakar < > sprabhakar2006@gmail.com> > > wrote: > > > > > Sure > > > I will try to explain the logic maybe in a day or two for the benefit > of > > > all who maybe interested in geometry manipulations. > > > > > > > > > > > > > > > > _______________________________________________ > > OpenSCAD mailing list > > To unsubscribe send an email to discuss-leave@lists.openscad.org > > > -- > ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 > ** > ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** > f equals m times a. When your f is steady, and your m is going down > your a is going up. -- Chris Hadfield about flying up the space shuttle. > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >

and let them decide, but for the casual user that could be difficult to select what to use and when. What do GUI CAD systems come up with for this example with the cone? ciao, Torsten.

translate ([0,20,12]) rotate ([0,90,0]) cylinder (d1=15, d2=0, h=40); ? At x=0... the intersection line is not a line, but a plane. Or the curve is not closed as you expect. Near x=0, there is probably no problem. But as x increases... ehh actually, directly from the start: the bezier will partially lie INSIDE the orginal object. This means that if you take that curve instead of the original object you'll have taken material AWAY from the object. That is something that you don't want to happen with a fillet.Think of adding a fillet as adding putty to the sharp corner between the objects. This only ADDS to the objects, never subtracts. Roger. > On Sun, 23 Jul 2023 at 22:43, Sanjeev Prabhakar > wrote: > > > Sure > > I will try to explain the logic maybe in a day or two for the benefit of > > all who maybe interested in geometry manipulations. > > > > > > > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org -- ** R.E.Wolff@BitWizard.nl ** https://www.BitWizard.nl/ ** +31-15-2049110 ** ** Delftechpark 11 2628 XJ Delft, The Netherlands. KVK: 27239233 ** f equals m times a. When your f is steady, and your m is going down your a is going up. -- Chris Hadfield about flying up the space shuttle.

internal vertices to read them and work with the coordinates. Unfortunately this is not as easy, because often a model is developed in OpenCSG and there are no coordinates available in OpenSCG. If you accept the fact that a full render has to be performed to get coordinates of a submodule. It's just a matter of a PR. If somebody guarantees, that such a PR will actually be accepted/merged, time to develop on such a PR would not be an issue. My Main Problem with SCAD language is that variables cannot be reassigned, once they are set -> could probably be solved with most other interpreter languages. The main benefit I see with python is not the opposite of the previous statement. Python is just any interpreter language choice. but its very easy to learn and very easy to read. PLUS: it has many accompanying libraries which will help you to do fancy stuff with OpenSCAD. for example this one: http://guenther-sohler.net/openscad/examples/qrcode.txt these few lines of code creates an qr code display object , which you can scan with your mobile. (Yes, i have seen openscad qr code libs, but this one appears easier and has more options) And your second statement : OpenSCAD has datastructures is also valid. Polyhedra are composed of triangles which are stored as coordinates only! It would be much better to compose triangles from indices into a global vertex array. This is something I am right now working on.(some ctests are not passed for my PR) Information which could also be stored with the "indexed " polygons is: a lookup table from point -> which triangles use this point. And Yes, I like your fillet and I personally appreciate , if Sanjeev's knowledge could go into GeomtryEvaluator.cc In the End, I'd like to see openscad become more powerful by being able to change variables once they are set and to use external libs. And yes, I know that I am aware that people might see this as a security risk, but those people can stay safe and do not even need to bother when not activating it. The rest and the interested people instead can leverage the new power coming from python. Thank you for reading On Sun, Jul 23, 2023 at 9:08 PM Adrian Mariano wrote: > I've been working on BOSL2 for a while with Revar, and we have 60k lines > of OpenSCAD code. Based on that experience, I think that the problem with > the OpenSCAD language is NOT fundamentally that it is functional. The > benefit of python is NOT fundamentally that it is procedural. There are > two basic problems with OpenSCAD for doing more complicated user space > processing. One is the inability to gain access to geometry, so to do user > space design, everything from the ground up has to be done "outside" of the > OpenSCAD geometry engine. The second problem is about efficiency. > OpenSCAD has no data structures. Graphics algorithms assume access to > sophisticated and efficient data structures like a priority queue or a tree > or other kinds of things that are impossible to implement efficiently in > OpenSCAD. So, yeah, you can implement the data structure, but instead of > being O(log N) or whatever it will be O(N^2). So then trying to implement > that process that uses that data structure in user space becomes > intractable. It's not clear to me that this limitation is fundamentally > about the language being functional. > > Note that the filleting process displayed by Sanjeev is straight forward > to implement in principle. You just find the intersection of two things > and put a fillet there. Two complications arise for doing this in > userspace in OpenSCAD. The first is representing the things, because > again, you can't use the geometry engine to do it. Now maybe a solution to > that problem is coming? The second complication is dealing with > self-intersections of the resulting polyhedron, because that's intractable > in OpenSCAD. Really it seems like OpenSCAD should have a primitive that > accepts a series of profiles and links them together into a polyhedron, > even if it's self-intersecting. > > Here's examples of doing the fillet problem entirely in OpenSCAD > userspace. There are many examples at the link below. I show a single one > in this message. > > > https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#functionmodule-join_prism > > [image: image.png] > > > On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar < > sprabhakar2006@gmail.com> wrote: > >> Sure >> I will try to explain the logic maybe in a day or two for the benefit of >> all who maybe interested in geometry manipulations. >> >> >> >> _______________________________________________ >> 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 >

AD language is NOT fundamentally that it is functional. The > benefit of python is NOT fundamentally that it is procedural. There are > two basic problems with OpenSCAD for doing more complicated user space > processing. One is the inability to gain access to geometry, so to do user > space design, everything from the ground up has to be done "outside" of the > OpenSCAD geometry engine. The second problem is about efficiency. > OpenSCAD has no data structures. Graphics algorithms assume access to > sophisticated and efficient data structures like a priority queue or a tree > or other kinds of things that are impossible to implement efficiently in > OpenSCAD. So, yeah, you can implement the data structure, but instead of > being O(log N) or whatever it will be O(N^2). So then trying to implement > that process that uses that data structure in user space becomes > intractable. It's not clear to me that this limitation is fundamentally > about the language being functional. > > Note that the filleting process displayed by Sanjeev is straight forward > to implement in principle. You just find the intersection of two things > and put a fillet there. Two complications arise for doing this in > userspace in OpenSCAD. The first is representing the things, because > again, you can't use the geometry engine to do it. Now maybe a solution to > that problem is coming? The second complication is dealing with > self-intersections of the resulting polyhedron, because that's intractable > in OpenSCAD. Really it seems like OpenSCAD should have a primitive that > accepts a series of profiles and links them together into a polyhedron, > even if it's self-intersecting. > > Here's examples of doing the fillet problem entirely in OpenSCAD > userspace. There are many examples at the link below. I show a single one > in this message. > > > https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#functionmodule-join_prism > > [image: image.png] > > > On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar < > sprabhakar2006@gmail.com> wrote: > >> Sure >> I will try to explain the logic maybe in a day or two for the benefit of >> all who maybe interested in geometry manipulations. >> >> >> >> _______________________________________________ >> 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 fillet instead. On Sun, Jul 23, 2023 at 10:00 PM nop head wrote: > The fact that prints always break along layer lines means adding a fillet > that is made of layers hardly affects the strength in my opinion. > > On Sun, 23 Jul 2023, 20:24 Adrian Mariano, wrote: > >> Are you thinking that the layers break the propagation of stress through >> the model, causing stress to concentrate at each layer, instead of >> concentrating at a corner? Have you observed that models which fail by >> layers shearing do so and random places in the model? >> >> >> On Sun, Jul 23, 2023 at 3:18 PM nop head wrote: >> >>> I am not sure 3D fillets are any use in FDM printing because of the >>> layers. I only use 2D fillets to get rounded tool paths. >>> >>> On Sun, 23 Jul 2023, 20:08 Adrian Mariano, wrote: >>> >>>> I've been working on BOSL2 for a while with Revar, and we have 60k >>>> lines of OpenSCAD code. Based on that experience, I think that the problem >>>> with the OpenSCAD language is NOT fundamentally that it is functional. The >>>> benefit of python is NOT fundamentally that it is procedural. There are >>>> two basic problems with OpenSCAD for doing more complicated user space >>>> processing. One is the inability to gain access to geometry, so to do user >>>> space design, everything from the ground up has to be done "outside" of the >>>> OpenSCAD geometry engine. The second problem is about efficiency. >>>> OpenSCAD has no data structures. Graphics algorithms assume access to >>>> sophisticated and efficient data structures like a priority queue or a tree >>>> or other kinds of things that are impossible to implement efficiently in >>>> OpenSCAD. So, yeah, you can implement the data structure, but instead of >>>> being O(log N) or whatever it will be O(N^2). So then trying to implement >>>> that process that uses that data structure in user space becomes >>>> intractable. It's not clear to me that this limitation is fundamentally >>>> about the language being functional. >>>> >>>> Note that the filleting process displayed by Sanjeev is straight >>>> forward to implement in principle. You just find the intersection of two >>>> things and put a fillet there. Two complications arise for doing this in >>>> userspace in OpenSCAD. The first is representing the things, because >>>> again, you can't use the geometry engine to do it. Now maybe a solution to >>>> that problem is coming? The second complication is dealing with >>>> self-intersections of the resulting polyhedron, because that's intractable >>>> in OpenSCAD. Really it seems like OpenSCAD should have a primitive that >>>> accepts a series of profiles and links them together into a polyhedron, >>>> even if it's self-intersecting. >>>> >>>> Here's examples of doing the fillet problem entirely in OpenSCAD >>>> userspace. There are many examples at the link below. I show a single one >>>> in this message. >>>> >>>> >>>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#functionmodule-join_prism >>>> >>>> [image: image.png] >>>> >>>> >>>> On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar < >>>> sprabhakar2006@gmail.com> wrote: >>>> >>>>> Sure >>>>> I will try to explain the logic maybe in a day or two for the benefit >>>>> of all who maybe interested in geometry manipulations. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >

centrating at a corner? Have you observed that models which fail by > layers shearing do so and random places in the model? > > > On Sun, Jul 23, 2023 at 3:18 PM nop head wrote: > >> I am not sure 3D fillets are any use in FDM printing because of the >> layers. I only use 2D fillets to get rounded tool paths. >> >> On Sun, 23 Jul 2023, 20:08 Adrian Mariano, wrote: >> >>> I've been working on BOSL2 for a while with Revar, and we have 60k lines >>> of OpenSCAD code. Based on that experience, I think that the problem with >>> the OpenSCAD language is NOT fundamentally that it is functional. The >>> benefit of python is NOT fundamentally that it is procedural. There are >>> two basic problems with OpenSCAD for doing more complicated user space >>> processing. One is the inability to gain access to geometry, so to do user >>> space design, everything from the ground up has to be done "outside" of the >>> OpenSCAD geometry engine. The second problem is about efficiency. >>> OpenSCAD has no data structures. Graphics algorithms assume access to >>> sophisticated and efficient data structures like a priority queue or a tree >>> or other kinds of things that are impossible to implement efficiently in >>> OpenSCAD. So, yeah, you can implement the data structure, but instead of >>> being O(log N) or whatever it will be O(N^2). So then trying to implement >>> that process that uses that data structure in user space becomes >>> intractable. It's not clear to me that this limitation is fundamentally >>> about the language being functional. >>> >>> Note that the filleting process displayed by Sanjeev is straight forward >>> to implement in principle. You just find the intersection of two things >>> and put a fillet there. Two complications arise for doing this in >>> userspace in OpenSCAD. The first is representing the things, because >>> again, you can't use the geometry engine to do it. Now maybe a solution to >>> that problem is coming? The second complication is dealing with >>> self-intersections of the resulting polyhedron, because that's intractable >>> in OpenSCAD. Really it seems like OpenSCAD should have a primitive that >>> accepts a series of profiles and links them together into a polyhedron, >>> even if it's self-intersecting. >>> >>> Here's examples of doing the fillet problem entirely in OpenSCAD >>> userspace. There are many examples at the link below. I show a single one >>> in this message. >>> >>> >>> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#functionmodule-join_prism >>> >>> [image: image.png] >>> >>> >>> On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar < >>> sprabhakar2006@gmail.com> wrote: >>> >>>> Sure >>>> I will try to explain the logic maybe in a day or two for the benefit >>>> of all who maybe interested in geometry manipulations. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >

illets are any use in FDM printing because of the > layers. I only use 2D fillets to get rounded tool paths. > > On Sun, 23 Jul 2023, 20:08 Adrian Mariano, wrote: > >> I've been working on BOSL2 for a while with Revar, and we have 60k lines >> of OpenSCAD code. Based on that experience, I think that the problem with >> the OpenSCAD language is NOT fundamentally that it is functional. The >> benefit of python is NOT fundamentally that it is procedural. There are >> two basic problems with OpenSCAD for doing more complicated user space >> processing. One is the inability to gain access to geometry, so to do user >> space design, everything from the ground up has to be done "outside" of the >> OpenSCAD geometry engine. The second problem is about efficiency. >> OpenSCAD has no data structures. Graphics algorithms assume access to >> sophisticated and efficient data structures like a priority queue or a tree >> or other kinds of things that are impossible to implement efficiently in >> OpenSCAD. So, yeah, you can implement the data structure, but instead of >> being O(log N) or whatever it will be O(N^2). So then trying to implement >> that process that uses that data structure in user space becomes >> intractable. It's not clear to me that this limitation is fundamentally >> about the language being functional. >> >> Note that the filleting process displayed by Sanjeev is straight forward >> to implement in principle. You just find the intersection of two things >> and put a fillet there. Two complications arise for doing this in >> userspace in OpenSCAD. The first is representing the things, because >> again, you can't use the geometry engine to do it. Now maybe a solution to >> that problem is coming? The second complication is dealing with >> self-intersections of the resulting polyhedron, because that's intractable >> in OpenSCAD. Really it seems like OpenSCAD should have a primitive that >> accepts a series of profiles and links them together into a polyhedron, >> even if it's self-intersecting. >> >> Here's examples of doing the fillet problem entirely in OpenSCAD >> userspace. There are many examples at the link below. I show a single one >> in this message. >> >> >> https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#functionmodule-join_prism >> >> [image: image.png] >> >> >> On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar < >> sprabhakar2006@gmail.com> wrote: >> >>> Sure >>> I will try to explain the logic maybe in a day or two for the benefit of >>> all who maybe interested in geometry manipulations. >>> >>> >>> >>> _______________________________________________ >>> 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 >

ace processing. One is the inability to gain access to geometry, so to do user space design, everything from the ground up has to be done "outside" of the OpenSCAD geometry engine. The second problem is about efficiency. OpenSCAD has no data structures. Graphics algorithms assume access to sophisticated and efficient data structures like a priority queue or a tree or other kinds of things that are impossible to implement efficiently in OpenSCAD. So, yeah, you can implement the data structure, but instead of being O(log N) or whatever it will be O(N^2). So then trying to implement that process that uses that data structure in user space becomes intractable. It's not clear to me that this limitation is fundamentally about the language being functional. Note that the filleting process displayed by Sanjeev is straight forward to implement in principle. You just find the intersection of two things and put a fillet there. Two complications arise for doing this in userspace in OpenSCAD. The first is representing the things, because again, you can't use the geometry engine to do it. Now maybe a solution to that problem is coming? The second complication is dealing with self-intersections of the resulting polyhedron, because that's intractable in OpenSCAD. Really it seems like OpenSCAD should have a primitive that accepts a series of profiles and links them together into a polyhedron, even if it's self-intersecting. Here's examples of doing the fillet problem entirely in OpenSCAD userspace. There are many examples at the link below. I show a single one in this message. https://github.com/BelfrySCAD/BOSL2/wiki/rounding.scad#functionmodule-join_prism [image: image.png] On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar wrote: > Sure > I will try to explain the logic maybe in a day or two for the benefit of > all who maybe interested in geometry manipulations. > > > > _______________________________________________ > OpenSCAD mailing list > To unsubscribe send an email to discuss-leave@lists.openscad.org >