I can only offer my own experience with OpenSCAD which I’ve been using for about 4 years, and to say that my knowledge and facility with OpenSCAD is driven primarily by the challenge of the final design. The open question... “How would I do that in OpenSCAD” and then setting about to make it happen.
If you’re lazy like me, you never really want to abandon the simple solutions and code flows you’ve mastered if they’ll do, but I’ve found it’s always useful to have the “Cheat Sheet” open in front of me, so that I’m always aware of options in functionality that I may not have tried yet.
My mastery of geometry is pathetic, so when I first examined mulmatrix() I gave it a wide berth, but if you want to sheer an object then there’s really no replacement (I say that somewhat embarrassed because in the early days I spent far too much time rotating cubes and slicing off sides :)) so even though I was loathe to climb the learning curve on that module, I eventually succeeded.
Then on the other hand, my personal experience is that life is just too short to make much use of minkowski() cause even though it's cool it can just take too staggeringly long to render some things so that I opt for a less sophisticated design rather than invoke the monster.
I have tried using the odd library, but once I figure out how a routine works I usually just rewrite it. The extensible nature of OpenSCAD where you can even replace all the existing modules with redefinition has left me with a rather extensive collection of routines in libraries of my own authorship, which means that my code doesn’t usually play well with others.
There’s also getting enough familiarity with OpenSCAD to develop an instinctive feel for what it can’t do… and others have experienced that too, so that every year or so you’ll see someone from the community innocently asking, “Can’t this feature be added to OpenSCAD” only to find that same feature was asked for a couple of years earlier and abandoned because it just can’t be accomplished with the way OpenSCAD interacts with it’s code base of other 3rd part modules. (For exampleI think we’d all love to have a way to extract the current point set at any point in our program… but as I understand it just isn’t possible. And wouldn’t it be neat to have some deformation routines, like “push this sphere into this cube”.
I know that I’d love to use some bezier curves in my designs, but from the little bit of investigation I’ve done in that area, looking at other people’s code and examples, it looks like the housekeeping requirements for keeping values alive and useful through transformations is beyond my ability to juggle more than on thing at a time.
I guess I would suggest that you set about writing routines that use every single function and module so that you develop a working knowledge of what they can do, and then their use will occur to you naturally when you cast about for how to solve your newest design challenge.
In short, I would say there’s just no substitute for doing lots of coding… always bearing in mind that regardless of what you’ve done, there’s probably a better smarter way of doing it that you may stumble across later.
Anyway, its always great to see someone else finding value in the OpenSCAD platform, for me, it is the parameterization that makes it the sole choice among modelling programs.
I’m sure others will have useful and helpful suggestions as well, as I can at least testify that the OpenSCAD community and its developers are by far the most welcoming, non-critical, helpful and patient bunch of folks probably on the whole planet.

The way to get rounded corners with the correct dimensions is to make sure
$fn is a multiple of 4. That way the circle or sphere has vertices that
align with the axes.

For 2D use offset for rounding and then linear_extrude for 2.5D. For full
3D use hull of spheres if possible and Minkowski with a sphere as last
resort.

I rarely use multmatix. So far I have only used it to skew things as most
other matrix operations can be done with translate, rotate, mirror and
scale.

Yes OpenSCAD is far from unique in being parametric. Its main differences
is you write script instead of interacting with a GUI. You only describe
geometry with it, you can't interrogate it, You do need high school lever
trigonometry to solve some problems with it.

On Wed, 20 Feb 2019 at 13:04, adrianv avm4@cornell.edu wrote:

I hope my original response to the OP didn’t come off as patronizing or simplistic, that wasn’t the intent… I clearly mis estimated the OP’s level of familiarity with OpenSCAD already.
I wasn’t suggesting that OpenSCAD was the only parametric design program out there but as you say, Solidworks IS expensive. At $4K a license I simply presumed that it was a non-starter for most people.
And I wasn’t trying to suggest that it one should rewrite all code, simply reporting on my own experience that often 3rd party libraries often point to the solution I need, but there always seems to be some other parameter or functionality I need to add for my own needs. Take for example Greg Frost’s Bevel and Spur gear library…. which is just a great contribution to the community but after having used it for awhile I discovered that I wanted gear designs that it could not accommodate. Personally I think 3rd party libraries are great in that they introduce (to me) new coding concepts and workable solutions, but that most of them are best thought of as tutorials that one can use very effectively to craft the solution for what is needed.
Because of the relatively modest popularity of OpenSCAD in the wider world, I find that it’s this mailing list that is the best source for outside guidance and learning tricks and techniques… and that was what my comment about the OpenSCAD community was really talking about… I’ve seen countless requests for help with design and coding that almost always result in helpful hints and discussions about the design at hand. Case in point… nop head’s response to your post and advice on setting $fn to multiples of 4.
For my part, I design models for 3D printing and try to craft code that will allow the things I create to be printed on any 3D printer, not just the ones I have access to. With that in mind, I came to appreciate that I needed to structure my code so that things like tolerance were parameterized at a very low level so that when Tab A needs to fit in Slot B, the desired fit can be achieved simply by changing a tolerance variable that works for a given machine… as out in the wild actual precision and accuracy varies a great deal.
And then there’s considerations like way OpenSCAD draws arcs and circles… and the need to mindful of final dimensions depending on whether you need an exterior cylinder or an interior knockout as discussed on this page… https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/undersized_circular_objects https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/undersized_circular_objects
You can implement a number of coding strategies to provide for the correct case, you could explicitly add the fudge factor whenever you need to draw an outer cylinder, or you can write unique methods for each use, or you can go for the approach I went for which was to provide a new cylinder method where the usage case is one of the parameters… e.g.

module _cylinder(height, radius, fn, usage = “default) {
r = usage == “default”
? radius
: usage == “outer”
? radius * 1 / cos(180/fn)
: radius * (1 + 1/cos(180/fn))/2;
cylinder(height,r,fn);

As a result of this kind of approach, and to accommodate the previously mentioned concerns about tolerance, I no longer call cylinder() in my code, but my own _cylinder() which notches up the level of abstraction of the objects I’m creating and helps me personally write what I find to be code that’s easier to understand.
Again I apologize if my original post implied anything more than was intended which was to offer encouragement and identify that for me, this forum is the best one-stop spot for everything OpenSCAD.

On 2/19/2019 6:12 PM, Hugo Jackson wrote:

At least for 2D beziers, the math is a little scary but once you've got
a function that emits a series of points it's not bad. You just feed
that list into polygon() and can then extrude and transform to your
heart's desire.  Note that you will often want to concatenate bezier
curves and straight lines to form your polygon.

I'm sure that 3D bezier curves are meaningful, but they hurt my head.

// Bezier functions from https://www.thingiverse.com/thing:8443
// but that yielded either single points or a raft of triangles;
// this yields a vector of points that you can then concatenate
// with other pieces to form a single polygon.
// If we were really clever, I think it would be possible to
// automatically space the output points based on how linear
// the curve is at that point.  But right now I'm not that clever.
function BEZ03(u) = pow((1-u), 3);
function BEZ13(u) = 3u(pow((1-u),2));
function BEZ23(u) = 3*(pow(u,2))*(1-u);
function BEZ33(u) = pow(u,3);

function PointAlongBez4(p0, p1, p2, p3, u) = [
BEZ03(u)*p0[0]+BEZ13(u)*p1[0]+BEZ23(u)*p2[0]+BEZ33(u)*p3[0],
BEZ03(u)*p0[1]+BEZ13(u)*p1[1]+BEZ23(u)*p2[1]+BEZ33(u)*p3[1]];

// p0 - start point
// p1 - control point 1, line departs p0 headed this way
// p2 - control point 2, line arrives at p3 from this way
// p3 - end point
// segs - number of segments
function bez(p0, p1, p2, p3, segs) = [
for (i = [0:segs]) PointAlongBez4(p0, p1, p2, p3, i/segs)
];

// And an example...

b = bez([0,10], [5,15], [5,5], [10,10], 10);
linear_extrude(height=5) polygon(concat([[10,0], [0,0]], b));

On 2/20/2019 4:59 AM, adrianv wrote:

Have you read this tutorial?

http://www.tridimake.com/2014/09/how-to-use-openscad-tricks-and-tips-to.html

It covers children in section 4.

The capsule summary is that you can write a module that can consume
child objects and manipulate them.

module double(offset) {
    children();
    translate(offset) children();
}

double([3,0,0]) cube(1);

Skewing.  This example skews in x and y based on z - that is, as z gets
bigger, x and y translate.

module skewz(x, y) {
multmatrix([
[ 1, 0, x, 0 ],
[ 0, 1, y, 0 ],
[ 0, 0, 1, 0 ],
[ 0, 0, 0, 1 ]
]) children();
}

skewz(1,1) cube(1);

Lookup tables.  I've only used it once (and that only as a proof of
concept for somebody else).

I don't remember what the original question was, but here's a function
that draws text one character at a time, using a character-width table. 
The key part is the cw() function.

// Table of character widths.
// These values approximate the default font for text() on Windows.
// Punctuation and digits left as an exercise for the reader.
widths = [
["A", 9],
["B", 9],
["C", 9],
["D", 10],
["E", 9],
["F", 9],
["G", 10],
["H", 10],
["I", 4],
["J", 7],
["K", 9],
["L", 8],
["M", 11],
["N", 9],
["O", 10],
["P", 9],
["Q", 10],
["R", 10],
["S", 9],
["T", 9],
["U", 9],
["V", 9],
["W", 13],
["X", 9],
["Y", 9],
["Z", 9],
["a", 7.5],
["b", 7.5],
["c", 7.5],
["d", 7.5],
["e", 7.5],
["f", 4],
["g", 7.5],
["h", 7.5],
["i", 3],
["j", 3],
["k", 7.5],
["l", 3],
["m", 11],
["n", 7.5],
["o", 7.5],
["p", 7.5],
["q", 7.5],
["r", 4.5],
["s", 7.5],
["t", 4],
["u", 7.5],
["v", 7],
["w", 9],
["x", 7],
["y", 6.5],
["z", 7.5],
];

// Given a character c (as a single-character string), return its width
function cw(c) = widths[search(c, widths, index_col_num=0)[0][0]][1];

// Given a string s and a length n, return the total width of the first n characters of s.  n defaults to the length of s.
function sw(s, n) = let(_n = n != undef ? n : len(s)) _n == 0 ? 0 : sw(s, _n-1) + cw(s[_n-1]);

// Draw a string s using the text defaults.
// This variation calculates the position of each character individually.
// Note that a real implementation would need to allow setting the size of the text, and would need to scale the widths based on the text size.
module text2(s) {
for (i = [0:len(s)-1]) {
translate([sw(s, i),0,0]) text(s[i]);
}
}

// Draw a string using the text defaults.
// This variation positions each character relative to the character before it.
// Again, a real implementation would need to allow for changing the font size.
module text3(s, start) {
_start = start != undef ? start : 0;
if (_start <= len(s)) {
text(s[_start]);
if (_start+1 <= len(s)) {
translate([cw(s[_start]),0,0]) text3(s, _start+1);
}
}
}

// Test case comparing the spacing generated here with the default spacing.
s = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz";
text(s);
translate([0,12,0]) text2(s);
translate([0,24,0]) text3(s);

nophead wrote

This is not sufficient.  In my original case I had $fn=8 and that resulted
in my model being unprintable due to the discrepancy.  In 2d forcing $fn=4
works.  But in 3d, you have to force $fn=4 and you also have to correct the
radius by the cos(180/$fn) factor.  At least, I think that works.  I don't
have a mechanism for making sure that my code is actually correct.  (Maybe
I should try to read the STL files.)

module boundcube(x,y,z,r=0,facets=20)
{
if (r==0)
translate([x[0],y[0],z[0]])
cube(size=[x[1]-x[0],y[1]-y[0],z[1]-z[0]],center=false);
else {
fixfacets = ceil(facets/4)4;  // Force facets to a multiple of 4
fixr = r/cos(180/facets);
hull()
for(i=[0,1])
for(j=[0,1])
for(k=[0,1])
translate([x[i]-2ir+r, y[j]-2jr+r, z[k]-2k*r+r])
sphere(r=fixr, $fn=fixfacets);
}
}

If you know what you're doing ahead of time, so to speak, then I think it's
easier to build roundovers into the design.  In the cases I'm thinking of I
constructed a model using a series of operations and then wanted the result
to have a roundover.  In once case, the model was fairly simple, resulting
from the intersection of cubes.  So I could have worked out the equations of
the cube faces to figure out their intersections and hence determined the
line of intersection and then placed my roundover there.  But in the second
case, I started with a shape made from a cos wave joined up to a tangent
function, which I expanded using offset() and then extruded into 3d, and
then I used minkowski to turn it into a hollow shape with thin walls.  Now I
want to cut off and round over some of those walls.  Figuring out exactly
where those walls are so I can round them over doesn't appear to be straight
forward, and I created a roundover shape and then shifted it around by trial
and error, which makes the model less parametric than one might like.  I
considered the goal of rounding over the entire edge of the shape, which
follows a cos wave---except not quite because of the offset.  I have no idea
how that could be accomplished short of redoing the model in a fully
functional (mathematical) fashion using polyhedron(), or trying to apply
minkowski again on it.  It was slow enough with one minkowski.  A more
general issue with minkowski is the need to design the model undersized to
make it work.  In one recent design I was making a box with cylinderical
holes and wanted the edge of the box and also the edges of the holes to have
a roundover.  I did this by subtracting cylinders from the cube, running
minkowski, and then subtracting the cylinders again to remove the excess.
This seems sort of messy.  But trying to construct roundover cylinders
seemed messier.  And of course it happens that you want to round over just
parts of the model, which minowski cannot do.

In response to Hugo Jackson, wouldn't it be better to extend the Gear
library to remove its limitations in a new library version rather than to
rewrite it yourself, for your own private version?  I suppose there's
always the risk of things getting overwhelmingly complex due to special case
situations.  But if the OpenSCAD community regards libraries as method
tutorials rather than as building blocks it seems like we're never going to
build very high.  And if its the nature of OpenSCAD that you can't build on
top of libraries but always need to rewrite them, that seems disturbing.  It
suggests that the environment is fundamentally limited, that it has a design
flaw of some kind.  Or maybe the library design isn't good.  But then we
need to know how to write a good, extensible library.

It would seem perfectly reasonable for OpenSCAD to provide primitive
operations like cylinder() but for there to be a set of standard libraries
that provide things like adjustment for the polygonal nature of cylinders.
But why should everybody have to (1) figure out the need for this and then
(2) write it himself?

Every time I do a design I feel like I'm stumbling around trying to find
clean or elegant solutions to problem in the design.  It doesn't really seem
like I should be trying to crowdsource my modeling by posting all of these
problems here.  That's also inefficient for the community in general.  I
normally figure that when encountering a programming difficulty one should
reduce it to the essential minimal example, but that seems harder to do than
in other programming contexts.  Or the minimal examples are bigger.  Maybe
I just need to work harder at the reduction.

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

JordanBrown wrote

Yes.  That tutorial was what opened my eyes to this whole capability.  But I
had to stumble across it.  It also raises the question about applying my own
module to a loop when they describe how their chained_hull() module won't
work on the output of for(), since for() just produces one child.  That's
what caused me to ask the question about whether I can write my own for()
function.  Certainly the code example where he hard codes the wedge_if calls
in a big list seems pretty darn ugly.  Is that the best that is possible?
It seems like being able to write my own iteration, or to operate on the
separate children of a for loop, would be a useful feature.  I assume
there's some reason it missing.  It is impossible, right?

Note: I recognize what can be done with matrix transformations.  I'm just
not seeing (at the moment) an application for it.  And if it's only good for
making skews, really, then it seems like you really just want to write the
skew() module and never look at mulmatrix again, due to its increased
complexity.  I mean, one could argue we don't need rotate() or translate()
since mulmatrix() can do it all.  One could imagine OpenSCAD implemented
with only mulmatrix() in the core language and with those other functions as
a library layer over it.

I saw in another message somebody searching vertex lists with search() for
some purpose that I didn't fully understand.  Lookup tables on single
characters seems like a pretty contrived example.

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

I think the greatest handicap OpenSCAD faces is the vicious circle of popularity vs. participation. I believe I read somewhere that you can count on one hand the number of people who’ve taken on the task of OpenSCAD development and maintenance… and as a consequence there are far more features and functionality that end users would like to see than there are people who have the time and resources to implement the wish lists.
As for my obligation to update the gear library, you make a good point. In my defence while I occasionally see requests for “where to find a gear library”, once they’re pointed to the existing contribution then that’s usually the end of it, so my assumption is that the existing library is giving people the functionality they need and no necessity to muddy the water with my own contribution. But perhaps it's simply that the existing library failed to meet their needs and they moved on in frustration.
But you’re right, it would be good to have more community endorsed libraries, and if I were to make a suggestion to the OpenSCAD maintainers it would be have an explicit and separate area on GitHub for OpenSCAD libraries. As it stands, its seems that the primary repository for OpenSCAD libraries is Thingiverse. While I don’t feel up to the challenge of modifying OpenSCAD itself, I’d be on board with supplying and participating in the development of library routines written in OpenSCAD.

Oh yes, spheres are a bit broken. Here you can see that a circle of radius
10 has its vertices exactly on 10.

[image: image.png]

But sphere doesn't get the poles and the equator correct as it starts the
latitude circles half an angle out.  So yes dividing the cos(180 / $fn)
fixes it.

[image: image.png]

Alternatively, writing ones own with polyhedron is probably better.

I always learn from this forum.

I assume there's some reason it missing.  It is impossible, right?

All modules currently can only return one child even though they can have
more than one child themselves. It is an implementation limitation and may
change. There is even a pull request for a version of for with union =
false as an option. https://github.com/openscad/openscad/pull/2796

On Wed, 20 Feb 2019 at 19:38, Hugo Jackson hugo@apres.net wrote:

OpenSCAD has a weird relationship with libraries.  I think there's
fundamentally 2 problems that feed each other.

1)  No package manager has ever really gained much adoption. (I've tried

• I'm the author of https://github.com/lostapathy/scad_bundler).  Which
  probably makes sense because there aren't many libraries packaged for
  any package manager.

2)  There's not a lot of community knowledge on how to make a library
that is well suited for reuse (or extract one from a larger project).

There's definitely a bootstrapping problem here.  I personally think a
lot of the perceived limitations of OpenSCAD can be solved at the
library level, and having a more compelling ecosystem there will attract
more effort in OpenSCAD itself.

I haven't spent much time on scad_bundler recently because I never got
much interest or engagement on it - good bad or otherwise. Perhaps
there's a mismatch in that I'm trying to approach using OpenSCAD like a
software engineering problem, and maybe that's not where the community
is at.  At the same time, "post your library on thingiverse" hasn't
really taken off, either.

I'm not sure what the next step is, but I'm open to suggestions.

On 2/20/19 1:37 PM, Hugo Jackson wrote:

nophead wrote

Actually all I can tell from that picture is that the circle is close to 10.
I can't tell that it's exactly ten.  Could be 10.1 maybe.  Could it be 10.2?
Maybe.

I went ahead and looked at the STL for
linear_extrude(height=1)circle(r=1,$fn=8); and found that it looks like
this:

solid OpenSCAD_Model
facet normal 0 0 -1
outer loop
vertex 0.707107 0.707107 0
vertex 1 0 0
vertex 0.707107 -0.707107 0
endloop
endfacet
facet normal -0 -0 -1
outer loop
vertex 0.707107 0.707107 0
vertex 0.707107 -0.707107 0
vertex -0.707107 0.707107 0
endloop
endfacet
facet normal 0 0 -1
outer loop
vertex 0.707107 0.707107 0
vertex -0.707107 0.707107 0
vertex 6.12323e-17 1 0
endloop
endfacet
facet normal 0 -0 -1
outer loop
vertex -0.707107 0.707107 0
vertex -1.83697e-16 -1 0
vertex -1 1.22465e-16 0
endloop
endfacet

etc, etc, etc

I loaded the data into octave and checked that the x and y range from -1 to
1 and that furthermore, all values above 0.9 are equal to 1 and all values
below -0.9 are less than 1.  So that's confirmation that nothing surprising
has happened.  I suppose I ought to do the same thing for my boundcube()
module.

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

lostapathy wrote

3. The language needs additional features to better support libraries. e.g.
   Namespaces

There has been much discussion on the future direction of OpenSCAD including
many such features, see  here
https://github.com/openscad/openscad/wiki/OpenSCAD-Enhancement-Proposals
&  here https://github.com/doug-moen/openscad2/blob/master/README.md  for
example, plus much past discussion in the headspace of the development
community. Note that they are proposals and still need design work (IMHO)
and not necessarily fully endorsed direction.

But as Hugo mentions, there is only a small pool of spare-time developers,
the resources available vary, so progress has to go in baby steps. An
unfortunate reality.

It should also be noted that OpenSCAD is young, according to Wikipedia, the
initial release was 19 February 2010. Happy 9th Birthday!! And only really 4
major releases in that time, with the 5th hopefully soon.

Compare to 47 years for C, or 29 for Python, I imaging the early versions
were also clunky.

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/

On 2/20/2019 11:32 AM, adrianv wrote:

If you go to openscad.org, then "documentation", then (in the left
sidebar or scroll down), "Tutorials - Articles / Blogs", it's the first
link.  It was the first thing I saw and read.  It could be more
prominent, but not much.

As nop head said, a module can only return one child.

Other than general DIY matrixes, skewing is the only application I know
of.  Indeed, I wrote a skew module to wrap it.  I haven't thought enough
about it to know whether one function is enough, or if you need more
than one.  If you try to do it with only one, I suspect that you end up
having to pass six values to fully describe the skew.  (But non-trivial
skews hurt my brain.)

I suspect that much of the reason for it is that the other functions
require the capability, so why not expose it in case somebody finds it
useful?

Well... it was the answer to a question that somebody really asked, so
not totally contrived.  I don't remember exactly what they were looking
for, but it involved getting character spacing right.  (A further
enhancement along the same lines might do searches on character pairs
for kerning.)

I have used the somewhat-similar lookup( ) in my own work to do
interpolated lookups in a table.

On 2/20/19 4:45 PM, MichaelAtOz wrote:

I'm quite familiar with that discussion at the info on GitHub.

I'm not saying there isn't room for language improvement, but IME you
can go a long on libraries without namespaces.  The scoping difference
of include vs use makes it possible to not pollute the namespace with
extra variables  or modules.  Libraries can be built such that a use'd
file only puts one module into the namespace of the caller, so you can
import only a minimum amount of functionality.  Given that, I'm not sure
why calling a module as MyLibrary-Function() vs MyLibrary::Function() is
a show stopper.

I agree completely.  My point was that if we build up the userspace
ecosystem around OpenSCAD to enable a larger user base, the small subset
of OpenSCAD users who can also develop on OpenSCAD itself will probably
grow with the community.

I hadn't thought about the possible importance of having a package manager.
It looks like your project is a reasonable effort.  I'm not sure it's enough
alone.  To me it seems like the thing that will make packages successful is
a central authority that lists packages (so people can find them) and
documentation and tutorials about the packages.  This last thing is crucial.
There is a list of packages in the manual, but the list is not very useful
because it doesn't state what exactly the packages can (or cannot) do.  And
furthermore, the packages aren't well documented.  And it comes across more
like a random collection of assorted code people wrote than an organized
extension to OpenSCAD.  If a package is seen as a standard library you
should be able to find documentation about how to use it and what it does.
If you look up the C++ template classes, or NumPy, you don't have to read
the source code to figure out what they can do or how to use them.  The
package are documented right along side the basic language.  If the OpenSCAD
manual had a section on packages and actually documented them, then new
users would presumably be interested in getting and using the packages.  I
updated my OpenSCAD from what is apparently the stable version (???) from 3
years ago to the development version because I read the manual and needed
those features.  If I read about some package that would solve my problem
I'd install it.  But there's nothing to read about....

I tried to use path_extrude on my recent project but had problems.  Lack of
documentation made it unclear if they were solvable or not.  Maybe I should
read the code.  But looking at it now, I see that it starts at the ground
level, defining lots of very primitive operations that one might imagine
should be supplied in some standard way by lower level packages.

I think this also ties to the second point.  If there are no libraries
designed for reuse then it's hard for users to know how to write such a
library.  What I stumbled across were various piles of code that may (or may
not) be well designed code.  I don't know.  And I'm not sure what they do.
Where is my model for how to make a library?  If I had example libraries
that were well documented it would provide ideas about how to design
additional libraries, I think.  It also seems like there's a potential
issue with libraries including other libraries.  Is it bad for a library to
be included multiple times in different scopes?

The "post your library on thingiverse" approach seems ridiculous to me.  I
started running across stuff on thingiverse and it wasn't clear to me what
its status was.  It's not where I'd expect to find a library---that's for
sure.

I'm not sure what the solution is---and obviously I just popped in here
today so I'm not really in a position to say what should happen.  But it's
seeming more and more like the existing situation is problematic.  Perhaps
we should start a well defined project of some kind to establish and
document a set of standard libraries?

lostapathy wrote

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

I suggest that a useful first step might be legitimizing what libraries are currently available by adding them to the OpenSCAD User Manual… as say Chapter 10. That way at least those are aren’t adverse to RTFM would see that libraries are not simply routines of unknown providence showing up on Thingiverse.
If there’s support for this first step I’d be happy to start said Chapter 10 and populating it with what I can gather from the existing library code.

boxcarmib wrote

This sounds like a great idea.  The only question I have---having not
examined the libraries in question---is whether they are good libraries.  Is
the API well thought out.  I don't want to put up roadblocks to progress,
but you want to get things off to a good start.

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

As per this discussion I’ve been spending the afternoon looking at the existing libraries and I would say they are of mixed quality, so part of the work I’d be willing to undertake would be to refactor most of them, and subject their modification to whatever the general review process is for code enhancements.
There are a number of libraries that really should be folded together… there’s a least 3 “shape” libraries, some of which have overlapping functionally, and some that have modules that just don’t work, not to mention libraries that haven’t been worked on in years so they bring up “assign deprecated” and other similar errors.
I’ve used source control in many forms but not GitHub and I don’t know what the protocol and procedures would be for submitting proposed changes and the release mechanism, so I’d need a little handholding help with that… perhaps there’s some already overworked code developer maintainer who could shoot me an offer to help me get bootstrapped into “how to submit changes to the OpenSCAD master branch”.

On 2/20/19 6:19 PM, adrianv wrote:

This is why a package manager that supports versioning is so critical,
and why I think the libraries should exist independently of OpenSCAD itself.

If we enshrine any current library as official and ship it with OpenSCAD
itself, it becomes impossible to update it and improve the API on a
separate lifecycle from OpenSCAD (which is itself another can of
worms).  It also becomes fairly unpalatable to make major breaking
changes to the API.  See the inconsistent APIs in MCAD that would be
easy to make better, but in doing so would break all existing code that
uses them.

Where if the libraries are independent, and the package manager can
handle version dependencies, it's ok to change the API between MCAD 1.0
and MCAD 2.0, so long as your own project's manifest (scadfile in the
case of scad_bundler) knows what version it needs.

Further, there seems to be a growing trend in other languages to
minimize the size of the "standard library" for these reasons, and also
so obsolete libraries can be abandoned.  For example, in the Ruby
standard library, there are a lot of libraries that should really be
removed from standard library because they are unmaintained and largely
irrelevant for new code, but people don't want to break existing code by
removing them.

I went into some of this from other angles in my article at
https://lostapathy.com/blog/openscad-needs-a-package-manager/ before I
released scad_bundler at https://github.com/lostapathy/scad_bundler

On 2/20/19 6:34 PM, Hugo Jackson wrote:

See my other reply from farther up thread as to why I don't think more
libraries in OpenSCAD proper is the answer.

Also as you look at package up libraries, keep in mind that we need to
be respectful of the original author's copyright and license, which is
often not totally clear, and it may not always be possible to combine
libraries that were released under different licenses.

There's probably a lot to be said for taking existing libraries,
figuring out what useful functionality they contain, and then making
clean implementations with a 100% known license situation.

I fixed those silly numbers in my PR here that is merged into master:
https://github.com/openscad/openscad/pull/2669

I don't think OpenSCAD needs package managers and namespaces, etc. The
number of libraries needed is very small compared to general purpose
programming languages. I don't use any but the amount of code I use that
would perhaps belong in a standard library is tiny. A one page of matrix
maths functions, Bezier curves and a sweep. I have a few standard shapes
like sectors, rounded rectangles and teardrops but they are trivial to
write.

I like OpenSCAD because it is simply and light weight compared to something
like C++ that needs many gigabytes of libraries to get anything done
nowadays.

On Thu, 21 Feb 2019 at 06:14, Rob Ward rl.ward@bigpond.com wrote:

nophead wrote

How do we know today what the libraries of tomorrow might be?  It seems like
there's a gear library, which sounds useful at least in general.  There was
a library I saw that involved defining attachment points and connecting
parts together that seems potentially useful.  (But I don't know if it is
actually useful.) There really should be something for doing fillets and
roundovers.  I am not sure what the right form is for this kind of thing.
One approach would be things like a cylinder that flares in or out at one or
both ends, which would enable filleted or rounded over junctions or holes.
Shapes like this are not so easy to make, and it's not immediately obvious
how to design a clean API for this.

I do think that at least initially, libraries can be established without a
package manager.  It's not clear to me how important the package manager is.
But it is definitely a good idea to keep them separate from OpenSCAD itself.
It should be possible to update individual libraries independently and as
needed.  We should give libraries clear version numbers and make versioning
clear so that libraries can evolve.  Perhaps libraries should define a
variable that gives the library version?

When C was originally invented it was small and simple.  Did Kernighan and
Ritchie foresee its eventual destination?  There were people who insisted
that it was better to write in assembly language rather than C.  Simpler?
Well, sort of.  OpenSCAD is simple, as long as your design is simple.  But
if your design is more complex, then the OpenSCAD code is not so simple.
That's the role for libraries---to make it easier to consider more complex
designs, to actually build more complex things, and to make it easier to
maintain your code.

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

All these, except attachments, actually already exist in the BOSL library.  And I'm thinking about how to best implement attachments.

https://github.com/revarbat/BOSL/wiki https://github.com/revarbat/BOSL/wiki

• Revar

The BOSL library looks very good, and it's great that it's documented.  I
started trying to use it and so far have the following observations.

I have been finding it useful to define a cube by its corner coordinates.
It doesn't supply this, as far as I could see.

There are a whole bunch of cube functions that make cubes in different
places, and then separate functions that make rounded cubes.  It seems like
it might be better to have this be unified, so you can create rounded cubes
in any desired manner.  In other words, rounding would be an option, or cube
positioning would be an option.  Or there might be a master cube module that
can make any kind of cube and more restricted functions that are simpler
that make specific ones.

I wanted to specify the inner diameter of a tube.  This seems like it would
be very common--maybe even the most common way to make a tube.  Having to
specify ID+wall and then wall again is clumsy.

The last concern has to do with the use of the term "fillet" and the
functionality I meant when I used the term.  I may not understand general
usage here.  I understood the term "fillet" to refer to specifically
rounding of *concave" corners.  Wikipedia presents this as the primary
definition:  https://en.wikipedia.org/wiki/Fillet_(mechanics)

What is implemented in BOSL as "fillet" is what I would call a roundover.
Now I poked around and found that some other programs (e.g. Autocad) use the
term "fillet" to mean roundover.  So some sort of decision on nomenclature
is necessary.  But also, the BOSL library appears to lack the ability to do
the type of fillet I was referring to, at least in general.  There are some
special cases such as the thinning brace and thinning wall.

http://forum.openscad.org/file/t2477/fillet2.png

One other observation about the BOSL library:  it's not listed on the
OpenSCAD list of libraries.

RevarBat wrote

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

JordanBrown wrote

I have taken a look at the various tutorials to see if I missed anything and
offer here a brief remark on each.

The first one I already read.  It is great because it gives some ideas of
how to really make use of modules.

The second one is a dead link.

The third one (EduTechWiki) is basically a rehash of the manual with some
examples.  I would say it's sort of unfortunate in that it shows the
creation of a lego block in an rather ugly fashion.  The code examples are a
bit much to actually read through.  Perhaps if it proceeded onward to show
a rewrite using more general modules I'd think it more helpful.

The fourth one by Ragain about DXF is missing a bunch of the pictures for
me, which makes it hard to follow.

The fifth one, "I Heart Robots" has some interesting content.  It's actually
a collection of several posts.  There is one on DXF again.  But also another
one about rounding.  It also shows the need for a generic rounded polygon
function.  The author works pretty hard to round over one corner of a
triangle.  Has anybody written this?

The sixth one refers to the Obijuan library and the use of connectors to do
beveling.  It looks interesting, but it's a bit spare on details.  It seems
like this notion of connectors is useful, though.

The last HTML tutorial is another one about DXF import, which looks useful.

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

Good idea.  I've added cube2pt(p1,p2) to implement this.

Yeah, the set of cube modules were evolved over time and it shows.  I'll take look at
this and decide what to do.  Maybe take offsetcube(), rename it something more
generic like cuboid() and give it align, fillet and chamfer arguments.

I've updated tube() to be able to take inner and outer diams and radii, or wall with
either inner or outer diams/radii.  The following calls should all create the same tube shape.

• tube(h=10, r=50, ir=45);
• tube(h=10, d=100, id=90);
• tube(h=10, r=50, wall=5);
• tube(h=10, d=100, wall=5);
• tube(h=10, ir=45, wall=5);
• tube(h=10, id=90, wall=5);

Err, Wikipedia defines a fillet as

"In mechanical engineering, a fillet is a rounding of an _interior or exterior_ corner of a part design."

However, dictionary.com http://dictionary.com/ indicates a fillet is a rounding of an interior corner.

AutoCAD uses fillet for both interior and exterior corners.

I figure if it's good enough for AutoCAD and Wikipedia, it's a generally understood name for interior and exterior angle rounding.

I actually hadn't noticed this until you mentioned it.  I've added interior_fillet() to shapes.scad to provide this capability, for arbitrary interior angles.

Would you believe that I simply hadn't noticed that page was a Wiki I could add to?

• Revar

RevarBat wrote

I realized that I actually mis-wrote what I did.  I defined the cube by
ranges of x, y, and z.    My function is boundcube(xrange, yrange, zrange).
Does this difference matter?  I think it does.  I went on to define an
"infinity" called inf, and "all" as [-inf,inf] so I could define half-spaces
like boundcube([0,inf],all,all).  This is less natural with the two points
method.  Maybe both approaches should be provided?  I think my thinking
process also tended to be about the x, y and z ranges, and not about the
corner points---like I need to fill in this space from this x position to
that one.

Is this a reasonable way to design shapes?  Is there a downside to creating
large coordinates, like setting inf=10^4 or 10^5?  When I did my sliding
dovetails I made them by using halfspaces defined like this, rotating them,
and then doing intersections and unions.  Is there a better way?

Sounds like that could be a reasonable approach.  Will fillet and chamfer
have interior and exterior options?

Looks good to me.  I know there's already a ton of parameters, but is it
worth adding od as an option for outer diameter for consistency?

Yeah,  Wikipedia does define it as including exterior.  But then they give
only examples of interior rounding.  Also the word "fillet" refers to "a
strip of material", so an added strip in a transition, not to removal.

Well, maybe, but maybe not.  I noticed in watching autocad tutorials a
couple things.  One is that there is one button.  So they wanted one term...
Well, except they didn't.  the button is labeled "rounds and fillets edges".
This suggests that rounds and fillets are not the same.

A second observation is that almost all the tutorials are in 2d operating on
lines, where in fact there is no difference.

A third observation is that if you are operating on a 3d shape by selecting
edges, as one does in autocad, the program knows if it's concave or convex,
so it would be silly to have two functions for this.

So the autocad designers may have chosen to generalize "fillet" beyond its
normal meaning.  Since autocad is important, this broadened the term.  But
does OpenSCAD work the same way as autocad?

Nope.  We have to explicitly distinguish between exterior and interior
operations.  So the question is how will that be done.  I'm not insisting
that fillet is the wrong term here, but just make sure that people are
generally happy with the choice of terms.  It may also depend on how you do
things.

This is a start.  I have a few thoughts.  One is that interior filletting
should be possible on cubes and cylinders just the way you have
filleted_cylinder().  In fact, I might want to make a cylinder that is
interior filleted on one end and exterior filleted on the other, so the
object includes both fillets.  This way if I want to make a stopped hole I
can simply create the cylinder and subtract it from a cube and I have all of
my rounding handled effortlessly.  (This is possible now but I think you
need to use 3 objects to do it.)

Another thing is that there needs to be a way to make the corner interior
fillets for a cube.  In the

https://github.com/StephS/i2_xends/blob/master/inc/fillets.scad

library you can make the corners.  Actually for roundover masks perhaps you
need a way to mask off corners.  And stepping back, I am still not really
sure how to apply these kind of building blocks in complex situations.  I
made a shape over the weekend that had a rectangular base that tapered wider
as it went up.  I needed the bottom corner to be rounded over.  That seemed
very difficult to do because it was an obtuse angle and I didn't know what
the angle was---and the fillet mask doesn't have an angle option.  I did a
chamfer instead.  This required trial and error shifting the chamfer mask
around so that I didn't have a little corner.  None of this is satisfying.
If I make a shape using prismoid and want to round the bottom I don't want
to have to do a bunch of trig to figure out the angles.

The second observation is that if you're going to say interior_fillet then
you need to say exterior_fillet for the other case for consistency.  The
chamfer operation actually has this problem as well, in that you need
interior and exterior chamfers if you want to supply them on cubes or
cylinders.  I kind of like the term "flare" to refer to adding interior
angle chamfers or interior fillets to the edges of cubes.  In other words,
you specify a flared cylinder end and then somehow indicate whether you want
it rounded or chamfered.
One possible way to do this might be to make a data structure that describes
edge treatments and have functions that create the data structure with
different characteristics and defaults.

So what is the right language for OpenSCAD (not autocad) to use to capture
all of this stuff.  And what are the right functions and operations to make
it easy to do?

The others who have written on this thread about libraries, do you have any
thoughts about the BOSL library?  It appears much better than MCAD to me in
general.  What does MCAD have that is missing from BOSL?  Does it make
sense to give BOSL a section in the OpenSCAD manual?  Does anybody else
have any thoughts on how to improve BOSL and make it something you'd be
happy to use?

I mentioned in an earlier post that generalized polygon roundover seems like
a nice feature.  And it turns out it does exist, already done, just like
BOSL was out there kind of in hiding.
https://github.com/Irev-Dev/Round-Anything
There was a thread about a year ago about this.  This library also supplies
a minkowski rounding function that could be useful in cases where it's not
too slow to use.  Hmmm.  Assuming there are any such cases.  (The author
speaks of waiting 10 hours for the result.)  I just ran it on a simple test
case and am still waiting, which doesn't inspire a whole lot of excitement,
though I suppose if I could get my model to a finished state and then run
this for an hour to apply the rounding it might still be useful.    It took
25 seconds to round over a cube with $fn=8.  I took a look at the code and
it calls minkowski three times.  There's also a round2d based on offset()
which rounds any 2d object and runs in reasonable time, so that could be
useful.

My simple test case finally finished.  It took 30 minutes and this is the
result:
http://forum.openscad.org/file/t2477/round.png

Another question I had is what is the standard way to use a library like
this.  I have put it in a lib directory (as a subdirectory of where my work
is) so I'm doing stuff like

use <lib/bosl/shapes.scad>

Is that the right thing to do?  Ideally I should be able to share my code
with other people and they should be able to run it without having to tinker
with the use statements.

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