OpenSCAD - The Programmers Solid 3D CAD Modeller
openscad.org
openscad.org
That's not a damning critique, but it is something I'd advise a friend or colleague who had a project to get on with. I'm still highly positive about OpenSCAD, because of its openness, its versatility, and the potential for using great programmers' tools (library code, scripting languages and version control) to make it much more powerful.
I've been working with vanilla OpenSCAD, downloading a few functions from people, and building little libraries of helper functions. Getting more familiar all along, figuring out the right way to do things. Some people have got a little further with creating scaffolding for mechanical design - projects like MCAD and OMDL. Of course, OpenSCAD is very versatile and people have many other uses for it. But I think when someone comes along and creates some really great libraries and frameworks on top of OpenSCAD - like LaTeX on top of TeX or Jupyter on top of iPython on top of Python - it would be suitable for any kind of design, competitive with the best GUI-based packages.
However, as a programmer who dabbles in 3d printing / 2.5d CNC routing, I have the exact opposite experience. I spend a lot of time in Fusion 360 just battling the software because for some dumb reason it decided to align the top of my part with the bottom of the other when I actually wanted everything in the same plane.
OpenSCAD just makes a lot more sense to my programmer brain, and I'm often much more productive in it.
However, beyond the obvious graphical VS text interface, there's another significant difference between the two: OpenSCAD's base concept is making operations (add / subtract) on solid primitives (prisms, cylinders, spheres) whereas Fusion360 is based on 2d sketches that you extrude. That latter model works very well with a CNC router & plywood.
I'm sure you can get used to it eventually. But I think we could do better in terms of 'cad designed by programmers'
x = 5;
cylinder(d = x, h=10);
x = 20;
In a declarative languages, one should not be able to update variables. In some contexts, rebiding makes sense, but not on OpenSCAD either.
When I was using OpenSCAD about 10 years ago, I immediately found it very intuitive and easy to use for simple things. But for anything complex, I ran into this sort of thing constantly. At the time the documentation of the language mentioned such issues, but failed to specify the language completely, leaving lots of ambiguous cases that I just had to try out to see what would happen. The behavior really seemed to be something that just agglomerated as the author had added features, rather than something planned with a design philosophy behind it. I found it hard to work around and plan more complex shapes as a result. I haven't been back to look at the docs in ages; perhaps it's better-specified now.
I ended up doing my more complex stuff in an OpenSCAD clone I hacked together on top of https://evanw.github.io/csg.js/ until I ran into problems with non-manifold surfaces. Simple problems I could repair, but that library's really only intended for visualizations, not generating STLs for printing, so eventually I went beyond what I could fix.
So then I wrote an implicit surface renderer [also in JS] using https://github.com/mikolalysenko/surface-nets, and that was less-precise, and a bit limited [my code, not theirs], but got the job done. A short while later, I found implicitcad.org, and saw what I could have written, had I had just one more epiphany. I've never used it, but I like the philosophy behind it, and that may be what I try when I get back to 3D printing.
OpenSCAD really should throw an error on compile if you try to redefine variables, but its intent is a declarative language. Once you think of it as such, most of its design choices start to make sense.
Have you tried OpenJSCAD? It's OpenSCAD meets Javascript.
Now, to address the things you mentioned:
>I want to be able to make a cylinder from point A to point B.
You can write a function that does it in OpenSCAD already
> I want to be able to declare a cube and then refer to its corners.
Referring to vertices of a solid in general seems to be incompatible with OpenSCAD's paradigm of modeling with boolean operations. You don't know where the vertices are until you render.
You can already write a helper function which returns you the vertices of a cube. More than that, you would need another tool. It's not about syntax, to my understanding.
> Referring to vertices of a solid in general seems to be incompatible with OpenSCAD's paradigm of modeling with boolean operations. You don't know where the vertices are until you render.
Is it? Well I suppose it is in the general case. It would be hard to refer to an edge that has been created as a result of some difference operation. But the corners of a cube are still valid reference points even if they've been chopped off, and aren't part of the final solid.
Incidentally, I ended up needing a function that places a cylinder between two points in OpenSCAD yesterday.
Here is my implementation - might come in handy!
// Transpose of matrix A (swap rows and columns)
function transpose(A) = [for (j = [0:len(A[0])-1]) [for(i = [0:len(A)-1]) A[i][j]]];
// Cylinder of radius r from P to Q
module cyl_between(P, Q, r){
v = Q - P; // vector from P to Q
L = norm(v); // height of the cylnder = dist(P, Q)
c = v / L; // unit vector: direction from P to Q
is_c_vertical = ( 1 - abs(c * [0, 0, 1]) < 1e-6); //is c parallel to z axis?
u = is_c_vertical ? [1, 0, 0] : cross([0, 0, 1], c); // normal to c and Z axis
a = u / norm(u); // unit vector normal to c and the Z axis
b = cross(c, a); // unit vector normal to a and b
// [a, b, c] is an orthonormal basis, i.e. the rotation matrix; P is the translation
MT = [a, b, c, P]; // the transformation matrix
M = transpose(MT); // OpenSCAD wants vectors in columns, so we need to transpose
multmatrix(M)
cylinder(h=L, r=r, $fn=24);
}I've created a few small things in OpenSCAD. To build up a part, I haven't found a better way than just keep adding up the width of the subcomponents to get the origin of the next piece.
It is manageable for me, and I find traditional CAD programs difficult, so I'll keep using it. But I want a better way to do all this.
For me, within 6 hours Fusion was night and day more productive (even after a lot of experience in OpenSCAD). As one example, it was so much more productive that I can think of only 2 OpenSCAD designs in 5 years where I bothered to add fillets for strength and appearance. It's just too damn much trouble.
In Fusion360, I'll often have a simple part whipped up in 15 minutes and then spend 1 extra minute adding fillets and chamfers as needed. In OpenSCAD, that same part would likely be 30 minutes for the base part and the fillets another 15-30 minutes (with fairly poor performance once added).
Because it's so programmable, most things can be made fairly easy if you think of them in time, by writing procedures, once. I'm interested, actually: I would have thought that long-time users would have developed some sort of tip or trick for this, recognising at the start the kinds of changes that might be difficult to make laters and planning them in at the start. Maybe internal rounded corners are just too much hassle any way you look at it.
If you need boolean ops on cubes, cones, and spheres, OpenSCAD is great. If you need fillets on an oblique cylinder that intersects a curved surface, you're in for a much longer walk.
I have to admit that I’m not-so-secretly hoping someone will post “hey, here’s my secret to easy fillets in OpenSCAD” and I can learn a new trick.
https://cadquery.readthedocs.io/en/latest/quickstart.html
...and the fillet command is built-in:
https://cadquery.readthedocs.io/en/latest/classreference.htm...
Thanks!
https://github.com/revarbat/BOSL2
They come with fillet / chamfer masks, but in general I've been just using their cylinder / cube replacements that generate rounded intenral corners, and just diff'ing them out of existing shapes.
In general, I've gotten a long way by just starting with chamfered/filleted shapes (the library includes a neat way of specifying which edges of the shapes you want filleted), and using the intersection / difference of filleted cubes, cones, and cylinders.
Intersections on curved surfaces seem impossible any way of looking at it (minus some projection nonsense, but that's expensive in openscad)
Can't wait for freecad to get a useable UI, because it is works fairly well for printing despite its UX shortcomings
If it's a calibration issue on the printer (parts print, but are slightly the wrong size), I can recommend Teaching Tech's intro here and here:
https://teachingtechyt.github.io/calibration.html
https://www.youtube.com/watch?v=rp3r921DBGI
If it's in the Fusion->STL stage, I might be able to be of more help. If it's in the STL->physical part stage, the above or other 3DP videos might help.
My problem was that the produced STL had some errors that were hard to see but definitely showed up in prints, for example a wall section could be missing.
In the 3dp discords i'm a part of it seems that i'm continually reminding everyone that slicer features are usually the culprit. Features like 'detect thin walls', 'ensure vertical thickness' and 'extra perimeters if needed' can and will very quickly ruin a print where the STL is error-free.
That said, one can accomodate these features by modifying the STL so that the slicer transformation occurs in such a way that allows a usable product, but as far as where the error is introduced, 9 times out of 10 it's the slicer.
What should happen is that the slicer should err out to the user when the shape of the end product is predicted to be radically different than the request, but I haven't ran into such features yet. Most slicers just happily try to print stuff that is physically impossible to do, and might be radically different than the shape of the STL -- usually resulting in a plate of spaghetti if you're using an FDM machine.
https://www.instructables.com/id/Non-manifolds-Your-Worst-3D...
I've some years of experience with CAD and know often what causes such issues but in the case of fusion360 I just couldn't figure out why this happened - in sometimes extremely simple models.
I haven't used fusion360 for about a year so maybe they have fixed the bugs now.
I created a generic OpenSCAD model for the product, and fed in parameters derrived from more than a dozen data sources to generate a model for every variation. Then, took the 90th percentile by production numbers, and overlaid the models to show the boundaries of the variations as one model. That shape was then used to generate stack-able, vacuum-formed trays to hold the product.
I had a couple of expensive 3D CAD products at my disposal there, but OpenSCAD was the solution I needed to programatically crank out models. That's how my foray into programming started and my career shifted from Manufacturing Engineering to Software. Thanks OpenSCAD team!
Even if you don't like the OpenSCAD DSL (it got it's quirks..) there are usually other options in more familiar languages. I use it via Clojure[1]. It's pretty fun, even for small stupid things like coding up a rolling oloid[2].
I've actually been working on making the DSL language modular so that you could use it with any programming language (given bindings)
I use SolidWorks for work. The contrast between these two is incredibly striking. OpenSCAD is like a bicycle in comparison to an automobile.
It would provide literally billions (maybe tens or hundreds of billions) of dollars of value to the world if a few million dollars was spent developing an open source CAD/CAM package that was more than a mere bicycle and that wasn't terrible (sorry, FreeCAD, but we both know it's true). There needs to be an indiegogo campaign or something.
If your part doesn't need lofts, NURBs, extrude-along-path, you can probably design it about as fast in SolveSpace as in SW, and with a similar mindset (vs. having to shift completely into programmer-mode for OpenSCAD).
e.g. Hood of a car? No way José, can't be done. Crankshaft and pistons? Easy.
Modeling objects in my head parametrically is a snap.
The language is a bit clunky and counter-intuitive but I have gotten used to it. I do not mind its imperative nature; adding and subtracting material is imperative at its heart. Still, it makes more abstract reference points more difficult.
I found myself resorting to hacks like moving one object .001 into another object just to make sure they would meld smoothly.
The underlying library, last I checked, did not support multi-threading so the aforementioned CPU consumption is especially painful.
Exporting to giant .STL files is a little annoying. Sometimes the .STL files are "broken" according to Shapeways, so that is also bothersome.
In general I see OpenSCAD as a fun toy for making software-generated artwork, but not as a serious tool to make real things.
The documentation is also great. Once you have a basic grasp, this page is basically all you need.
https://www.openscad.org/cheatsheet/
Edit: Psych, you also need this:
https://en.wikipedia.org/wiki/List_of_trigonometric_identiti...
I've neglected this project, but I'm working on a library to make one's reasoning more explicit by providing math utilities.
The limitations caught up really quickly after that.
I echo what the other folks are saying. Its great, but there is no "I knocked this out in 10 minutes in OpenSCAD" for any part that couldn't be done in less time in TinkerCAD.
Its difficult to imagine how you could fix this elegantly. "Pick a path that follows the intersection of these two solids" is difficult to express in code, and easy to express by clicking on the vectors that represent the path.
It's been growing steadily in the last 7 to 8 years.
It was as if it uses some stochastic algorithm that sometimes doesn't converge...
It takes OpenSCAD files and generates meshes vastly faster for complex models.
A lot of big name 3d printing software are really badly written and perform horribly on complex models.
I used 4 open-source CAD programs before finally just concluding I need SolidWorks to do serious modeling. But I do still use one of the open source alternatives sometimes.
* Blender
OK, technically I didn't really give this a try for CAD. I had used it in the past for scene modeling and I knew it was extremely powerful for that but a huge pain for doing CAD-type work. Doing CAD with triangle meshes is total madness, CSG is the only way to go.
* OpenSCAD
I'll write the most about this because it's the subject of the article. If you come into this from a Blender background, it is awesome: finally I can define my model with a few key parameters, and have the program generate all the other dimensions from there! And CSG makes way more sense than meshes -- I can make a box, then put a hole through that box, then cut a countersink on that hole. Awesome.
But all the other parametric CAD programs have that stuff too. You've got constraints in sketches, support for formulas in equations, and templating features like linear patterns. So you can typically get the same level of flexibility where if you want to change your model in a big way, you just edit the few dimensions from which all else is derived. There are cases where you can't "program" your model in terms of those 3 common CAD features, while you can in an OpenSCAD file. But they are few and far between.
And the way the other programs do it is not only easier to "write" by clicking buttons on a UI, but much, much easier to "read" by viewing the sketch drawing. You can see how a sketch is defined a lot faster than you can understand the OpenSCAD code that does the same thing. Trying to revisit an old OpenSCAD project has a steep learning curve.
I really did fall in love with this way of defining models for a short time, but I realized that I was making more work for myself when the models I get out of other parametric CAD tools are equally "programmable" for practical purposes.
* FreeCAD
First thoughts: Wow! This thing is pretty cool! I found the default controls for moving the view a little "off" based on my past experience but that's easy to adjust to. And at first, FreeCAD is really impressive because it brings complex features to the table like "loft", which is something I really missed from SolidWorks. It's almost a must-have for my grip designs.
The main problem I had with FreeCAD is that it just breaks too often. When I started making complex designs using those features I loved so much, FreeCAD would get unstable. It's very frustrating to work on parts when the editor keeps crashing, sometimes mid-save corrupting the current file. I would have to go back to the drawing board and try another way of defining the same shape in hopes that FreeCAD liked the new way better. Ultimately I just got too annoyed by it. Also, I really wished that I could use guide curves for lofts -- but here I am asking them both to make a complex feature MORE complex AND to fix the existing bugs with it, which is a really tall order.
FreeCAD is an amazing achievement for volunteer work but it's not useful to me.
* SolveSpace
With its unconventional looking UI, this seemed like it was going to be one of those idiosyncratic open source programs like Blender or GIMP where you spend half the time just cursing them out for doing things a weird way and making you learn it.
On the contrary, once I worked through the first tutorial on their official website, I felt like I had a pretty good understanding of the program. Some stuff like defining new workplanes was still a bit confusing, but I got the hang of it. The shortcut keys are super handy and easy to learn by hovering the buttons. Best of all, SolveSpace is fast and usually stable -- though you can get it to stack overflow, sometimes on save, by turning up the modeling resolution too far.
This lacks advanced features like the aforementioned loft, and sadly lacks a quick fillet/chamfer tool too. The modeling resolution thing can be a little bit of a pain (OpenSCAD has this problem even worse) coming from a commercial tool like SolidWorks where you don't even think about it until it's time to export to STL.
But overall, SolveSpace is a good example of keeping it simple, constraining the feature set to something manageable and then just doing that well. So I still use it now and then for quick stuff where I know I'm not going to need flowing 3d surfaces, just boxy extruded things with a few curved edges. It feels a lot more responsive than SolidWorks -- it's like using a text editor vs. using MS Word.