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.