Functional OpenSCAD, working with vertex data

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Functional OpenSCAD, working with vertex data

thehans
I've been working on a library that re-implements OpenSCAD's builtin
modules as functions that basically operate on vectors of 2D and 3D
point data.

Its now at a point where I feel its usable and accurate enough to
share, so I made an initial commit here:
https://github.com/thehans/FunctionalOpenSCAD/blob/master/functional.scad

Building the geometry from the bottom up like this makes it possible
for all kinds of computations performed over geometry that would
otherwise require modifying OpenSCAD's own source code.
For example the library contains a "bounds" function for computing the
bounding box on a shape or list of shapes.
Another potential function (not yet written) would be computing the
volume of a solid.

I added some documentation in the file's comments, but it could
probably use more improvement.
I've had my head in this for a while, so I'm not sure if I'm glossing
over any non-obvious aspects of what's going on here.

I think it can potentially be pretty powerful for certain cases where
OpenSCAD's programming interface is otherwise limiting in some way.

I'm curious what others on the list think of this.  Suggestions are welcome.

Hans

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

MichaelAtOz
Administrator
Interesting. Any feeling on performance v's builtins?
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!
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

MichaelAtOz
Administrator
// OpenSCAD Modules not (yet) implemented as Functions
& text()
;)
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!
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Neon22
In reply to this post by thehans
That is pretty darn cool.
No changes to the language - results are in poly or polyhedron form.
well done sir !!!

Now if we could get the sweeps and lofts incorporated into this same model that will be fantastic.
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

TLC123
In reply to this post by thehans
Very nice.
Subdivision and tesselletions?
Domain warps?  
Be ware of self intersections though.  

 
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Parkinbot
In reply to this post by thehans
A very nice and consequent step into the right direction. However, OpenSCAD gains most of its power from its Boolean operations. At most you could offer some lazy union and bounding box calculations for "intended" Boolean operations but not more.
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
In reply to this post by MichaelAtOz
On Wed, Apr 5, 2017 at 1:31 AM, MichaelAtOz <[hidden email]> wrote:
> Interesting. Any feeling on performance v's builtins?
Haven't done a ton of testing.  Things like sphere take a little
longer to process when initially hitting f5, but the actual framerate
of previewing them should be nearly the same.

In general I would expect slightly worse performance if for example
translating an existing script to a functional version, one-to-one for
every operation.  The advantage comes when you use some of the
features to generate a shape in an alternate way.  For example one
enhancement I made was supporting radius on squares.  Internally it
concatenates 4 90-degree arc paths, which isn't directly comparable to
any builtin modules.  I did a little bit of comparing this with other
methods of generating rounded squares (hull of 4 circles, etc.) and it
was the fastest of the methods I tested.

On Wed, Apr 5, 2017 at 1:34 AM, MichaelAtOz <[hidden email]> wrote:
> & text()
> ;)

Yeah I didn't put text since I consider that completely out of the
question. Its not possible to open files to read font definitions or
any other lower level font api that would give vertex data.  Even if I
could read files, i'm not particularly interested in implementing my
own truetype library or whatever it is that would be needed.

The other ones listed I could see maybe being feasible, but will
require some more research on my part as to what algorithms to use and
how to shoehorn them into the openscad language.

On Wed, Apr 5, 2017 at 9:21 AM, TLC123 <[hidden email]> wrote:
> Very nice.
> Subdivision and tesselletions?
> Domain warps?
> Be ware of self intersections though.

I haven't looked into the others, but subdivision is definitely a
possibility!  I developed some alternative sphere implementations
shortly before releasing this functional library:
https://gist.github.com/thehans/052129033443d8a8c14ac1e69b42e8da

At the bottom of the file is a subdivision function that is used for
generating the icosahedron based sphere.
I think I will add these to the repo soon, I just need to rewrite some
of the functions to be consistent with the interface conventions of
the rest of the library.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

Ronaldo
In reply to this post by thehans
It is a nice initiative towards filling a gap in the OpenSCAD arsenal: the access of vertex and face data. But it is unlikely that someone comes to write codes to the missing boolean , convex hull and minkowski operators of the library. So, IMO, the library value would be as test bed for the development of functions and operators demanding geometry inquires (like volume, centroid and non-linear operators) and as a good source for beginners learning.

There are proposals to fill that gap without any significant language change (#1324 and #1585) but it seems they have been postponed.
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
In reply to this post by Parkinbot
On Wed, Apr 5, 2017 at 10:28 AM, Parkinbot <[hidden email]> wrote:
> A very nice and consequent step into the right direction. However, OpenSCAD
> gains most of its power from its Boolean operations. At most you could offer
> some lazy union and bounding box calculations for "intended" Boolean
> operations but not more.

I think it should be theoretically possible to perform boolean
operations directly on the vertex/face data from within openscad.
They are definitely going to be some of the more involved code
compared with the other functions, that is why I put them off for some
of the last things to attempt.

I would probably try to replicate the simplest implementation that
I've seen which is this: http://evanw.github.io/csg.js/docs/
That code was the basis for the original OpenJSCAD code.  It actually
makes it look not so bad, though translating some of these functions
into openscad might prove difficult.  I'm not sure as I haven't yet
attempted it.

Wouldn't it be something if it could be done faster than the current
CGAL implementation?  :P
I'd give it 50% odds of being faster, assuming it gets written.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
I just added some more files to the repo.

The alternative_spheres and subdivision I had mentioned in a previous
post and those might have some niche uses, but double_fillet.scad is
one that I think is quite versatile and applicable to a wide range of
designs.
It creates a 2d path for a smooth transition between two heights by
having a top radius and bottom radius, and calculating the line
tangent to both for the slope in between the radii.
Then you can linear_extrude this 2d shape to create a sort of ledge on
a part, or rotate extrude to create a mound, protrusion, knob, and
even shapes roughly resembling a mushroom cloud!

If you load the double_fillet.scad file in OpenSCAD, you can view an
animated example of some of the possibilities with different
combinations of radii and offsets.

Or watch this short video animation:
https://photos.google.com/share/AF1QipPO5TCMSigJob_mThznq7jmtVjRaA_dSE-_LTLx76KZnfHrLHYEYpivonuTdGaWDQ?key=QzkwX2l2QUtmVXdpWjU3Q05SLW5DNUpFY29YSUJB

I've been developing some of these functions and ideas gradually over
time as I design new parts that need particular difficult features,
etc.  And I think the most powerful concept I've taken away from it is
a fairly simple one:  The creation of 2d paths, building them up by
concatenating lists of points and arcs, can be used to make really
nice designs with smooth fillets, and does so quite efficiently.
Every arc that can be placed as part of a 2d path before its extruded
is at least one less boolean operation required to make that shape.
At its heart the double fillet is just two arcs on a path.

Another example is this endstop mount design which I'm quite proud of:
  http://www.thingiverse.com/thing:2204123
In the scad for that, there is a module to create the "base_profile"
which is a fairly complex 2d shape that would have otherwise used
quite a lot of boolean operations.
All it is, is a bunch of arcs concatenated together (in the script the
function is called arcPath, I've since shortened it to just "arc" in
functional.scad )

http://i.imgur.com/FKqiiNr.png




On Wed, Apr 5, 2017 at 1:31 PM, Hans L <[hidden email]> wrote:

> On Wed, Apr 5, 2017 at 10:28 AM, Parkinbot <[hidden email]> wrote:
>> A very nice and consequent step into the right direction. However, OpenSCAD
>> gains most of its power from its Boolean operations. At most you could offer
>> some lazy union and bounding box calculations for "intended" Boolean
>> operations but not more.
>
> I think it should be theoretically possible to perform boolean
> operations directly on the vertex/face data from within openscad.
> They are definitely going to be some of the more involved code
> compared with the other functions, that is why I put them off for some
> of the last things to attempt.
>
> I would probably try to replicate the simplest implementation that
> I've seen which is this: http://evanw.github.io/csg.js/docs/
> That code was the basis for the original OpenJSCAD code.  It actually
> makes it look not so bad, though translating some of these functions
> into openscad might prove difficult.  I'm not sure as I haven't yet
> attempted it.
>
> Wouldn't it be something if it could be done faster than the current
> CGAL implementation?  :P
> I'd give it 50% odds of being faster, assuming it gets written.

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

NateTG
In reply to this post by thehans
> I think it should be theoretically possible to perform boolean
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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

kintel
Administrator
The dot notation shortcut isn't really documented, except through source code:
https://github.com/openscad/openscad/blob/master/src/expr.cc#L393

Not sure it's worth using as it may make code less readable for people not used to this syntax.
We should design such features in a better way.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

doug.moen
Marius said:
Not sure it's worth using as it may make code less readable for people not used to this syntax.
> We should design such features in a better way.

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 <[hidden email]> wrote:
The dot notation shortcut isn't really documented, except through source code:
https://github.com/openscad/openscad/blob/master/src/expr.cc#L393

Not sure it's worth using as it may make code less readable for people not used to this syntax.
We should design such features in a better way.

 -Marius


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
In reply to this post by kintel
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 <[hidden email]> wrote:

> The dot notation shortcut isn't really documented, except through source
> code:
> https://github.com/openscad/openscad/blob/master/src/expr.cc#L393
>
> Not sure it's worth using as it may make code less readable for people not
> used to this syntax.
> We should design such features in a better way.
>
>  -Marius
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

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

> On Jan 25, 2018, at 3:49 PM, Hans L <[hidden email]> 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 <[hidden email]> wrote:
>> The dot notation shortcut isn't really documented, except through source
>> code:
>> https://github.com/openscad/openscad/blob/master/src/expr.cc#L393
>>
>> Not sure it's worth using as it may make code less readable for people not
>> used to this syntax.
>> We should design such features in a better way.
>>
>> -Marius
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org


_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
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 <[hidden email]> 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.
>
>> On Jan 25, 2018, at 3:49 PM, Hans L <[hidden email]> 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 <[hidden email]> wrote:
>>> The dot notation shortcut isn't really documented, except through source
>>> code:
>>> https://github.com/openscad/openscad/blob/master/src/expr.cc#L393
>>>
>>> Not sure it's worth using as it may make code less readable for people not
>>> used to this syntax.
>>> We should design such features in a better way.
>>>
>>> -Marius
>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> [hidden email]
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

NateTG
> Do you have ideas for any other features you would like to see added?
(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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

togo
In reply to this post by thehans
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 <[hidden email]> wrote:

> 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 <[hidden email]> 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.
>>
>>> On Jan 25, 2018, at 3:49 PM, Hans L <[hidden email]> 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 <[hidden email]> wrote:
>>>> The dot notation shortcut isn't really documented, except through source
>>>> code:
>>>> https://github.com/openscad/openscad/blob/master/src/expr.cc#L393
>>>>
>>>> Not sure it's worth using as it may make code less readable for people not
>>>> used to this syntax.
>>>> We should design such features in a better way.
>>>>
>>>> -Marius
>>>>
>>>>
>>>> _______________________________________________
>>>> OpenSCAD mailing list
>>>> [hidden email]
>>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>>>
>>>
>>> _______________________________________________
>>> OpenSCAD mailing list
>>> [hidden email]
>>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>>
>>
>> _______________________________________________
>> OpenSCAD mailing list
>> [hidden email]
>> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
>
> _______________________________________________
> OpenSCAD mailing list
> [hidden email]
> http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org



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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

thehans
In reply to this post by NateTG
On Mon, Jan 29, 2018 at 9:08 AM, NateTG <[hidden email]> 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
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.

> 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

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
Reply | Threaded
Open this post in threaded view
|

Re: Functional OpenSCAD, working with vertex data

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

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

> ... I've *heard* of delaunay triangulation, for
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.

> ... Projective transform is already possible using a 4x4 matrix though,
> right? ...

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/

_______________________________________________
OpenSCAD mailing list
[hidden email]
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org
123