OpenSCAD exists, is perfectly usable, is very cool, and stores CAD models 'as code' which is git-friendly. Professionals don't use it. I like it, but I would never standardize on it at work. I'm sure a more point-and-click front-end is certainly possible, but that nobody has tried something quite so obvious probably speaks to its incompatibility with use common use cases. I use Autodesk software daily, and merely representing 3D objects is a very small part of the utility it provides. The software is undoubtedly an unstable mess, but feature parity with Revit or just Fusion 360 is far beyond a pizza-box team of 'disruptors'. There is also a culture of professionalism and practicality in AEC that I don't see folks used to coastal VC/startup playgrounds doing well in.
I also find it pretty hard to take the contents of an article seriously when there's name-dropping of celebrity-developers whose business appears to be self-promotion. "I use vim, btw ;)" really puts the nail in the coffin for me. I'm sure CAD-but-on-electron would look great on a slide deck, though.
OpenSCAD is cool and I do use it when it is the most convenient tool, but I find it to be incredibly slow, and if you don't want the output to be all blocky polygons (which you can only achieve by increasing $fn AFAIK) then it gets even slower.
It also suffers from not having any general-case way to fillet or chamfer edges, which means you have to bear your fillets/chamfers in mind throughout the entire design if you want any (which is why most OpenSCAD designs don't bother).
There is actually a general-purpose way to do fillets in OpenSCAD, using a slightly Rube-Goldberg combination of booleans and minkowski sums. Unfortunately it is, again, far too slow to be usable in 3d at anything like an acceptable resolution. It works great in 2D however.
It's general if you want an equal fillet on every edge, but it's not "general" in the sense that you can apply fillets and chamfers of different sizes to different edges.
Unless you plan to do so from the very start and design your entire part accordingly.
- the model is describable mathematically
- the model description is simple enough that performance isn't an issue
- a supported form of output is workable (DXF, SVG using straight lines, STL)
It's not possible to get a nice text file out of it w/o jumping through hoops, doing CAM directly is frowned upon, and quickly brings the program to its knees (just modeling cutting out a hemisphere w/ an endmill resulted in a file which took minutes to render, and left the program barely usable).
Apparently these folks did an article on Medium.com as well:
OpenSCAD is a neat tool, but it has a few huge drawbacks for real world use:
- a weird domain specific language that only adds a bit of syntactic sugar and is a pain to learn. They would have been *way* better off using Python and extending it.
- no filet / chamfer tool. No CAD program can be taken seriously unless it has those.
- the CAD core is (IIRC) CGAL, which only works with polygonal models and is god-awful slow as soon as the model gets complex. For example, Minkowski sums are basically unusable on any real-world model.
What is really neat about OpenSCAD is the notion that a 3D object is basically code.
This brings in for free a ton of very nice things:
- version control
- collaborative editing
- parametric modeling
- object optimization
I also find it pretty hard to take the contents of an article seriously when there's name-dropping of celebrity-developers whose business appears to be self-promotion. "I use vim, btw ;)" really puts the nail in the coffin for me. I'm sure CAD-but-on-electron would look great on a slide deck, though.