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.