Re: STL best practices & tools
Hi Nerius,
I don't think the crowd here is receptive to the sort of stuff you wanna
do.
I'd suggest you build up your resumé on Linkedin and wait for people to
find you. You might also via Linkedin search out major companies who write
CAD/CAM software, I am sure you can compile a list of the usual suspects,
starting with Dassault/Catia and Autocad. Going to any specialist tech
conference will usually also generate employment leads as people attend to
hire.
Here in France a lot of nursing personnel felt the same way as you and
refused the jab and got fired; after suffering the side effects, I
certainly understand their pov. Interestingly the Facebook group where
people post descriptions and photographs documenting their issues is
labelled as "false information".
Edmund
On Sun, Jun 4, 2023 at 12:41 AM 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