332 karma · joined September 11, 2024
Write honestly. Write the way you write. Use your own flow, make your own grammatical wobbles, whatever they are. Express yourself authentically.
Don't let an AI do this to you.
Shoot me in the face if my own writing is ever that bad.
ETA: just to be clear... I am not a great writer. Or a bad one. But this is a particular kind of bad. The kind we should all try to avoid.
But this is actually like a lot of LLM applications. For example: it's not terribly hard to learn to write a song; you don't even need to know an instrument. The songs LLMs write aren't better than novice songwriters. The difficult bit is turning a basic song into a great song, and novices who've skipped writing the song itself won't be better at it.
This whole idea seems contingent on imagining a situation where a non-CAD user has an idea for a truly novel physical object, has extensive geometry skills, and can describe that object in some magical level of detail that doesn't involve any terms of art from the CAD domain.
It's not a very likely scenario. And the energy put into tools to support this scenario would be better spent improving searchability of the data that is going to go into the training set, and simple tools to allow objects in the training set to be combined (such as those offered by TinkerCad or Microsoft's 3D builder).
It's also prone to the risk that the LLM gets something wrong: makes a part that is prone to failure, or will actually destroy a CNC, or be unprintable by a 3D printer, etc.
Not to mention that in this case, this disagreement over the meaning of ultra-fine detail will be happening with an LLM, which does not really understand the words.
Yep. I have two printed prototypes of different approaches to a mechanism on my desk that only exist because of months of staring at CAD in the evenings, learning new things, doing research.
They are not radical (they may be slightly novel in places; I have never seen 3D printed mechanisms like them).
I don't know if I could describe them in words at all, but if I could, it would only be because I worked through them in CAD in the first place.
For anything other than a trivial object I just can't see how you'd even come up with the words without having worked through the design -- what, on paper in 2D in pencil? After doing the maths? That's CAD in reverse.
If you can tweak the model in a CAD package, you can quite possibly make it in CAD in the first place more quickly than you can manage several rounds of descriptions with an LLM.
It's like the whole "I'd like to get an LLM to write a song and then I'd adjust it" thing. No musician needs this. If you can truly fine-tune a song, writing one is easy. And if you aren't a musician, you won't get good results fine-tuning a song.
This is what I think, and yet I am the longest time away from being an expert.
It's easier because CAD tools unlock CAD thinking and empower your brain to actually do design, as well as helping you see problems you didn't anticipate.
This whole area -- LLM to CAD -- is one of the most misguided applications for generative AI (beyond "generative design" as it was understood in the pre-LLM/pre-GAN era, where it was usually used for FEM/topology optimisation)
There are already enormous libraries of freely available basic CAD models for real-world objects; any beginner would be much better off simply learning how to merge them. And any tool aimed at beginners would be better off assisting that process (TinkerCad does, for example)
And if a beginner has a truly novel object to make, an LLM is not going to have the training set data to make it. Nor is the beginner likely to have the CAD knowledge (words, expressions) to describe it.
For this to be of use to a beginner you do have to imagine quite a niche kind of beginner: one who is expert in descriptive language and advanced geometry. Those people would be better off learning some sort of CAD environment; indeed they are the niche that is least likely to be driven insane by the limitations of OpenSCAD.
Even if you could do what you're suggesting with an LLM (I have my doubts) this result would be a mesh or 3D pixel grid or something, yes?
This is terrible for interoperability and it's the opposite of what mainstream CAD packages do.
Only if the result of the LLM is a good, well-architected parametric CAD model you can adjust, right?
I'm still really quite green at CAD; I've come to it late in life and I only make relatively simple things, perhaps; only simple mechanisms.
But when I look at people getting stuck and asking for help in CAD groups it so often comes down to the knock-on effects of very early mistakes, like squandering the benefits of the base planes by choosing the wrong initial orientation, muddling through with primitives when an extrusion of a sketch would do the job, or making a series of complex circular pockets when a single revolve could have done it better.
Basic familiarity with a few principles and their expression in CAD, and a little study of existing objects gets you a long way.
It interests me that programmers are willing to learn the expressive nuances of individual languages or libraries or methodologies, but as soon as it comes to GUI CAD they dismiss the whole thing as too hard or too obscure. The excitement around LLM text-to-CAD seems emblematic of this; as if the wrong conclusions about GUI interfaces have been drawn from bad experiences of dev GUIs.
I think this is one of those things that programmers overestimate worse than non-programmers, too. To the point that they reject CAD UIs too early and get themselves stuck in often rather limiting code-CAD environments, because they never get to learn how parametric GUI CAD works.
This belief that only code can be intuitively parametric is obviously not something that non-programmers suffer from.
I think code-CAD has many benefits (though the idea of the various LLM-to-OpenSCAD tools out there makes me shudder; this is the worst possible combination of obscure knowledge-bases).
But just a trivial amount of time learning even FreeCAD (the least-intuitive CAD package, pretty unambiguously) unlocks so much potential.
And appears now to be fixed.
And you're right it has a place. I'm not totally advocating switching if it works for you. But for newer users who want to really use code-CAD, out there are tools that are not held back by OpenSCAD's limitations (and which scale less painfully with complexity), and learning about them might help see simpler solutions or even bridge the gap to GUI CAD.
The most significant limitation I can see for a hobbyist maker is reaching the point where you can't make something yourself (or can't make it cost-effectively) and need to get it fabricated elsewhere. That is when you may very well find you would benefit from something OpenSCAD cannot (ever, I think) do: true, efficient STEP export.
As my 3D printed designs get more complex I am pushing closer and closer to the point where I will need a part cut conventionally out of steel or aluminium, or -- most likely sooner -- where I will need custom fasteners. One of the advantages of a workflow that will produce STEP is being able to work with someone who has those specialisations (and/or import work into the software tools they use). So at the earliest point I could, I made sure I was in that world. As a side bonus, it means being able to potentially use home CNC, or even just extract vector faces from generated models for use with a laser cutter or a Silhouette-type machine.
Out of completeness I should note that in that situation you're not totally out of options, as FreeCAD can interpret OpenSCAD in a bRep context with the exception of a few operations like minkowski() that get left as meshes. But it's a real limitation.
Right. OpenSCAD can import and mesh STEP files. But the process throws away the true geometry.
I agree that the raster/vector analogy is strong!
Plasticity (the sorta-CAD-sorta-modeller app) has seemingly just added some logic to the recent version to help with extracting the true geometry from meshes. I want to like Plasticity but it's not enough CAD for me right now.
(The programmer in me would love to be able to leave comments in more places on FreeCAD designs. I have spent a lot of time trying to learn how to make the simplest, most self-documenting parametric flow.)
But the reason I framed my comment above in terms of spending at least some time with CadQuery or Build123D etc. over OpenSCAD, is that CadQuery taught me additional CAD concepts that helped me make progress.
I had tried to use FreeCAD before, about 18 months before I finally got my 3D printer, but I was absolutely bamboozled. So when I finally started with my 3D printer, I started with OpenSCAD. I got small stuff done and held it in my hands, but I immediately felt its limitations (partly because I struggle with co-ordinate spaces and maths). Was I really going to be stuck doing all the maths, over and over again, or using libraries of specific functions like BOSL? My maths skills are weaker than I'd like, and it felt like a dead-end.
I stumbled on CadQuery, spent some time working on some key things in it, really immersed myself in the documentation, and this helped me grasp the bRep fundamental ideas of faces, vertexes and edges, normals, orientations, planes, etc. All the higher-order concepts in modern CAD above CSG.
I then had two things I knew could work for me -- CadQuery or in a pinch OpenSCAD. And because as you know there are/were workbenches for both, the knowledge gave me the confidence to spend time with FreeCAD.
Without stumbling on CadQuery I would have been stuck with OpenSCAD and it may have driven me away from trying to make my own things.
There are elements of my designs I will be (re-)building in Build123D to get some code-CAD advantages (scripted customisation). But it's the time with CadQuery that helped me make the transition to CAD thinking.
Say for example a single six-sided die: six faces, twelve edges.
But this would be twelve mesh triangles, right? None of which individually represent a face -- and six of the mesh edges are not edges in the true geometry.
A rounded six-sided die might have 26 faces (including the curved edges, rounded corners). 48 edges between them. etc. But the number of mesh triangles and edges will vary according to the precision.
bRep kernels can give you the geometry information, not just the mesh information.
(N.B. the Replicad studio code editor on that site seems to be broken today, which is a bummer -- it wasn't when I last checked)
CadQuery might not be in Ubuntu repositories on its own (same with Build123D -- these are python libraries really) but have you tried looking for cq-editor? (I think that's in Homebrew as well.)
https://snapcraft.io/install/cadquery-editor/ubuntu
To be fair I'd probably install the VSCode support for Build123D and CadQuery instead, because 1) this is code-CAD and you really manage it as such, and 2) I'm not that fond of the cq-editor environment.
https://marketplace.visualstudio.com/items?itemName=bernhard...
https://github.com/bernhard-42/vscode-ocp-cad-viewer
This extension can install Build123D or CadQuery for you if you have a python setup for VSCode.
I have certainly learned over time that when you're looking at an object that exists in the real world, one way to start to figure out how to model it is to figure out how it -- or its injection-mould positive -- was physically made. Can it be cut with a mill? Was it glued together in parts?
It absolutely is fun to try to work out how to come up with a shape subtractively from some giant primitive as if it was a block of steel. I often find myself visualising in terms of a scroll saw. I watched a couple of great videos about three-dimensional scroll-saw work and it weirdly affected my understanding of CAD!
The point for me is that, as a relative novice, I have got past some really important hurdles recently. So I can explain the benefits of getting past them to people who maybe don't know they are there.
I started off using OpenSCAD because it convinced me I'd be able to make something, quite quickly. My first two or three things were OpenSCAD things. It introduces you to stuff that isn't immediately obvious: the more complex booleans like difference of simple primitives, extrudes, lofts, sweeps, revolves. Great! I made things, I printed them, it was transformative.
(There's also quite a good thread library -- Adrian Schlatter's threadlib -- that I do want to say is very helpful and I learned a lot from.)
But it will likely hold back your development as a CAD user for even modestly complex things. Because you will never get access to the fundamentals of your objects -- the faces, vertexes and edges. Putting aside BOSL and the like, it leaves you stuck with a lot of increasingly complex maths, when if you could use the generated geometry you would not have to be. You would have much simpler operations relative to faces and edges.
This is why I said it would be worth spending at least some time with these tools. So you know what is out there.
It is a bug (well, a limitation), but AFAIR from my own designs, it generally only affects the low-precision, "fast" preview; in the final calculation it won't be an issue.
Nevertheless it is one of the things that is annoying as hell with the OpenSCAD previewer; constantly having to over-join to avoid it just makes the code more painful.
Coplanarity is generally a challenge in fast CAD previews.
You are right on a precipice between what you know, and falling into a deep, deep trough of CAD knowledge!
https://en.wikipedia.org/wiki/Tangent_lines_to_circles
You absolutely don't need to get into the maths to get value from this idea. The maths terrifies me. Just know this core concept: a tangent line meets a circle only once and is at right angles to the radius when it does.
Here's why this is valuable in CAD environments that properly support it: once you know how a tangent line works, and see how a constraint-based modeller represents them, it is possible to understand how to model a whole set of smoothly rounded features that the CAD package can automatically adjust to changes made to core measurements, retaining this perfect "join". Rounded slots, curved rounded slots, fillets, all sorts of interesting motion components, etc.
FWIW these don't have massive benefits for CAD modelling either. Most CAD kernels, even commercial ones, are sort of stubbornly single-threaded.
Sure, multi-threading can really help make the wider application feel more responsive, and a GPU is enormously useful for high-level photorealistic rendering as an end product. But it doesn't bring that much to bear on geometry solving, and the kind of 3D you need for CAD modelling and viewing is pretty old hat in OpenGL terms, I think?
And the way they are not the same is (as the GP is saying) rather telling about the challenge of getting really precise things working in OpenSCAD without a pretty solid grasp of maths.
[0] they might be functionally equivalent in application, which is not nothing, of course