But that said, this is all correct. OpenSCAD is actually an extremely limited environment and much more expressive tools exist in the same "code-based 3D modelling" space.
I saw this thread only because it's clearly a followup to the FreeCAD discussion the other day that I have contributed to.
--
People do get oddly grumpy when you criticise OpenSCAD; there is an element of the "I can do maths and refuse to believe CAD needs to be any more than this" militancy about it.
I absolutely don't hate it -- OpenSCAD's mere existence is what unlocked my ability to even reason in 3D, actually. But that quasi-militant tendency is holding back a fascinating, liberating software field.
https://www.goodreads.com/book/show/58059196-make
which has since become a series including:
Trigonometry: https://www.goodreads.com/book/show/123127774-make
Calculus: https://www.goodreads.com/book/show/61739368-make
Currently working through a library using the new Python-enabled OpenPythonSCAD, and at the end of it, hope to work on a project which requires conic sections (which I'm still researching, so if anyone has any good resources on that I'd be glad of them).
Joan Horvath is a superhero -- I've seen a few interviews now.
I will very happily use OpenSCAD for that because it seems like a well-chosen tool for the job.
Most of us don't realize how much our comfort with familiar concepts affects our ability to objectively evaluate them. Moving from dev to being a tech artist, I see the same exact sort of irrational biases, hang-ups and endemic misconceptions with completely different tool chains and types of complexity. When I first started using Houdini, I tried to turn every task into a Python coding problem because that's what I was comfortable with— Python is amazing in Houdini but it's definitely not the best way to accomplish most tasks.
The awful thing about OpenSCAD is that what one can create in it is strongly bounded by one's facility with and fluency in mathematics.
I'm curious how the new Python-enabled (I really hope it gets added in to the program itself) will affect this.
As an example, if doing V carving, the appearance will be smoother if the geometry is imported so as to have arcs/curves, deferring the conversion to polylines/straight line movements until the last possible moment on the machine.
Arcs/Curves are also easier to work with if one needs to edit, and are more efficient in terms of representation/disk space/storage.
CAM people, for example drive numerically controlled machines and robots. (CNC machines) These machines are driven by lines, arcs, higher order analytic curves, such as the conic, and recent controllers will accept bsplines.
Having path planning done with real geometric entities brings a lot of benefits along for the ride! Accuracy without a bazillion entities for the look ahead system to manage and for program buffers to drip feed (DNC) to a machine that probably does not have a large enough program memory to deal with that bazillion entities.
In many cases, derivative or extrapolated curves do not convey the right shape or path or are difficult and time consuming to force conformance.
We ended up with the big geometry kernels, such as Parasolid, precisely so that CAD could create a brep (boundary representation model) of sufficient fidelity to make other tasks, such as CAM and simulation, as well as derivative designs possible, practical, repeatable.
Those big code bodies have so damn many man hours of development in them it is very hard to replace it all. And that means we are stuck with some things, like many operations being single threaded, which caps CAD design to be a function of sequential compute speeds.
There are ways to build models to eliminate some dependencies, and the same goes for assemblies, so that multi-processing of some sort is possible. That brings our multi-core CPUs into the game.
But those are hard to teach, a lot of software does not yet support multi-threading anywhere near enough to fully exploit the model work, and, and, and...
In the CAD / CAM world, the primitive is the b-spline, and the surfaces it can represent.
Those generate faces, trim boundaries and sets of those create boundary representation models.
And still those can cause grief. They might be open, or just a surface representation. Or, they may self intersect...
Basically, every edge, which boils down to a b-spline curve that matches up to another b-spline curve serving as a trim boundary of a surface, must be shared by two and only two surfaces or the model is not representative of a real world, manufacturable thing.
Another great observation regarding real world objects is there are no edges, just radii, if only a single molecule big. Just an interesting and perhaps useful aside.
And b-splines are constrained to conform to the properties of lower order entities, such as lines, arcs, and the like. This is a part of why wireframe entities are all called "curves" or "sketch curves." They literally are all b-splines constrained by number and or placement of control points.
This doesn't work if you already have a mesh. You need to generate your triangles on demand from the BREP data.
Alternatively you need to use tesselation, but then you need to design your models with tesselation in mind, such as people do in blender.
>Isn't this how any rendering will ultimately work? The primitive is triangles.
Uhm no. 3D printing and CAM do not work with triangles. The slicer and CAM software generate tool paths in gcode.
Importing STEP files into OrcaSlicer/BambuSlicer gives me better quality results and better print speeds than using STL files.
I have personally never understood the love for STL files in the 3D printing community for anything that isn't the result of a blender export. Like, is it really that fun to constantly export different versions of STL files set to different quality levels? Rescaling a print in the slicer is not recommended with STL. You have to re-export the model from blender where the tesselation happens.
https://github.com/WillAdams/gcodepreview
See:
https://github.com/WillAdams/gcodepreview/blob/main/export.d...
Have you looked at grblgru.com ? Not opensource, but does have CNC lathe support.
I do not have any DXF of something like this.
[0] Some will import them now but convert them to triangles, cura can use a plugin to convert those triangles back to G2-G3 arcs or circles.
[1] at least by default, marlin has optional support for arcs that can be enabled at compile time.
OpenSCAD also has a lower barrier to entry in that the programming language and environment is familiar without needing a lot of training or context.
(With the addition of developer openness: directly meshing with Python or JS libraries)