Rectangle with one curved edge

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

adrianv
lar3ry wrote

> adrianv wrote
>> lar3ry wrote
>>> I have been doing a lot of modification on existing STL files, and the
>>> easiest way I have found is to do pretty much all trial and error. I
>>> guess
>>> that may be (bad)habit-forming. I am also the product of a lot of years
>>> of
>>> self-taught programming in everything from assembler on up.
>>
>> You're importing STL files into OpenSCAD and modifying them?   That seems
>> like it would be difficult to do in a nice fashion.  
>
> Actually, I'm quite comfortable with the technique. I am curently in the
> process of building a Hypercube Evolution printer, which is running. I
> want
> to make some improvements, one of which is to use a piezo disk as a Z-stop
> or bed probe. There is one available for the hotend mount, but I wanted to
> make it an under-bed mount. So I took an aready-modified bed mount and
> used
> union and difference to add some parts.
> <example deleted>

Interesting example.  Note for anyone running it that that there is a subtle
filename mismatch.  

I had never tried importing an STL file into OpenSCAD, so it was nice to see
this.  But what I meant when I said it wasn't going to be "nice" is that
trial and error is going to be unavoidable, since you won't (presumably)
know where anything is in the imported model, or have any way to orient
things to it.  

>> But if you meant SCAD files then I think it relates to coding style.  I
>> started a discussion here about learning how to use OpenSCAD because I
>> have
>> been struggling with these issues myself---both finding that I am doing
>> things by trial and error, and also finding that I can't read my own code
>> a
>> day later.  And I think it has to do with writing code that is at too low
>> a
>> level.  To avoid this, it's necessary to use libraries to abstract the
>> design.   But people here don't seem to be supportive of this approach.  
>> There's an idea that you should do everything directly on your own.
>> Things
>> like obiscad's attach library or the BOSL library I think are important
>> for
>> helping us to write code that is easier to read, modify and reuse.  
>
> I know exactly what you mean. I always struggle with trying to achieve a
> balance. I am definitely old-school in that I have a hard time wrapping my
> mind around object oriented languages. Instead of using objects, I tend to
> use subroutines and functions, but I do try to make re-usable ones, and
> libraries are definitely a nice was to encapsulate groups of modules.
>
> I LOVE the BOSL library, but haven't had a good look at the attach
> library.
> I am going to get a lot of mileage out of the Round-Anything lib.

Well, no "objects" in the sense of object oriented programming are available
in OpenSCAD, so you can stay old school.  :)  

What do you mean when you say "it's hard to find balance"?  To me it seems
like the higher level I can write my code at the better, so it's not about
balance, but about pushing for libraries with more and more abstraction or
more power.  

A major problem is that there seems to be little interest  in libraries and
a weak infrastructure.  It's hard to know that libraries exist and of those
that do, hard to figure out which ones you should be looking at to use.
Everybody is reinventing the wheel.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

nophead
BOSL creates a lot of trivial shortcuts for common operations. So instead of having to remember a small number of flexible primitives you now have a much larger language of simpler operations. That may suit some people but my brain works by remembering how to work things out rather than lots of arbitrary facts. For example, at school I didn't memorise trig formulas but I could remember how to work them out from first principles if I needed to. I have never known the number of days in a month because there is no proper rule or formula I know of.

I use my own library to make my projects but it doesn't go about redefining and extending the OpenSCAD language. Instead it is mainly models of real world objects like fasteners and electronic components. I am quite happy modelling those in OpenSCADs simple low level language and don't feel need to abstract further. Even the most complicated models are mainly combinations of circles, squares, cubes, cylinders and spheres, translated and rotated.

I do have translate_z(z) as a shortcut for translate([0, 0, z]) but that is about as far as it goes.

People have very different ways and thinking, so common libraries are only popular when they do something that an individual doesn't have the time or ability to do correctly themselves. Most things in BOSL are not hard to do directly in OpenSCAD.


On Sat, 9 Mar 2019 at 12:29, adrianv <[hidden email]> wrote:
lar3ry wrote
> adrianv wrote
>> lar3ry wrote
>>> I have been doing a lot of modification on existing STL files, and the
>>> easiest way I have found is to do pretty much all trial and error. I
>>> guess
>>> that may be (bad)habit-forming. I am also the product of a lot of years
>>> of
>>> self-taught programming in everything from assembler on up.
>>
>> You're importing STL files into OpenSCAD and modifying them?   That seems
>> like it would be difficult to do in a nice fashion. 
>
> Actually, I'm quite comfortable with the technique. I am curently in the
> process of building a Hypercube Evolution printer, which is running. I
> want
> to make some improvements, one of which is to use a piezo disk as a Z-stop
> or bed probe. There is one available for the hotend mount, but I wanted to
> make it an under-bed mount. So I took an aready-modified bed mount and
> used
> union and difference to add some parts.
> <example deleted>

Interesting example.  Note for anyone running it that that there is a subtle
filename mismatch. 

I had never tried importing an STL file into OpenSCAD, so it was nice to see
this.  But what I meant when I said it wasn't going to be "nice" is that
trial and error is going to be unavoidable, since you won't (presumably)
know where anything is in the imported model, or have any way to orient
things to it. 

>> But if you meant SCAD files then I think it relates to coding style.  I
>> started a discussion here about learning how to use OpenSCAD because I
>> have
>> been struggling with these issues myself---both finding that I am doing
>> things by trial and error, and also finding that I can't read my own code
>> a
>> day later.  And I think it has to do with writing code that is at too low
>> a
>> level.  To avoid this, it's necessary to use libraries to abstract the
>> design.   But people here don't seem to be supportive of this approach. 
>> There's an idea that you should do everything directly on your own.
>> Things
>> like obiscad's attach library or the BOSL library I think are important
>> for
>> helping us to write code that is easier to read, modify and reuse. 
>
> I know exactly what you mean. I always struggle with trying to achieve a
> balance. I am definitely old-school in that I have a hard time wrapping my
> mind around object oriented languages. Instead of using objects, I tend to
> use subroutines and functions, but I do try to make re-usable ones, and
> libraries are definitely a nice was to encapsulate groups of modules.
>
> I LOVE the BOSL library, but haven't had a good look at the attach
> library.
> I am going to get a lot of mileage out of the Round-Anything lib.

Well, no "objects" in the sense of object oriented programming are available
in OpenSCAD, so you can stay old school.  :) 

What do you mean when you say "it's hard to find balance"?  To me it seems
like the higher level I can write my code at the better, so it's not about
balance, but about pushing for libraries with more and more abstraction or
more power. 

A major problem is that there seems to be little interest  in libraries and
a weak infrastructure.  It's hard to know that libraries exist and of those
that do, hard to figure out which ones you should be looking at to use.
Everybody is reinventing the wheel.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

lar3ry
In reply to this post by adrianv
adrianv wrote

> lar3ry wrote
>> adrianv wrote
>>> lar3ry wrote
>>> You're importing STL files into OpenSCAD and modifying them?   That
>>> seems
>>> like it would be difficult to do in a nice fashion.  
>>
>> Actually, I'm quite comfortable with the technique. I am curently in the
>> process of building a Hypercube Evolution printer, which is running. I
>> want
>> to make some improvements, one of which is to use a piezo disk as a
>> Z-stop
>> or bed probe. There is one available for the hotend mount, but I wanted
>> to
>> make it an under-bed mount. So I took an aready-modified bed mount and
>> used
>> union and difference to add some parts.
>>
> <example deleted>
> Interesting example.  Note for anyone running it that that there is a
> subtle
> filename mismatch.  

Fixed that. When I uploaded the stl file, the forum decided to mess with the
name, likely because of the "." in "1.0", so I changed it to a "-".


> I had never tried importing an STL file into OpenSCAD, so it was nice to
> see
> this.  But what I meant when I said it wasn't going to be "nice" is that
> trial and error is going to be unavoidable, since you won't (presumably)
> know where anything is in the imported model, or have any way to orient
> things to it.  

Yes, unavoidable, but it's relatively easy to measure things in terms of
both sizes and position. If I want to find, for example, the size and
position of a cube, I simply make a cube, play with position and size until
I get it bang on. The"#" modifier helps a lot with that, because of the
shimmery congruent surfaces in preview. Often it isn't necessary to be that
exact. Filling a hole can usually be done with something that need not be
accurate in at least two dimensions.


>>> But if you meant SCAD files then I think it relates to coding style.  I
>>> started a discussion here about learning how to use OpenSCAD because I
>>> have been struggling with these issues myself---both finding that I am
>>> doing
>>> things by trial and error, and also finding that I can't read my own
>>> code a
>>> day later.  And I think it has to do with writing code that is at too
>>> low a
>>> level.  To avoid this, it's necessary to use libraries to abstract the
>>> design.   But people here don't seem to be supportive of this approach.  
>>> There's an idea that you should do everything directly on your own.
>>> Things like obiscad's attach library or the BOSL library I think are
>>> important
>>> for helping us to write code that is easier to read, modify and reuse.  
>>
>> I know exactly what you mean. I always struggle with trying to achieve a
>> balance. I am definitely old-school in that I have a hard time wrapping
>> my
>> mind around object oriented languages. Instead of using objects, I tend
>> to
>> use subroutines and functions, but I do try to make re-usable ones, and
>> libraries are definitely a nice was to encapsulate groups of modules.
>
>> I LOVE the BOSL library, but haven't had a good look at the attach
>> library. I am going to get a lot of mileage out of the Round-Anything
>> lib.
>
> Well, no "objects" in the sense of object oriented programming are
> available
> in OpenSCAD, so you can stay old school.  :)  
>
> What do you mean when you say "it's hard to find balance"?  To me it seems
> like the higher level I can write my code at the better, so it's not about
> balance, but about pushing for libraries with more and more abstraction or
> more power.  
>
> A major problem is that there seems to be little interest  in libraries
> and
> a weak infrastructure.  It's hard to know that libraries exist and of
> those
> that do, hard to figure out which ones you should be looking at to use.
> Everybody is reinventing the wheel.

Finding the balance.. I am very comfortable with lower level languages,
right down to assembler and even lower, if you count the first program I
ever wrote, which was a program to find prime numbers. I wrote it on an IBM
6420 Electronic Accounting Machine
(https://www.computerhistory.org/collections/catalog/102645466), using a
plugboard that let you direct program steps and select operators and
operands for each step. The whole thing ran on relays for the program, and
cards with discrete transistor circuitry to actually perform the operations.
Just as an interesting side note. I left that program running overnight,
from about 5PM until 8:30AM, and it had managed to get all the way up to
853. It was a brute force approach, and a better algorithm would have
helped.

On the other hand, I am comfortable with high level languages that operate
in ways that I can intuitively understand. It's the intermediate languages
that give me problems. I was never very comfortable with the whole C/C++/C#,
family, but Visual Basic evolved into something I am very much at ease with.

So when I am writing SCAD, I use whatever feels right at the time. If I know
of a library or saved module that I understand and can use, I'll use it, but
if I don't, well, I'll just write it at low level, and if appropriate, save
whatever modules that are generic enough to be used elsewhere. I don't
always make the right choice, but libraries help a by showing me possible
ways to do things.






--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

lar3ry
In reply to this post by nophead
nophead wrote
> I have never known the number of days in a month because there is no
> proper
> rule or formula I know of.

I can help you with that! I've been using the 'knuckle' method most of my
life.
https://www.youtube.com/watch?v=UfOpjDv8RxQ


> I use my own library to make my projects but it doesn't go about
> redefining
> and extending the OpenSCAD language. Instead it is mainly models of real
> world objects like fasteners and electronic components. I am quite happy
> modelling those in OpenSCADs simple low level language and don't feel need
> to abstract further. Even the most complicated models are mainly
> combinations of circles, squares, cubes, cylinders and spheres, translated
> and rotated.
>
> I do have translate_z(z) as a shortcut for translate([0, 0, z]) but that
> is
> about as far as it goes.

Never thought of doing something like that, but it's something I might like
to use, just to save me the typing time and the possibilityof errors. I
usually do a translate (or any other op using vectors) Like this...

translate([]) then backspace twice and put in the values

I find it reduces the errors.


> People have very different ways and thinking, so common libraries are only
> popular when they do something that an individual doesn't have the time or
> ability to do correctly themselves. Most things in BOSL are not hard to do
> directly in OpenSCAD.

True enough, though I often use libraries or saved modules when I don't need
the operation very often, and really don't want to reinvent it.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

nophead
> I can help you with that! I've been using the 'knuckle' method most of my life.
Thanks, I always learn a lot here!

On Sat, 9 Mar 2019 at 16:22, lar3ry <[hidden email]> wrote:
nophead wrote
> I have never known the number of days in a month because there is no
> proper
> rule or formula I know of.

I can help you with that! I've been using the 'knuckle' method most of my
life.
https://www.youtube.com/watch?v=UfOpjDv8RxQ


> I use my own library to make my projects but it doesn't go about
> redefining
> and extending the OpenSCAD language. Instead it is mainly models of real
> world objects like fasteners and electronic components. I am quite happy
> modelling those in OpenSCADs simple low level language and don't feel need
> to abstract further. Even the most complicated models are mainly
> combinations of circles, squares, cubes, cylinders and spheres, translated
> and rotated.
>
> I do have translate_z(z) as a shortcut for translate([0, 0, z]) but that
> is
> about as far as it goes.

Never thought of doing something like that, but it's something I might like
to use, just to save me the typing time and the possibilityof errors. I
usually do a translate (or any other op using vectors) Like this...

translate([]) then backspace twice and put in the values

I find it reduces the errors.


> People have very different ways and thinking, so common libraries are only
> popular when they do something that an individual doesn't have the time or
> ability to do correctly themselves. Most things in BOSL are not hard to do
> directly in OpenSCAD.

True enough, though I often use libraries or saved modules when I don't need
the operation very often, and really don't want to reinvent it.





--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

adrianv
In reply to this post by nophead
nophead wrote

> BOSL creates a lot of trivial shortcuts for common operations. So instead
> of having to remember a small number of flexible primitives you now have a
> much larger language of simpler operations. That may suit some people but
> my brain works by remembering how to work things out rather than lots of
> arbitrary facts. For example, at school I didn't memorise trig formulas
> but
> I could remember how to work them out from first principles if I needed
> to.
> I have never known the number of days in a month because there is no
> proper
> rule or formula I know of.

Yes, BOSL creates these short cuts.  And yes, you don't need them.  But they
make code easier to write and they make it easier to maintain.  Maybe you
never have to maintain code, or aren't bothered by it.  Or maybe you have a
different way than I do of understanding code that you look at where you can
grasp the code at a higher level than I can.  To me, encapsulating several
operations into one operation almost always makes it easier to understand
and write. Consider, for example, that I want to make a reflection of some
stuff, so:

mirror(){
   thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}

But the problem is I needed to keep the original.  I can do

thingA(a,b,c);
thingB(d,e,f);
thingC(g,h);
mirror(){
   thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}

which is the easiest solution.  But this is both hard to maintain and hard
to read.  The reader has to recognize that the three things above are the
same as the children of mirror().  So of course you can make a module, which
is perhaps a good solution.  

module thing(){
  thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}

thing();
mirror() thing();

So that's not so bad.  But in my opinion, being able to do

mirror_copy(){
  thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}|

makes it easier and is more clear.  You can still use the thing module and
write mirror_copy()thing(); if you want and I think that's still more clear.
Now maybe you are thinking it's quite easy to recognize the original form
for what it is.  But when you have code duplication there's always the
potential for problems.  Now you may think this example is trivial.  But
when you do this over and over again in the code and then do it at the next
level, the code becomes simpler, easier to write, and easier to read, even
though you fundamentally have not made the system more powerful.  You may
like writing in assembly language, but most people prefer python.  (I have
written in assembly language, and in C, but those low level environments are
not my preference.)   Can python do more than C?  Arguably the answer is no.
But things are easier to do.  And

Yes, it means learning more commands.  You can write your own personal
libraries.  And that's OK until you want to interact with others.  Maybe you
never need to interact with others, in which case it doesn't matter.  But
writing your own libraries does take time and effort, especially if you want
to make them really robust.  I guess then the question becomes: is it easier
to write your own library that works exactly the way you want or is it
easier to learn to use somebody else's library?  


> I use my own library to make my projects but it doesn't go about
> redefining
> and extending the OpenSCAD language. Instead it is mainly models of real
> world objects like fasteners and electronic components. I am quite happy
> modelling those in OpenSCADs simple low level language and don't feel need
> to abstract further. Even the most complicated models are mainly
> combinations of circles, squares, cubes, cylinders and spheres, translated
> and rotated.

Of course you can model many things with these basic operations.  But I have
found that when you want to round over edges (something that should, in
principle, be done to nearly every edge in a model that will be 3d printed)
it can be quite tricky to do without an endless wait for minkowski().   I
have found that probably half or more of my design time goes to working out
details like this that shouldn't be so difficult.  It might actually be 90%
of the design time.  And I find myself using trial-and-error methods to
position roundover masks, which is not a satisfying approach, nor one that
is robust if the model dimensions change.   In any case, it's pretty clear
that our goals or our basic approach to modeling (or both) are not the same.
There's no reason you need to use libraries if you don't want to.  I'm not
trying to force them on anybody.  I'm interested in seeing good libraries
get established and documented so that those of us who want to use them can
do so.   I mean, just now I was thinking I needed a function to determine if
a point is inside a simply connected polygon.  It's surely been done a dozen
times, but I haven't found code yet for it.  Do I write it myself.  I'd call
it non-trivial.  


> I do have translate_z(z) as a shortcut for translate([0, 0, z]) but that
> is
> about as far as it goes.
>
> People have very different ways and thinking, so common libraries are only
> popular when they do something that an individual doesn't have the time or
> ability to do correctly themselves. Most things in BOSL are not hard to do
> directly in OpenSCAD.

First of all, note that BOSL implements screws, gears, bearings and various
types of joints.  It is 7000 lines of code, not something that could be
rewritten in an hour.   It implements a rounded cube where you pick which
edges you want to round.  Rounded cube itself is harder than it should be to
implement *correctly* in OpenSCAD.   (I printed about 15 hours of stuff that
all failed before I realized that spheres in OpenSCAD are undersized.)
Maybe my 3d visualization is just weak, but I find it annoying to have to
figure out the right sequence of rotations and translations to place a
roundover mask at a desired cube edge, for example.  And if I'm looking at
the code next week, I won't know what I did, or how to change it.  Then I
end up doing trial and error.  Or sometimes I think I understand...but it
turns out to be error.  

Getting back to people's different ways of thinking, I think you are
underestimating or misunderstanding the potential for libraries.  Definitely
one big advantage is extending function in nontrivial ways.  I think the
polyRound module is an example of this.  But also the OpenSCAD language
needs to be extended.  This is obvious if you look around because everybody
extends it.  People write functions to compute angle between vectors, for
example, or other basic math extensions.  I've seen some "extensions" that
seem to be in the base language (were they later additions?).   Then there
are other types of extensions whose purpose is to increase abstraction.
They aren't hard to write, but they simplify the code.  I've realized as I
build more models that I wasted a bunch of time fiddling to get parameters
right for something that, had I done it as a general routine, would have
been easier.  And if I used a library---even easier.  As an example of
abstraction at work, I wrote a segment module for the problem in this
thread.  It required doing a bit of basic math and wasn't a big deal, but if
you ran across that math embedded in some code it would be hard to
understand what it meant, whereas it's very easy to understand what the
segment module does.  

If I'm trying to read somebody else's code it's easier if I have learned,
once, a standard set of extensions than having to puzzle out a custom set of
extensions that do the same thing.  This is one big reason why it's better
to have this stuff done in a standard way by a library rather than everybody
doing it independently.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

nophead
> I guess then the question becomes: is it easier to write your own library that works exactly the way you want or is it easier to learn to use somebody else's library?  
For me if is definitely the former. I write just enough to make things work and don't spend time making it robust and overly general.

I wrote my own rounded polygon code initially in response to a question on this list and I now use it to model belt paths and calculate their length. It is only about 65 lines of code.

image.png

I also modelled a rubber sealing with complex profile strip with it.

image.png

Not sure what you mean by "roundover masks".  For 3D printing I mainly round in the XY plane by using offset and then linear_extrude. I don't spend any time doing trial and error to round things.

module rounded_square(size, r, center = true)
{
    $fn = r2sides4n(r);
    offset(r) offset(-r) square(size, center = center);
}

module rounded_rectangle(size, r, center = true, xy_center = true)
{
    linear_extrude(height = size[2], center = center)
        rounded_square([size[0], size[1]], r, xy_center);
}

For 3D rounded thing I use hull.

module corner_block(screw = def_screw, name = false) {
    stl(name ? name : str("corner_block", "_M", screw_radius(screw) * 20));

    r = 1;
    cb_width = corner_block_width(screw);
    cb_height = cb_width;
    cb_depth = cb_width;
    insert = screw_insert(screw);
    corner_rad = insert_outer_d(insert) / 2 + wall;
    offset = corner_block_hole_offset(screw);
    difference() {
        hull()  {
            translate([r, r])
                rounded_cylinder(r = r, h = cb_height, r2 = r);

            translate([r, cb_depth - r])
                cylinder(r = r, h = cb_height - corner_rad);

            translate([cb_width - r, r])
                cylinder(r = r, h = cb_height - corner_rad);

            translate([offset, offset, offset])
                sphere(corner_rad);

            translate([offset, offset])
                cylinder(r = corner_rad, h = offset);

            translate([offset, r, offset])
                rotate([-90, 0, 180])
                    rounded_cylinder(r = corner_rad, h = r, r2 = r);

            translate([r, offset, offset])
                rotate([0, 90, 180])
                    rounded_cylinder(r = corner_rad, h = r, r2 = r);
        }
        union() {
            corner_block_v_holes(screw)
                insert_hole(insert, overshoot);

            corner_block_h_holes(screw)
                insert_hole(insert, overshoot, true);
        }
        children();
    }
}

image.png

After you pointed out the bug in sphere I wrote my own that rotate extrudes a semicircle ensuring the number of vertices is a multiple of 4, so the poles and equator always have vertices on the axes.

image.png

//
// Replicate OpenSCAD logic to calculate number of sides from radius
//
function r2sides(r) = $fn ? $fn : ceil(max(min(360/ $fa, r * 2 * PI / $fs), 5));
//
// Round up number of sides to multiple of 4 to ensure points on all axes
//
function r2sides4n(r) = floor((r2sides(r) + 3) / 4) * 4;
//
// Circle with multiple of 4 vertices
//
module Circle(r, d = undef) {
    R = is_undef(d) ? r : d / 2;
    circle(R, $fn = r2sides4n(R));
}
//
// Semi circle
//
module semi_circle(r)
    render() intersection() {
        Circle(r);

        sq = r + 1;
        translate([-sq, 0])
            square([2 * sq, sq]);
    }
//
// Sphere that has vertices on all three axes. Has the advantage of giving correct dimensions when hulled
//
module sphere(r = 1, d = undef) {
    R = is_undef(d) ? r : d / 2;
    rotate_extrude($fn = r2sides4n(R))
        rotate(-90)
            semi_circle(R);
}

Yes I literally reinvented the wheel by defining my own version of circle!

I have never come across a need for mirror_copy(). If I did I would write one. Typically I make a left handed model of something and then define a right handed one which is the mirror of the left version. I then print one of each. So yes I have the original and the mirrored copy but they are in separate modules to fit in with my BOM generation and STL generation scheme.

I don't agree with your analogy to assembly code. The number of lines in my OpenSCAD projects is typically hundreds. You don't get much done in hundreds of assembly instructions. 3D object descriptions are much shorter than typical computer programs written in a high level language. Although the code to union a sphere and a cube might seem like it is operating at a low level geometrically the libraries to actually compute the result are very complicated indeed. So in one sense it is very high level code.

I have nothing against people using libraries I am just trying to explain why they are not popular with OpenSCAD compared to other languages. The code to describe objects is massively shorter and simpler than a normal computer program, where you typically have to use libraries to get anything done at all. In OpenSCAD the libraries that we are using are the ones compiled into it. I.e. CGAL, OpenCSG, Eigen and many more. It takes about 10GB of libraries to compile OpenSCAD. One could write geometry directly in C++ with CGAL and that would be a much lower level approach. OpenSCAD has abstracted that and made it very easy.

On Sat, 9 Mar 2019 at 19:40, adrianv <[hidden email]> wrote:
nophead wrote
> BOSL creates a lot of trivial shortcuts for common operations. So instead
> of having to remember a small number of flexible primitives you now have a
> much larger language of simpler operations. That may suit some people but
> my brain works by remembering how to work things out rather than lots of
> arbitrary facts. For example, at school I didn't memorise trig formulas
> but
> I could remember how to work them out from first principles if I needed
> to.
> I have never known the number of days in a month because there is no
> proper
> rule or formula I know of.

Yes, BOSL creates these short cuts.  And yes, you don't need them.  But they
make code easier to write and they make it easier to maintain.  Maybe you
never have to maintain code, or aren't bothered by it.  Or maybe you have a
different way than I do of understanding code that you look at where you can
grasp the code at a higher level than I can.  To me, encapsulating several
operations into one operation almost always makes it easier to understand
and write. Consider, for example, that I want to make a reflection of some
stuff, so:

mirror(){
   thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}

But the problem is I needed to keep the original.  I can do

thingA(a,b,c);
thingB(d,e,f);
thingC(g,h);
mirror(){
   thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}

which is the easiest solution.  But this is both hard to maintain and hard
to read.  The reader has to recognize that the three things above are the
same as the children of mirror().  So of course you can make a module, which
is perhaps a good solution. 

module thing(){
  thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}

thing();
mirror() thing();

So that's not so bad.  But in my opinion, being able to do

mirror_copy(){
  thingA(a,b,c);
   thingB(d,e,f);
   thingC(g,h);
}|

makes it easier and is more clear.  You can still use the thing module and
write mirror_copy()thing(); if you want and I think that's still more clear.
Now maybe you are thinking it's quite easy to recognize the original form
for what it is.  But when you have code duplication there's always the
potential for problems.  Now you may think this example is trivial.  But
when you do this over and over again in the code and then do it at the next
level, the code becomes simpler, easier to write, and easier to read, even
though you fundamentally have not made the system more powerful.  You may
like writing in assembly language, but most people prefer python.  (I have
written in assembly language, and in C, but those low level environments are
not my preference.)   Can python do more than C?  Arguably the answer is no.
But things are easier to do.  And

Yes, it means learning more commands.  You can write your own personal
libraries.  And that's OK until you want to interact with others.  Maybe you
never need to interact with others, in which case it doesn't matter.  But
writing your own libraries does take time and effort, especially if you want
to make them really robust.  I guess then the question becomes: is it easier
to write your own library that works exactly the way you want or is it
easier to learn to use somebody else's library? 


> I use my own library to make my projects but it doesn't go about
> redefining
> and extending the OpenSCAD language. Instead it is mainly models of real
> world objects like fasteners and electronic components. I am quite happy
> modelling those in OpenSCADs simple low level language and don't feel need
> to abstract further. Even the most complicated models are mainly
> combinations of circles, squares, cubes, cylinders and spheres, translated
> and rotated.

Of course you can model many things with these basic operations.  But I have
found that when you want to round over edges (something that should, in
principle, be done to nearly every edge in a model that will be 3d printed)
it can be quite tricky to do without an endless wait for minkowski().   I
have found that probably half or more of my design time goes to working out
details like this that shouldn't be so difficult.  It might actually be 90%
of the design time.  And I find myself using trial-and-error methods to
position roundover masks, which is not a satisfying approach, nor one that
is robust if the model dimensions change.   In any case, it's pretty clear
that our goals or our basic approach to modeling (or both) are not the same.
There's no reason you need to use libraries if you don't want to.  I'm not
trying to force them on anybody.  I'm interested in seeing good libraries
get established and documented so that those of us who want to use them can
do so.   I mean, just now I was thinking I needed a function to determine if
a point is inside a simply connected polygon.  It's surely been done a dozen
times, but I haven't found code yet for it.  Do I write it myself.  I'd call
it non-trivial. 


> I do have translate_z(z) as a shortcut for translate([0, 0, z]) but that
> is
> about as far as it goes.
>
> People have very different ways and thinking, so common libraries are only
> popular when they do something that an individual doesn't have the time or
> ability to do correctly themselves. Most things in BOSL are not hard to do
> directly in OpenSCAD.

First of all, note that BOSL implements screws, gears, bearings and various
types of joints.  It is 7000 lines of code, not something that could be
rewritten in an hour.   It implements a rounded cube where you pick which
edges you want to round.  Rounded cube itself is harder than it should be to
implement *correctly* in OpenSCAD.   (I printed about 15 hours of stuff that
all failed before I realized that spheres in OpenSCAD are undersized.)
Maybe my 3d visualization is just weak, but I find it annoying to have to
figure out the right sequence of rotations and translations to place a
roundover mask at a desired cube edge, for example.  And if I'm looking at
the code next week, I won't know what I did, or how to change it.  Then I
end up doing trial and error.  Or sometimes I think I understand...but it
turns out to be error. 

Getting back to people's different ways of thinking, I think you are
underestimating or misunderstanding the potential for libraries.  Definitely
one big advantage is extending function in nontrivial ways.  I think the
polyRound module is an example of this.  But also the OpenSCAD language
needs to be extended.  This is obvious if you look around because everybody
extends it.  People write functions to compute angle between vectors, for
example, or other basic math extensions.  I've seen some "extensions" that
seem to be in the base language (were they later additions?).   Then there
are other types of extensions whose purpose is to increase abstraction.
They aren't hard to write, but they simplify the code.  I've realized as I
build more models that I wasted a bunch of time fiddling to get parameters
right for something that, had I done it as a general routine, would have
been easier.  And if I used a library---even easier.  As an example of
abstraction at work, I wrote a segment module for the problem in this
thread.  It required doing a bit of basic math and wasn't a big deal, but if
you ran across that math embedded in some code it would be hard to
understand what it meant, whereas it's very easy to understand what the
segment module does. 

If I'm trying to read somebody else's code it's easier if I have learned,
once, a standard set of extensions than having to puzzle out a custom set of
extensions that do the same thing.  This is one big reason why it's better
to have this stuff done in a standard way by a library rather than everybody
doing it independently. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

adrianv
nophead wrote
> I wrote my own rounded polygon code initially in response to a question on
> this list and I now use it to model belt paths and calculate their length.
> It is only about 65 lines of code.

Well, apparently either your code is less general, or you are much more
clever than the author of the Round-Anything library, because his code is
about 400 lines.  His code is pretty hard to follow, so I can't assess
whether it's unnecessarily long or complicated, but since I'm not aware of a
released alternative, that's what we have to work with.   But even if 65
lines of code suffices to do this task, it's a lot to ask that every user
needs to write this.  Sixty-five lines of OpenSCAD is a significant amount
of code.  


> Not sure what you mean by "roundover masks".  For 3D printing I mainly
> round in the XY plane by using offset and then linear_extrude. I don't
> spend any time doing trial and error to round things.

A roundover mask is the thing you need to subtract from your model to create
a roundover (in the case where you weren't able to build it in when you made
the geometry originally.)  Here's an example of what I'm talking about.  

<http://forum.openscad.org/file/t2477/rmask2.png>

Here's the whole output for better context.  Maybe you can tell that the
roundover I achieved isn't really ideal.  It's not oriented normal to the
surface I'm rounding and it wasn't obvious to me how to get the relevant
normal vector to fix that.  It also only rounds in one direction where
really the roundover should be in two directions, but I couldn't find a
decent way to do that.  And ideally the entire edge of the whole model would
be rounded, which I see no way to do other than some insane use of minkowski
that would probably take days to run---or perhaps a complete rewrite using
some sort of sweep operation to generate the shape.  But without
libraries....sweeping is impossible...  

<http://forum.openscad.org/file/t2477/wholemod2.png>

And the whole 350 lines of code (written with no libraries) if you really
want to look at it:
wave_battery.scad <http://forum.openscad.org/file/t2477/wave_battery.scad>  


> I have never come across a need for mirror_copy(). If I did I would write
> one.

I have used this pattern of code for constructing symmetric parts.  


> I don't agree with your analogy to assembly code. The number of lines in
> my
> OpenSCAD projects is typically hundreds. You don't get much done in
> hundreds of assembly instructions. 3D object descriptions are much shorter
> than typical computer programs written in a high level language.

Yes, it's true that you need a lot more assembly code to do anything
interesting.  But I'm finding that reading my own OpenSCAD code is extremely
difficult, so in that sense, the analogy may be stronger.  


> I have nothing against people using libraries I am just trying to explain
> why they are not popular with OpenSCAD compared to other languages. The
> code to describe objects is massively shorter and simpler than a normal
> computer program, where you typically have to use libraries to get
> anything
> done at all.

I think what you are really doing is explaining why you and like-thinking
people don't use libraries.  I worked with a guy for a while who didn't
believe in using the standard C++ libraries.  This guy wrote his own vector
template class instead of using the standard one and dismissed the standard
one as being without value. The preference for writing your own stuff and
not using libraries is a general attitude and can come up with many
different languages and in varying contexts---it's not unique to OpenSCAD.  

I think the reason that we see so little use of libraries in OpenSCAD
overall is that libraries are hard to find, it's not clear that there are
any standard libraries, and documentation tends to be sparse.  If there was
a clearly established set of libraries that people were using, that seemed
to be well written rather than random code snippets, that were documented
through the main OpenSCAD manual then you would see a lot more library use.
I'm not saying that everybody would be using libraries.  But the people who
think like me would be using libraries.  

I think that what happens instead is that people look at OpenSCAD, don't see
any libraries, and just assume that OpenSCAD is limited.  It just can't do
those things.  Or that's just hard to do those things.  Not everybody will
push to try to find ways to do things that seem hard.  They might decide
OpenSCAD is just a weak system for modeling and that for the models they
need, a different software is required.   This could potentially even select
for a population of the kind of users who don't mind working harder to write
everything on their own.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

nophead


On Sun, 10 Mar 2019 at 13:08, adrianv <[hidden email]> wrote:
nophead wrote
> I wrote my own rounded polygon code initially in response to a question on
> this list and I now use it to model belt paths and calculate their length.
> It is only about 65 lines of code.

Well, apparently either your code is less general, or you are much more
clever than the author of the Round-Anything library, because his code is
about 400 lines.  His code is pretty hard to follow, so I can't assess
whether it's unnecessarily long or complicated, but since I'm not aware of a
released alternative, that's what we have to work with.   But even if 65
lines of code suffices to do this task, it's a lot to ask that every user
needs to write this.  Sixty-five lines of OpenSCAD is a significant amount
of code. 

 
Not sure what the 400 lines of code does that mine doesn't. I just take a list of 3 vectors that are X,Y coordinates and a radius that can be positive, negative or zero. I then just construct the tangents between the circles. Here is the code:

function circle_tangent(p1, p2) =
    let(
        r1 = p1[2],
        r2 = p2[2],
        dx = p2.x - p1.x,
        dy = p2.y - p1.y,
        d = sqrt(dx * dx + dy * dy),
        theta = atan2(dy, dx) + acos((r1 - r2) / d),
        xa = p1.x +(cos(theta) * r1),
        ya = p1.y +(sin(theta) * r1),
        xb = p2.x +(cos(theta) * r2),
        yb = p2.y +(sin(theta) * r2)
    )[ [xa, ya], [xb, yb] ];

function rounded_polygon_tangents(points) =
    let(len = len(points))
        [for(i = [0 : len - 1])
            let(ends = circle_tangent(points[i], points[(i + 1) % len]))
                for(end = [0, 1])
                    ends[end]];

function sumv(v, i = 0, sum = 0) = i == len(v) ? sum : sumv(v, i + 1, sum + v[i]);

// cross product of 2D vectors is the area of the parallelogram between them. we use the sign of this to decide if the angle is bigger than 180.
function rounded_polygon_length(points, tangents) =
    let(
      len = len(points),
      indices = [0 : len - 1],
      straights = [for(i = indices) norm(tangents[2 * i] - tangents[2 * i + 1])],
      arcs = [for(i = indices) let(p1 = tangents[2 * i + 1],
                                   p2 = tangents[(2 * i + 2) % (2 * len)],
                                   corner = points[(i + 1) % len],
                                   c = [corner.x, corner.y],
                                   v1 = p1 - c,
                                   v2 = p2 - c,
                                   r = abs(corner.z),
                                   a = acos((v1 * v2) / sqr(r))) PI * (cross(v1,v2) <= 0 ? a : 360 - a) * r / 180]
     )
    sumv(concat(straights, arcs));

module rounded_polygon(points, _tangents = undef) {
    len = len(points);
    indices = [0 : len - 1];
    tangents = _tangents ? _tangents : rounded_polygon_tangents(points);

    difference(convexity = points) {
        union() {
            for(i = indices)
                if(points[i][2] > 0)
                    hull() {
                        translate([points[i].x, points[i].y])
                            circle(points[i][2]);
                        polygon([tangents[(2 * i - 1 + 2 * len) % (2 * len)], tangents[2 * i], [points[i].x, points[i].y]]);
                    }

            polygon(tangents, convexity = points);
        }
        for(i = indices)
            if(points[i][2] < 0)
                hull() {
                    translate([points[i].x, points[i].y])
                        circle(-points[i][2]);

                    polygon([tangents[(2 * i - 1 + 2 * len) % (2 *len)], tangents[2 * i], [points[i].x, points[i].y]]);
                }
     }
}

This illustrates why I don't use somebody else's 400 line library when I can easily write my own code. I did it just to help somebody on this list as, at the time, I didn't have a use for it. It has its origins here:


> Not sure what you mean by "roundover masks".  For 3D printing I mainly
> round in the XY plane by using offset and then linear_extrude. I don't
> spend any time doing trial and error to round things.

A roundover mask is the thing you need to subtract from your model to create
a roundover (in the case where you weren't able to build it in when you made
the geometry originally.)  Here's an example of what I'm talking about. 

<http://forum.openscad.org/file/t2477/rmask2.png>

Here's the whole output for better context.  Maybe you can tell that the
roundover I achieved isn't really ideal.  It's not oriented normal to the
surface I'm rounding and it wasn't obvious to me how to get the relevant
normal vector to fix that.  It also only rounds in one direction where
really the roundover should be in two directions, but I couldn't find a
decent way to do that.  And ideally the entire edge of the whole model would
be rounded, which I see no way to do other than some insane use of minkowski
that would probably take days to run---or perhaps a complete rewrite using
some sort of sweep operation to generate the shape.  But without
libraries....sweeping is impossible... 

Well I wrote my own simple sweep as well but with some help from people here.

When 3D printing rounding in 2D is desirable to smooth the tool path but 3D rounding is only needed for functional or aesthetic reasons, so I tend to avoid it because it is slow unless I can generate it with hull.
 
 

<http://forum.openscad.org/file/t2477/wholemod2.png>

And the whole 350 lines of code (written with no libraries) if you really
want to look at it:
wave_battery.scad <http://forum.openscad.org/file/t2477/wave_battery.scad



I will have a look later if it ever finishes previewing.
 
> I have never come across a need for mirror_copy(). If I did I would write
> one.

I have used this pattern of code for constructing symmetric parts. 


> I don't agree with your analogy to assembly code. The number of lines in
> my
> OpenSCAD projects is typically hundreds. You don't get much done in
> hundreds of assembly instructions. 3D object descriptions are much shorter
> than typical computer programs written in a high level language.

Yes, it's true that you need a lot more assembly code to do anything
interesting.  But I'm finding that reading my own OpenSCAD code is extremely
difficult, so in that sense, the analogy may be stronger. 


> I have nothing against people using libraries I am just trying to explain
> why they are not popular with OpenSCAD compared to other languages. The
> code to describe objects is massively shorter and simpler than a normal
> computer program, where you typically have to use libraries to get
> anything
> done at all.

I think what you are really doing is explaining why you and like-thinking
people don't use libraries.  I worked with a guy for a while who didn't
believe in using the standard C++ libraries.  This guy wrote his own vector
template class instead of using the standard one and dismissed the standard
one as being without value. The preference for writing your own stuff and
not using libraries is a general attitude and can come up with many
different languages and in varying contexts---it's not unique to OpenSCAD. 

I do use things like the standard C library and STL. I write my own when I think it is quick and easy and use libraries for hard stuff.


I think the reason that we see so little use of libraries in OpenSCAD
overall is that libraries are hard to find, it's not clear that there are
any standard libraries, and documentation tends to be sparse.  If there was
a clearly established set of libraries that people were using, that seemed
to be well written rather than random code snippets, that were documented
through the main OpenSCAD manual then you would see a lot more library use.
I'm not saying that everybody would be using libraries.  But the people who
think like me would be using libraries. 

I think that what happens instead is that people look at OpenSCAD, don't see
any libraries, and just assume that OpenSCAD is limited.  It just can't do
those things.  Or that's just hard to do those things.  Not everybody will
push to try to find ways to do things that seem hard.  They might decide
OpenSCAD is just a weak system for modeling and that for the models they
need, a different software is required.   This could potentially even select
for a population of the kind of users who don't mind working harder to write
everything on their own. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

MichaelAtOz
Administrator
OK.  I think we have debated the merits of libraries to the point where those
who do, do, and don't, don't.
It would be good that every new topic on this forum DOES NOT end up in
further general discussion of the history and philosophy of libraries.



-----
Admin - email* me if you need anything, or if I've done something stupid...

* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work. Obviously inclusion of works of previous authors is not included in the above.

The TPP is no simple “trade agreement.”   Fight it! http://www.ourfairdeal.org/   time is running out!
--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Admin - email* me if you need anything,
or if I've done something stupid...
* click on my MichaelAtOz label, there is a link to email me.

Unless specifically shown otherwise above, my contribution is in the Public Domain; to the extent possible under law, I have waived all copyright and related or neighbouring rights to this work.
Obviously inclusion of works of previous authors is not included in the above.


The TPP is no simple “trade agreement.” Fight it! http://www.ourfairdeal.org/ time is running out!
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

adrianv
In reply to this post by nophead
nophead wrote
> Not sure what the 400 lines of code does that mine doesn't. I just take a
> list of 3 vectors that are X,Y coordinates and a radius that can be
> positive, negative or zero. I then just construct the tangents between the
> circles. Here is the code:

I took a look and found that the code doesn't round the corners, but instead
grows the size of the shape.  The new shape does indeed have rounded
corners...but it's not a rounded version of the polygon you started with.
It also fails in the important case of non-convex polygons.   Perhaps these
differences in function explain the difference in code size.  


> When 3D printing rounding in 2D is desirable to smooth the tool path but
> 3D
> rounding is only needed for functional or aesthetic reasons, so I tend to
> avoid it because it is slow unless I can generate it with hull.

You may be right about 3d rounding.  But aesthetic reasons are important to
me in my designs.  I don't want to make things with uncomfortable sharp
corners.  And even 2d rounding seems to be nontrivial to do in many cases
when the design is not just an extrusion of a 2d shape.  

Actually, rounding entrances to holes is functional and that's 3d rounding.  
Sharp interior corners are points of weakness structurally and could be 3d.
I'm not sure why rounding off corners would lead to slower printing.  I
would have expected the reverse, since less material is extruded.  




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

nophead
Yes my code doesn't round a polygon with sharp vertices, instead it takes a list of circles and joins them tangentially to make a rounded polygon, so the input for a given shape is different. I.e. I start with centre points and radii of the actual shape rather than a list of imaginary vertices that get rounded off. It does cope with concave shapes. The belt path example I showed is concave. I use negative radii to specify the concave corners, and zero for a sharp corner. I think it can make exactly the same set of shapes but the input data is different.

I didn't mean rounded corners are slower to print, I meant 3D rounding in OpenSCAD is very slow. Your example took 20 minutes to preview on my laptop, none of my designs are that slow. Even a full 3D printer with every nut and bolt is only about 6 minutes with the latest OpenSCAD snapshot. However, I don't have any 3D Minkowski in my designs.

I think the only way to make the channel quickly is to sweep a rounded U shape along the path. You are still left with how to round the ends though.To calculate the normal you can subtract the last two points in the path to get the tangent and cross that with vertical vector to get the normal.



On Sun, 10 Mar 2019 at 17:54, adrianv <[hidden email]> wrote:
nophead wrote
> Not sure what the 400 lines of code does that mine doesn't. I just take a
> list of 3 vectors that are X,Y coordinates and a radius that can be
> positive, negative or zero. I then just construct the tangents between the
> circles. Here is the code:

I took a look and found that the code doesn't round the corners, but instead
grows the size of the shape.  The new shape does indeed have rounded
corners...but it's not a rounded version of the polygon you started with.
It also fails in the important case of non-convex polygons.   Perhaps these
differences in function explain the difference in code size. 


> When 3D printing rounding in 2D is desirable to smooth the tool path but
> 3D
> rounding is only needed for functional or aesthetic reasons, so I tend to
> avoid it because it is slow unless I can generate it with hull.

You may be right about 3d rounding.  But aesthetic reasons are important to
me in my designs.  I don't want to make things with uncomfortable sharp
corners.  And even 2d rounding seems to be nontrivial to do in many cases
when the design is not just an extrusion of a 2d shape. 

Actually, rounding entrances to holes is functional and that's 3d rounding. 
Sharp interior corners are points of weakness structurally and could be 3d.
I'm not sure why rounding off corners would lead to slower printing.  I
would have expected the reverse, since less material is extruded. 




--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

adrianv
Yes, doing 3d rounding is definitely slow.  I found that using render() with
minkowski() made it kind of tolerable because I wasn't recomputing the
minkowski() every time I tweaked the model.  In this model I actually used
minkowski() twice: once to create the channel and another time for rounding.
Certainly faster solutions would be nice.   The minkowskiRound() module
calls minkowski() three times and the author says it can take 12 hours.  I
suppose one can argue that slow is better than impossible.  

Regarding finding the normal, I concluded that because the channel was
formed from offsets and then cut that it was not obvious how to find the
point on the cosine curve that corresponded to the end of the channel.  I
would have to solve for the equation that describes the offset from cosine
(e.g. by adding its normal vector at every point?) and then I could take the
derivative of that.  It seemed like it was going to be a complex
calculation---but also, what's the point of using offset() if I then have to
turn around and compute the equation of the curve myself?  Did I err in my
thinking about this?   If it was just determined by the underlying cosine
curve it should actually be parallel to the axis at the ends, but that's not
what happens.  

I agree that with the exception of very large roundings---like the one I
used above in this thread to solve the curved edge rectangle---the two
rounded polygon codes produces the same set of shapes.  But at least for how
I design parts and think about design, it's enormously better to define a
polygon and then cut off the corners instead of defining  it with a set of
tangent spheres, because the locations of the sides of the polygon are the
primary parameter, and when the angles are not 90 degrees, figuring out how
to place the tangent spheres requires a computation.  A major attraction to
me of the roundPoly function I found is that it eliminates computation and
lets me instead describe the desired output.    I maintain that the computer
should be doing the computations, not me.   I suppose I could write a
wrapper that computes the necessary positions for the circles and it seems
like that wouldn't take 335 more lines of code.   Perhaps I'll dig deeper.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Rectangle with one curved edge

nophead
> Did I err in my thinking about this?

No. What I said would apply to a sweep of a U where the profile would be always be oriented parallel to the tangent of the path. The way you have offset from a larger polygon I am not sure the same is true. Possible it, is but since you have sliced the channel to form the ends it isn't obvious where on the path the end you want to round is. Also since the path is curved any mask would need to be curved as well, so now I appreciate your problem. 

>But at least for how I design parts and think about design, it's enormously better to define a polygon and then cut off the corners instead of defining  it with a set of tangent spheres

And this is exactly why we don't have standard libraries. My code is perfect for what I use it for, which is belt paths, where the primary parameters are the position and pitch radius of the pulleys.

On Mon, 11 Mar 2019 at 01:23, adrianv <[hidden email]> wrote:
Yes, doing 3d rounding is definitely slow.  I found that using render() with
minkowski() made it kind of tolerable because I wasn't recomputing the
minkowski() every time I tweaked the model.  In this model I actually used
minkowski() twice: once to create the channel and another time for rounding.
Certainly faster solutions would be nice.   The minkowskiRound() module
calls minkowski() three times and the author says it can take 12 hours.  I
suppose one can argue that slow is better than impossible. 

Regarding finding the normal, I concluded that because the channel was
formed from offsets and then cut that it was not obvious how to find the
point on the cosine curve that corresponded to the end of the channel.  I
would have to solve for the equation that describes the offset from cosine
(e.g. by adding its normal vector at every point?) and then I could take the
derivative of that.  It seemed like it was going to be a complex
calculation---but also, what's the point of using offset() if I then have to
turn around and compute the equation of the curve myself?  Did I err in my
thinking about this?   If it was just determined by the underlying cosine
curve it should actually be parallel to the axis at the ends, but that's not
what happens. 

I agree that with the exception of very large roundings---like the one I
used above in this thread to solve the curved edge rectangle---the two
rounded polygon codes produces the same set of shapes.  But at least for how
I design parts and think about design, it's enormously better to define a
polygon and then cut off the corners instead of defining  it with a set of
tangent spheres, because the locations of the sides of the polygon are the
primary parameter, and when the angles are not 90 degrees, figuring out how
to place the tangent spheres requires a computation.  A major attraction to
me of the roundPoly function I found is that it eliminates computation and
lets me instead describe the desired output.    I maintain that the computer
should be doing the computations, not me.   I suppose I could write a
wrapper that computes the necessary positions for the circles and it seems
like that wouldn't take 335 more lines of code.   Perhaps I'll dig deeper.



--
Sent from: http://forum.openscad.org/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
12