| ▲ | dofm 4 hours ago | ||||||||||||||||||||||||||||||||||||||||
None of the "findings" here really needed an AI experiment to do it: - "CadQuery fails loudly and early... OpenSCAD fails silently and late" This should be obvious, from the documentation, from the way geometry construction works. OpenSCAD has no sense of failure where one shape means another won't work; you're just drawing the equivalent of 3D pixels in space. It will always potentially-meaninglessly succeed if the syntax is OK. - Renders caught nothing that mattered Objects with hollows are not going to show their major problems this way. - CadQuery can be interrogated, OpenSCAD cannot Isn't this explicit from the documentation of both? One works by iteratively building on top of a previous result that can be stored in a variable; the other doesn't. - OpenSCAD renders have no concept of a part edge Again — this should be explicit from the documentation, which describes no methods for operating on edges (and largely from the fact that it is declarative). - Speed favours OpenSCAD, and it barely matters Yes, being faster is no good if things are wrong. - "What decides it is verifiability rather than expressiveness, and CadQuery leads there by a wider margin than the syntax difference suggests." Yes, because the difference is semantic. Which you can get from the documentation. Building iteratively on the basis of existing geometry is inherently more verifiable, because stuff that can't work won't work. Honestly do people not try learning CAD before they try to build an AI tool to generate CAD models? This feels like yet another situation where people who have not done the foundational conceptual work seem to think that they can avoid it and just work around it with AI. | |||||||||||||||||||||||||||||||||||||||||
| ▲ | ricardobeat 3 hours ago | parent [-] | ||||||||||||||||||||||||||||||||||||||||
Your mistake is assuming “people” wrote this. | |||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||