adrianv wrote

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 "-".

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.

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/

nophead wrote

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

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.

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/

life.
Thanks, I always learn a lot here!

On Sat, 9 Mar 2019 at 16:22, lar3ry lar3ry@sasktel.net wrote:

nophead wrote

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?

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.

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/

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: image.png]

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

[image: 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: 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: 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 avm4@cornell.edu wrote:

nophead wrote

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.

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 used this pattern of code for constructing symmetric parts.

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 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/

On Sun, 10 Mar 2019 at 13:08, adrianv avm4@cornell.edu 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:

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:
http://forum.openscad.org/Script-to-replicate-hull-and-minkoswki-for-CSG-export-import-into-FreeCAD-td16537.html#a16556

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.

I will have a look later if it ever finishes previewing.

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.

nophead wrote

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.

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/

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 avm4@cornell.edu wrote: