operations directly on the vertex/face data from within openscad. ...

I have a pretty good idea of a way to do it, but it's going to be a chore to
write.  I also don't know how to running into issues with the recursion
limit.

P.S. I'm not sure I've ever seen then ".x" in "s.x" in OpenSCAD before.  Do
you know if it's documented anywhere?

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

Marius said:

not used to this syntax.

v.x is the first element of vector v, same as v[0].

Another way of designing this feature is to provide built-in global
variables
X = 0
Y = 1
Z = 2
and then you can write v[X] to get the first element of v.

On 25 January 2018 at 16:28, Marius Kintel marius@kintel.net wrote:

I like the .x .y .z shortcuts and I think they are somewhat useful
feature, but I actually feel that it doesn't go far enough!  I think
support for swizzling, much like GLSL would be a really handy
addition.  https://www.khronos.org/opengl/wiki/Data_Type_(GLSL)#Swizzling

So you could do something like this for example:
p3d = [1,2,3];
p2d = p3d.xy; // alternative to: [ p3d[0], p3d[1] ]  more clean and
concise with swizzling

And all the other combinations and transposing of axes could also be possible.

On Thu, Jan 25, 2018 at 3:28 PM, Marius Kintel marius@kintel.net wrote:

Wow… I agree… I love the dot notation and had no idea it existed… I think it really helps with readability of code.
I also agree the swizzling would be great.

The resurrection of this thread has spurred me to make some updates to
the library over the past few days.

https://github.com/thehans/FunctionalOpenSCAD

• I've created an overall README.md for the project and tried to
  document everything a bit better.
• A signed_volume function has been added, thanks to NateTG.
• Added new planes.scad file for creating planes from points,
  visualization, etc.
• Plus a handful of other minor additions and changes.

I hope the new documentation makes it all easier to understand.  Let
me know if anything in particular is unclear.

The splitPolygonByPlane function in planes.scad is my attempt to port
this function from OpenJSCAD/csg.js  My implementation doesn't work
100% and I guess that's where I stalled on further implementing
boolean ops, etc.  I haven't touched that code in months and forgot a
lot of what I was doing.  I'm not particularly motivated to pick that
code back up at the moment, but I fiured it was still worthwhile to
show what progress I had made.

Do you have ideas for any other features you would like to see added?
(aside from the currently unsupported OpenSCAD builtins)

Lastly I'm curious anyone has found FunctionalOpenSCAD useful in their
own projects so far?

Thanks
-Hans

On Thu, Jan 25, 2018 at 6:19 PM, Hugo Jackson hugo@apres.net wrote:

(aside from the currently unsupported OpenSCAD builtins)

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

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.

A function that fills in a solid under a patch of surface could be handy,
and shouldn't be that hard to write.

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.

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.

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

Thanks for doing this project!

It strikes me that writing more of openscad in openscad
will make porting easier, and maybe foster unification
of openscad and openjscad.

On Sun, Jan 28, 2018 at 12:10 PM, Hans L thehans@gmail.com wrote:

--

Best Regards.
This is unedited.
This message came out of me
via a suboptimal keyboard.

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

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
functional.scad.  As far as scope of additional functionality goes,
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
OpenSCAD.
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

Compare that to something like OpenSCAD's example006.scad, which is a
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.

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.

I don't understand what you mean here.

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?

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

It's super simple.  I'll just write it up and submit it on github.

example, but have never attempted to implement it myself. ...

Delauney triangulation and voronoi diagrams are for things like finding
nearest neighbors.  Polygon triangulation involves different algorithms.  (
https://en.wikipedia.org/wiki/Polygon_triangulation )

I'll submit a simple stupid one on github.

It is possible with 4x4 matrices but not supported in OpenSCAD.

https://en.wikibooks.org/wiki/OpenSCAD_User_Manual/Transformations#multmatrix

"...the fourth row is used in 3D environments to define a view of the
object. it is not used in OpenSCAD and should be [0,0,0,1]..."

(I thought it was too, but realized it wasn't after suggesting it as an
improvement in the 'bend algorithm' that uses intersections and multmatrix.
https://github.com/openscad/openscad/issues/815 )

P.S.:

A 2-3 tree is a self-balancing tree.  It's a data structure for searchable
lists.

https://en.wikipedia.org/wiki/Self-balancing_binary_search_tree

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