---------- Forwarded message ----------
From: neri-engineering neri-engineering@protonmail.com
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc:
Bcc:
Date: Sat, 03 Jun 2023 22:41:02 +0000
Subject: [OpenSCAD] STL best practices & tools
Greetings,

I want to begin to seek advice on an OpenSCAD-related project (improvement
or addition) in my writings below; however, first I offer a quick
introduction.

I use OpenSCAD to create hobby engineering designs and assembly
animations.  I have shared some of these before.  I want to share my latest
computer animation which was generated using OpenSCAD, along with the
top-level scripts used to generate it; in the case that someone wants to do
something similar they may draw upon my work for inspiration and ideas.

The animation itself (and I'm sorry if some people are offended with the
posting of an external link):
https://odysee.com/@Neri_Engineering/4wd-motor-mount-assy

The entry points into the program to generate the above computer animation:

https://sourceforge.net/p/nl10/code/HEAD/tree/scripts/4wd/motor/4wd-motor-mount-assembly-animation.sh
(entry point + camera work)

https://sourceforge.net/p/nl10/code/HEAD/tree/code/gears/4wd/motor/anim/4wd-motor-mount-assembly.scad
(movement of parts, part definitions)

At some point I could possibly “Nerf” down those animation scripts to
create something extremely barebones and simple, and then I could make a
video presentation/lecture describing it.

Next, I am looking for employment opportunities.  BERKELEY GRAD (MATH+CS),
EXPERT IN 3D COMPUTER GRAPHICS, THREADED PROGRAMMING, LOW LEVEL NETWORK
PROGRAMMING.  UNIX POWER USER.  FREEBSD, LINUX.  JAVA / C / PYTHON.  IN
TEXAS, SEEKING TO RELOCATE.  CURRENTLY EMPLOYED.  HAVE REFERENCES.

Okay, now onto the main topic of this email.

As I was studying other open source projects related to OpenSCAD I noticed
something interesting.  In particular I recall looking at some code to
generate spur gears, and other code that was for generating screw threads
(using the polyhedron() native construct in OpenSCAD).

I noticed that programmers have a habit of creating polyhedron that
overlap with their neighbors, so that when STL is generated, it consists of
one piece and not of many individual pieces.

Yes, it makes sense to do that.  I do understand why.

But, it makes a large project unmanageable, in my opinion.  For one,
usually, "fudging" the vertices on polyhedron() will result in very "jaggy"
objects, with extra vertices and extra little jaggies everywhere.  This is
obviously undesirable.

Second, it's not a pure approach in the mathematical sense.  When you
start doing boolean operations (add, subtract, intersect, etc.) with jaggy
and imprecise objects then things get very hairy and very quickly.

In all of my code, my mathematical intuition initially told me
instinctively to never fudge vertices in order to make polyhedron overlap,
and to instead keep everything as accurate and as precise as possible, with
the consequence that generated STL will be made up of many little pieces
(undesirable).

Now I am at a point where I need to address these issues, of having
generated STL that consists of many little pieces.

With time I will likely need to create STL to 3D print from, or to use to
make forms for injection molding, and with more time I will need to
transfer much of my work to other tools such as FreeCAD (Python scripts) in
the case where those parts need to be machined from metal, using CNC.

But, I was thinking about the possibility of creating a post-generation
"STL cleanup tool", and I'm sure that such tools already exist.  I was
imagining a tool which is configurable with "epsilon values" which will
treat sufficiently close numbers as being equal (configurable of course),
and will determine which faces are co-planar and which ones aren't.  I
already have lots of experience with this sort of technique from my days of
writing line-drawing algorithms that use full aliasing (no anti-aliasing)
with blocky pixels, yet which allow end point coordinates to be specified
in 64 bit floating point.  You are then able to draw very old-fashioned and
retro-looking pixelated lines (which look similar to the Bresenham style of
line) yet you're able to perfectly overlap sub-segments of the line.  For
example, if you draw your original line from (0.0,0.0) to (5.0,13.0), two
prime numbers that is, then you can draw a subsegment covering only half of
the original line (0.0,0.0) -> (2.5,6.5), where every single pixel in the
subsegment is almost guaranteed to cover a pixel in the original line
segment.  I say "almost" because usually this sort of operation entails
viewing the 64 bit representation of a floating point number in 32 bits, in
order to determine whether or not two numbers are sufficiently close to be
deemed equal.  There are always, or at least usually, going to be some very
rare cases where such calculations won't lead to desired results, due to
the nature of number approximations that usually happen in computers
(unless real number systems are used, which are computationally very
expensive).

I imagine using an approach similar to that of my near-perfect retro
line-drawing algorithm, in order to implement an STL cleanup tool which
combines STL pieces that "touch" into one solid object.  ("Touch" within an
epsilon value which is configurable.)  These are early ideas into such
functionality.

I have also in the past implemented a spacial 3D search tree, “R-tree” to
be exact, which optimizes the determination of whether or not two small
things are intersecting or not.  When analyzing STL files full of many
small little pieces, it would make sense to optimize boolean operations
through the use of a structure such as an R-tree.  There are research
papers written that describe the algorithm for the R-tree.  The R-tree has
very favorable time complexity characteristics, and it would be well-suited
for this sort of operation.  I implemented and used an R-tree (written in
Java) while working at a research laboratory at the University of
California, with excellent results.

So I ask, does such “STL clean-up” functionality already exist?  I think
no doubt it would by now.  But are such tools implemented correctly and are
they effective?  Can they handle the cleanup of STL files that consists of
hundreds, or thousands of tiny pieces?  For example I found myself needing
to implement my retro line drawer twenty two years ago because I didn't
find anything similar on the internet (and still can't).  I needed that
"retro line look" but wanted precise subsegment-covering properties for my
Blockout video game, so I implemented my own line-drawing library.

I imagine some post-OpenSCAD piece of code, which handles STL files
outside the scope of OpenSCAD, to allow for cleanup of STL files.  I
imagine this being written in Java, in C, or in Python.  I also imagine
that if such a piece of code is successful enough, that it may be
incorporated into OpenSCAD “proper” eventually (which is a great tool by
the way!).

For these reasons I seek some guidance.  I would like to potentially
embark on this mission of writing such a toolset in the near future, unless
such a toolset already exists, and unless it does a proper job.

This sort of work is right up my alley by the way.  I excel in
computational geometry and the like.  I think there would be extensive use
of recursive functions and intelligent ways of triangulating surfaces which
need to be split up and combined, in the ideal piece of code which I’m now
starting to imagine.

I interviewed with Materialise in Belgium (actually with a subsidiary in
Princeton NJ) but didn’t get the offer because of my unwillingness to take
the jab.  They were receiving financial help from a medical device company
(a client of theirs), which influenced their decision to mandate the jab
for all of their employees.

What I’m trying to say is that I find it odd that someone such as myself,
with my level of intelligence, talent, skill, and ambition, isn’t able to
find a way to sustain himself doing the type of work that he is best at.
At the very least I deserve a chance to be a contributing member of larger
society.  People such as myself oftentimes end up asking themselves,
whether the problem is internal to themselves or whether it’s a problem
with the people running our world.

Any feedback appreciated. on this sort of tool.  I am in the early stages
of thinking about such a tool at this point.  It’s the sort of thing I
would like to work on in the future; and, I would be very good at it.  I've
been away from this email list for a while because I have been so busy with
my hobby projects.

Respectfully,
Nerius Anthony Landys

Sent with Proton Mail https://proton.me/ secure email.

---------- Forwarded message ----------
From: neri-engineering via Discuss discuss@lists.openscad.org
To: OpenSCAD general discussion Mailing-list discuss@lists.openscad.org
Cc: neri-engineering neri-engineering@protonmail.com
Bcc:
Date: Sat, 03 Jun 2023 22:41:02 +0000
Subject: [OpenSCAD] STL best practices & tools

OpenSCAD mailing list
To unsubscribe send an email to discuss-leave@lists.openscad.org

You're doing some serious mental gymnastics if you're wondering why
you can't work in a social group when you haven't gotten vaccinated.
Self-defeating behaviors that make your presence toxic to the group
will lead to rejection and/or exclusion by groups. If the job offer
was dependent on actually working in physical proximity in an office
because work-from-home isn't possible, they were quite reasonable to
reject you.

On Sat, Jun 3, 2023 at 4:41 PM neri-engineering via Discuss
discuss@lists.openscad.org wrote:

 ---------- Forwarded message ----------
 From: neri-engineering <neri-engineering@protonmail.com>
 To: OpenSCAD general discussion Mailing-list
 <discuss@lists.openscad.org>
 Cc:
 Bcc:
 Date: Sat, 03 Jun 2023 22:41:02 +0000
 Subject: [OpenSCAD] STL best practices & tools
 Greetings,

 I want to begin to seek advice on an OpenSCAD-related project
 (improvement or addition) in my writings below; however, first I
 offer a quick introduction.

 I use OpenSCAD to create hobby engineering designs and assembly
 animations.  I have shared some of these before.  I want to share
 my latest computer animation which was generated using OpenSCAD,
 along with the top-level scripts used to generate it; in the case
 that someone wants to do something similar they may draw upon my
 work for inspiration and ideas.

 The animation itself (and I'm sorry if some people are offended
 with the posting of an external link):
 https://odysee.com/@Neri_Engineering/4wd-motor-mount-assy

 The entry points into the program to generate the above computer
 animation:
 https://sourceforge.net/p/nl10/code/HEAD/tree/scripts/4wd/motor/4wd-motor-mount-assembly-animation.sh
 (entry point + camera work)
 https://sourceforge.net/p/nl10/code/HEAD/tree/code/gears/4wd/motor/anim/4wd-motor-mount-assembly.scad
 (movement of parts, part definitions)

 At some point I could possibly “Nerf” down those animation scripts
 to create something extremely barebones and simple, and then I
 could make a video presentation/lecture describing it.

 Next, I am looking for employment opportunities. BERKELEY GRAD
 (MATH+CS), EXPERT IN 3D COMPUTER GRAPHICS, THREADED PROGRAMMING,
 LOW LEVEL NETWORK PROGRAMMING. UNIX POWER USER.  FREEBSD, LINUX. 
 JAVA / C / PYTHON. IN TEXAS, SEEKING TO RELOCATE.  CURRENTLY
 EMPLOYED. HAVE REFERENCES.

 Okay, now onto the main topic of this email.

 As I was studying other open source projects related to OpenSCAD I
 noticed something interesting.  In particular I recall looking at
 some code to generate spur gears, and other code that was for
 generating screw threads (using the polyhedron() native construct
 in OpenSCAD).

 I noticed that programmers have a habit of creating polyhedron
 that overlap with their neighbors, so that when STL is generated,
 it consists of one piece and not of many individual pieces.

 Yes, it makes sense to do that.  I do understand why.

 But, it makes a large project unmanageable, in my opinion.  For
 one, usually, "fudging" the vertices on polyhedron() will result
 in very "jaggy" objects, with extra vertices and extra little
 jaggies everywhere. This is obviously undesirable.

 Second, it's not a pure approach in the mathematical sense.  When
 you start doing boolean operations (add, subtract, intersect,
 etc.) with jaggy and imprecise objects then things get very hairy
 and very quickly.

 In all of my code, my mathematical intuition initially told me
 instinctively to never fudge vertices in order to make polyhedron
 overlap, and to instead keep everything as accurate and as precise
 as possible, with the consequence that generated STL will be made
 up of many little pieces (undesirable).

 Now I am at a point where I need to address these issues, of
 having generated STL that consists of many little pieces.

 With time I will likely need to create STL to 3D print from, or to
 use to make forms for injection molding, and with more time I will
 need to transfer much of my work to other tools such as FreeCAD
 (Python scripts) in the case where those parts need to be machined
 from metal, using CNC.

 But, I was thinking about the possibility of creating a
 post-generation "STL cleanup tool", and I'm sure that such tools
 already exist.  I was imagining a tool which is configurable with
 "epsilon values" which will treat sufficiently close numbers as
 being equal (configurable of course), and will determine which
 faces are co-planar and which ones aren't.  I already have lots of
 experience with this sort of technique from my days of writing
 line-drawing algorithms that use full aliasing (no anti-aliasing)
 with blocky pixels, yet which allow end point coordinates to be
 specified in 64 bit floating point.  You are then able to draw
 very old-fashioned and retro-looking pixelated lines (which look
 similar to the Bresenham style of line) yet you're able to
 perfectly overlap sub-segments of the line.  For example, if you
 draw your original line from (0.0,0.0) to (5.0,13.0), two prime
 numbers that is, then you can draw a subsegment covering only half
 of the original line (0.0,0.0) -> (2.5,6.5), where every single
 pixel in the subsegment is almost guaranteed to cover a pixel in
 the original line segment.  I say "almost" because usually this
 sort of operation entails viewing the 64 bit representation of a
 floating point number in 32 bits, in order to determine whether or
 not two numbers are sufficiently close to be deemed equal.  There
 are always, or at least usually, going to be some very rare cases
 where such calculations won't lead to desired results, due to the
 nature of number approximations that usually happen in computers
 (unless real number systems are used, which are computationally
 very expensive).

 I imagine using an approach similar to that of my near-perfect
 retro line-drawing algorithm, in order to implement an STL cleanup
 tool which combines STL pieces that "touch" into one solid object.
  ("Touch" within an epsilon value which is configurable.)  These
 are early ideas into such functionality.

 I have also in the past implemented a spacial 3D search tree,
 “R-tree” to be exact, which optimizes the determination of whether
 or not two small things are intersecting or not.  When analyzing
 STL files full of many small little pieces, it would make sense to
 optimize boolean operations through the use of a structure such as
 an R-tree.  There are research papers written that describe the
 algorithm for the R-tree.  The R-tree has very favorable time
 complexity characteristics, and it would be well-suited for this
 sort of operation.  I implemented and used an R-tree (written in
 Java) while working at a research laboratory at the University of
 California, with excellent results.

 So I ask, does such “STL clean-up” functionality already exist?  I
 think no doubt it would by now.  But are such tools implemented
 correctly and are they effective?  Can they handle the cleanup of
 STL files that consists of hundreds, or thousands of tiny pieces?
 For example I found myself needing to implement my retro line
 drawer twenty two years ago because I didn't find anything similar
 on the internet (and still can't).  I needed that "retro line
 look" but wanted precise subsegment-covering properties for my
 Blockout video game, so I implemented my own line-drawing library.

 I imagine some post-OpenSCAD piece of code, which handles STL
 files outside the scope of OpenSCAD, to allow for cleanup of STL
 files.  I imagine this being written in Java, in C, or in Python. 
 I also imagine that if such a piece of code is successful enough,
 that it may be incorporated into OpenSCAD “proper” eventually
 (which is a great tool by the way!).

 For these reasons I seek some guidance.  I would like to
 potentially embark on this mission of writing such a toolset in
 the near future, unless such a toolset already exists, and unless
 it does a proper job.

 This sort of work is right up my alley by the way.  I excel in
 computational geometry and the like.  I think there would be
 extensive use of recursive functions and intelligent ways of
 triangulating surfaces which need to be split up and combined, in
 the ideal piece of code which I’m now starting to imagine.

 I interviewed with Materialise in Belgium (actually with a
 subsidiary in Princeton NJ) but didn’t get the offer because of my
 unwillingness to take the jab.  They were receiving financial help
 from a medical device company (a client of theirs), which
 influenced their decision to mandate the jab for all of their
 employees.

 What I’m trying to say is that I find it odd that someone such as
 myself, with my level of intelligence, talent, skill, and
 ambition, isn’t able to find a way to sustain himself doing the
 type of work that he is best at.  At the very least I deserve a
 chance to be a contributing member of larger society.  People such
 as myself oftentimes end up asking themselves, whether the problem
 is internal to themselves or whether it’s a problem with the
 people running our world.

 Any feedback appreciated. on this sort of tool. I am in the early
 stages of thinking about such a tool at this point.  It’s the sort
 of thing I would like to work on in the future; and, I would be
 very good at it. I've been away from this email list for a while
 because I have been so busy with my hobby projects.

 Respectfully,
 Nerius Anthony Landys

 Sent with Proton Mail <https://proton.me/> secure email.



 ---------- Forwarded message ----------
 From: neri-engineering via Discuss <discuss@lists.openscad.org>
 To: OpenSCAD general discussion Mailing-list
 <discuss@lists.openscad.org>
 Cc: neri-engineering <neri-engineering@protonmail.com>
 Bcc:
 Date: Sat, 03 Jun 2023 22:41:02 +0000
 Subject: [OpenSCAD] STL best practices & tools
 _______________________________________________
 OpenSCAD mailing list
 To unsubscribe send an email to discuss-leave@lists.openscad.org

OpenSCAD mailing list
To unsubscribe send an email todiscuss-leave@lists.openscad.org