Hans L thehans at gmail.com
Mon Jan 29 20:37:29 EST 2018

```On Mon, Jan 29, 2018 at 9:08 AM, NateTG <nate-openscadforum at pedantic.org> wrote:

> I'm not sure what you want the scope of the project to be.

Well, the core "functional.scad" is primarily intended to implement
only OpenSCAD's builtins, with minimal extra functions needed to
accomplish that.
On one hand it can be looked at as a sort of reference implementation,
like Tony was saying just above.  On the other hand the library is a
sort of conversation piece for discussion on some of OpenSCAD's
limitations and how we might improve OpenSCAD in such a way that makes
this library obsolete!

For any *addiitonal* functionality that extends beyond builtins, I
have tried to split these into other files, which include
the sky is the limit.
I like to use this project as a showcase of some of the cool things
you can do when you have full access to the geometry.  I'm interested
in pushing limits of what can be accomplished in OpenSCAD, and showing
unique features that were otherwise not possible or too cumbersome.

The project can also be seen a testing ground for additional features
that, if proven useful, could be later implemented natively in
For example I added an optional "r" (radius) parameter to the square
function.  My implementation concatenates four 90degree arcs, so no
extra boolean or hull or minkowski operations are required.  By itself
I don't think its particularly remarkable, but I also plan to add the
same radius parameter for cube which I *do* think is a big deal.
Currently there is no particularly efficient way to generate a rounded
cube and a pure functional method like this would be blazing fast (and
accurate) in comparison to existing methods.
Conceptually you would generate the vertices/faces for each octant of
a sphere(or just one octant and mirror it around), and then add quad
faces to connect the edges of those sphere corners.  I've done some
work towards this purely functional rounded cube implementation but it
is not finished yet.

Here is a quick implementation of the rounded cube concept which I
made as a module, since this version *does* still require one hull
operation.
https://gist.github.com/thehans/2c96601af4e5c8c2d232e50252dd37b1

model of a six sided die.  The body of the die is a rounded cube, but
if you look closely the corners are a mess; the faces and edges of
spheres and cyllinders that make up the shape don't line up.
I'd love to see such a radius parameter added to the native cube
module, so an example such as this could be so much cleaner both in
the code and in the geometry it creates.

Yeah... I think I might look into finishing up that cube radius
parameter as one of my next tasks.

> Something that is likely to be useful in general (but may be scope creep) is
> a 'mesh checker' that takes points and faces as arguments and identifies
> easy-to-detect topological flaws like holes and non-manifold edges.
> Reverse-wound faces or sections are relatively easy to detect as a special
> case, and non-manifold vertices shouldn't be that much more effort.  A more
> advanced version could also detect self-intersection (though that's halfway
> to a clipper.)   Another ambitious extension of this idea is to have
> functions to fix some of these issues.

I agree that some form mesh validation would be pretty handy, but I'm
not well versed in relevant algorithms for that sort of thing.

> A function that fills in a solid under a patch of surface could be handy,

I don't understand what you mean here.

> I see you have subdivide, but no face triangulation function that lets you
> apply it to to the output of cube().  That seems like a missing piece and
> the algorithms are well-documented.  (I was tinkering with this yesterday.)
> Armed with that, you can start doing plastic deform stuff pretty easily.
> Generic plastic deforms aren't going to be available without functions as
> first-class variables, but you can still have good support for basic stuff
> like projective, cylindrical, and spherical transforms.

Yeah the subdivision was written specifically for the
alternative_spheres, and could really use triangulation to be more
widely applicable.  I've *heard* of delaunay triangulation, for
example, but have never attempted to implement it myself.
Oh, is the 2-3 tree structure you made intended for use in
triangulation?  I skimmed briefly but I'm not famliiar with that data
structure or its applications.

Adding new transformations / deformations is something I'm
particularly interested in, like "wrapping" an object around a
cylinder or sphere (if that's what you mean).  Projective transform is
already possible using a 4x4 matrix though, right?

> An alternative to using a clipper for booleans is a voxel-based geometry
> engine.   Union, intersection, and subtraction are really easy with that,
> but making it viable in OpenSCAD requires conversion utilities to switch
> between the voxel and surface models of geometry.
>
> Automated mesh smoothing operations like filleting, beveling, and spline
> fitting are things that people want, but that aren't available in OpenSCAD.

Fillets in particular I really like to include in most of my designs.
I usually end up building a 2d profile from arcs, then linear or
rotate extruding it.
double_fillet was my attempt to make slightly easier to generalize
some tricky cases of fillets, but I still wouldn't consider it
"automated" by any means; you have to build the fillets into your
model from the beginning.

The best sort of automated fillet approach I've seen would be a blend
function used by a SDF(signed distance function) based renderer, (like
Doug Moen is doing with Curv: https://github.com/doug-moen/curv ,
another exciting project) but SDF is a complete paradigm shift that I
don't think would be practical to attempt implementing in OpenSCAD.

-Hans

```