GenCAD(gencad.github.io) |
Ironically the former is engineered to avoid the latter.
What is your workflow for llm integration to openscad?
I also wrote a bit about what goes into CAD apps! https://campedersen.com/tessellation
Which CAD program? I'm confused
Am I reading this right?
>Most importantly, GenCAD does not merely generate a 3D solid but also the entire CAD program.
Clue here: > Our proposed GenCAD architecture...
So, at this point, it seems like this will work with all CAD programs, since they have yet to encounter any systems that they can't work with. More seriously, my guess would be whatever one is available for free in their lab. Kind of standard operating procedure for academic projects -- do a proof of concept, make a video that avoids known bugs, get a grade, push source to git, graduate. Good ideas come out of that... production code... eh... maybe.
More likely someone ends up in the situation that my kid did, previous graduate student's git repo is stale by 2 versions of C++, and 4 versions of ROS, and neither of the two unit tests still work after porting.
Looks like you can go JSON -> step files, but not really in such a way that you can modify any of the operations.
Doesn't matter. CAD models/objects are represented by a sequence of operations on a primitive or sketch. Unlike meshes, that describe the manifested resulting shape of objects in 3D programs like Blender.
So it's about the fact, that their model outputs that hierarchy of operations. The history of development, not just the result.
"These fonts are licensed under the Open Font License. You can use them in your products & projects – print or digital, commercial or otherwise."
Then then have a trained llm that has can generate kcl to either create new parts or act as a llm assistant for changes to existing parts.
It’s neat that llms can do 3-D but I wonder how much of the problem is integration.
It's analogous to "all squares are rectangles, but not all rectangles are squares" (squares=CSG, rectangles=BREP)
CSG by itself isn't suitable for most CAD use-cases.
Code to compute fillets and blends gets incredibly complex when multiple surfaces are involved. And when surfaces are barely intersecting, or almost coincident, all bets are off what the command will do - very much depends on the geometry kernel and the tolerances it uses whether it decides the surfaces even intersect. And if it decides they don't intersect, all downstream commands will fail. Handling tolerances is one of the hardest aspects of CAD. (It's no coincidence that most open source CAD applications always demo with the same relatively basic types of models - they just can't do truly complex CAD.)
So a simple set of operations - cube, sphere, intersect - sure that will work anywhere and will be portable across applications and makes a nice simple demo. But once you start doing any serious CAD modeling the result is kernel dependent. That's why portable CAD formats like STEP do not preserve the commands used to generate the results. And why native CAD application formats do preserve the command history but are not portable across applications.