Re: python support for openscad
3D fillets aren’t only for strength, though. Sometimes they are just nice for aesthetic reasons.
-Revar
On Jul 23, 2023, at 1:00 PM, nop head <nop.head@gmail.com> 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, <avm4@cornell.edu> 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 <nop.head@gmail.com> 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, <avm4@cornell.edu> 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.png>
On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote:
SureI 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
I could care less if BOSL2 becomes obsolete or not. If efficient data structures and geometry access finally become available in OpenSCAD, then BOSL3 will be rewritten to use them. I will celebrate the improvements.
-Revar
On Jul 23, 2023, at 12:45 PM, Guenther Sohler <guenther.sohler@gmail.com> wrote:
Adriano, thank you for your input
I appreciate your work with Revar on BOSL2 and I understand your reasoning that BOSL2 could become obsolete,
but I am sure it will not. When openscad becomes more powerful, BOSL code might be able to code with fewer lines, but BOSL2 is still very important to openscad.
Yes, I would appreciate OpenSCAD to have access to the 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 <avm4@cornell.edu> 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.png>
On Sun, Jul 23, 2023 at 1:14 PM Sanjeev Prabhakar <sprabhakar2006@gmail.com> wrote:
SureI 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
please see the explanation.
Although it seems quite complicated, but it takes around 1 sec to compute
and display the results
I hope this helps
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.
On Mon, Jul 24, 2023 at 10:01:22PM +0530, Sanjeev Prabhakar wrote:
please see the explanation.
Although it seems quite complicated, but it takes around 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.
--
** 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.
The approach explained in my earlier message will not work in such cases.
[image: Screenshot 2023-07-24 at 11.32.15 PM.png]
On Mon, 24 Jul 2023 at 22:35, Rogier Wolff R.E.Wolff@bitwizard.nl wrote:
On Mon, Jul 24, 2023 at 10:01:22PM +0530, Sanjeev Prabhakar wrote:
please see the explanation.
Although it seems quite complicated, but it takes around 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 <
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.
--
** 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
On 24.07.23 20:06, Sanjeev Prabhakar wrote:
The approach explained in my earlier message will not work in such cases.
Thanks for the explanation, this is nicely visualized. I suppose
subdividing some of the surfaces might also be needed?
Are there solutions that are more general? For the experienced user
it's probably fine to give a couple of strategies 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.
On 7/24/23 12:32, Sanjeev Prabhakar wrote:
please see the explanation.
Although it seems quite complicated, but it takes around 1 sec to compute
and display the results
I hope this helps
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.
And this looks as if a set of tool paths could be defined in gcode from
it, RS-274-D IOW, respecting the machines spindle power & rpm ability
for depth of cut. # of loops and final finish accuracy determined by how
close the radius of the fillet matches the tool nose radius. If this can
be done in a useful time frame, the finished code to do this for
subtractive machining would be a good src of funds to bank for your
retirement.
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 http://geneslinuxbox.net:6309/
Haha, thanks
retirement is nearby also
On Tue, 25 Jul 2023 at 03:03, gene heskett gheskett@shentel.net wrote:
On 7/24/23 12:32, Sanjeev Prabhakar wrote:
please see the explanation.
Although it seems quite complicated, but it takes around 1 sec to compute
and display the results
I hope this helps
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.
And this looks as if a set of tool paths could be defined in gcode from
it, RS-274-D IOW, respecting the machines spindle power & rpm ability
for depth of cut. # of loops and final finish accuracy determined by how
close the radius of the fillet matches the tool nose radius. If this can
be done in a useful time frame, the finished code to do this for
subtractive machining would be a good src of funds to bank for your
retirement.
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 http://geneslinuxbox.net:6309/
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
rather than exactly matching the cone base with the cube it can be offset
to get the 3 lines and then shave off the extra cone.
This could be one solution I can think off
[image: Screenshot 2023-07-25 at 6.16.28 AM.png]
On Tue, 25 Jul 2023 at 00:36, Torsten Paul Torsten.Paul@gmx.de wrote:
On 24.07.23 20:06, Sanjeev Prabhakar wrote:
The approach explained in my earlier message will not work in such cases.
Thanks for the explanation, this is nicely visualized. I suppose
subdividing some of the surfaces might also be needed?
Are there solutions that are more general? For the experienced user
it's probably fine to give a couple of strategies 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.
OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org
On 7/24/23 20:49, Sanjeev Prabhakar wrote:
Haha, thanks
retirement is nearby also
While I as I look to my 89th in a couple months will be retired for 23
years. I am a C.E.T. with an 8th grade education, and don't have the
math skills to do what you are doing. Rather precocious electronically
before I was a teenager, my 8th grade algebra teacher thought he was a
George Carlin and far more interested in what was in the girls panties
than he was in actually teaching the algebra class he was being paid to
do. So I quit school and went to work fixing what was then a brand new
tech, TV's at 14 yo. You would not be far wrong to say I grew up with a
hot soldering iron in one hand and a scope probe in the other by the
time I hit 17. But real math? Nope... What little I can do was taught
to me by a TI SR51 or a log-log-duplex Pickett slipstick. What you are
doing might as well be black magic to me.
But if you have an electronics problem, I can probably help.
[...]
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 http://geneslinuxbox.net:6309/