OpenSCAD isn't perfect, but it's so plainly obvious that code-based CAD is a better idea to me that it sort of bothers me that it's not the default.
Being able to utilize actual code to do anything allows you to use any kind of logic to create your models. I'm sure that someone could write something that would convert KiCAD stuff into a Fusion 360 model, but since SCAD is "just text", it is categorically easier to work with.
I was never able to really do anything productive with FreeCAD or CorelCAD, but I've been able to make tons of 3D prints from SCAD designs. The model just jives with my brain a bit better.
If anyone here likes SCAD, I highly recommend checking out Bowler Studio as well [1]. It's more robotics-focused than OpenSCAD, but free and open source, has its own "JavaCAD" DSL that lets you write in Java or Groovy or Clojure or Kotlin or Python to do CSG, and you can tack on a physics engine to test things out. The interface is still pretty clunky but it's definitely pretty cool software that I think is worth playing with.
> it's so plainly obvious that code-based CAD is a better idea to me that it sort of bothers me that it's not the default.
I'm a software developer, but I'm also a 3D print designer and a woodworker. OpenSCAD is really unfriendly once you want to get past "I have a box and the box needs to connect to another box"; cadquery and especially build123d are more promising for sure, but the environment and the affordances are clumsy compared to "draw a sketch with a mouse and extrude a thing" in Fusion. Maybe if my alternative was FreeCAD (thankfully it's not) code-based CAD would feel like a better alternative, but it's not, and like--if I have to contort myself to make a fillet work, I would simply not bother. And if I have to sit there, squint, and change a variable and wait for a recompute, rather than dragging the thing to where I want it, I'm also probably not gonna bother with that, either. I tried; it doesn't work for me, and sweeping universal statements about this stuff are Pretty Weird.
On the other hand, having access to a kernel like Fusion's, plus their Python scripting environment, is pretty nice for me, and I enjoy building tools to manipulate that. But those tools don't take center stage; the visuals and the chain of features do that.
> "I have a box and the box needs to connect to another box"
I have gotten more elaborate shapes like gears and screws with OpenSCAD, but I will admit for more elaborate projects I use BowlerStudio since I find found it easier to use some of the JavaCAD stuff.
I've just never been able to get the hang of mouse controls, even in Fusion 360; in SCAD if I need to extrude a bizarre shape, I will occasionally draw the thing into an SVG, import it into SCAD and linear extrude from there.
The rendering time is a fair complaint though; with complicated models, especially with a high $fn value, re-rendering can be pretty slow. I don't really have a good response to that, I just put up with it because I feel the other perks of code-based CAD make up for it.;
Obviously to each their own. I do wish that code-based CAD is better but I'm not a mechanical engineer, just an enthusiast with a 3D printer.
> I've just never been able to get the hang of mouse controls, even in Fusion 360
I can relate to this -- I would consider myself 3D-clumsy. But learning the various navigation tools in FreeCAD (numbered views, the navigation cube, the new orient-to-face option) has helped me a lot.
And I think fundamentally not being so intimidated by the rest of the package means it's more worth persevering with that stuff.
(Also FreeCAD's trackpad+keyboard gestures are basically usable)
> Obviously to each their own. I do wish that code-based CAD is better but I'm not a mechanical engineer, just an enthusiast with a 3D printer.
Indeed. It's fabulous that we have choices in open source CAD, open source slicers, open source printers. It's just wild to me -- it actually makes me emotional -- that I can make some of the things I want from my thoughts at such low cost.
But do check out Build123D; I think it will get you to another level.
Yeah, I see Build123D being referenced a lot here. I'll give it a try, though I suspect I'll probably stick with Bowler Studio because I actually use the physics and robo simulation stuff a lot.
Bowler Studio was entirely new to me, so thanks for mentioning it.
One random mention: Nick Lockwood's ShapeScript, which is another code-CAD thing based around a mesh CSG environment (and pretty unusually runs on iOS)
Bowler Studio was sort of revelatory for me, because it gave me the ability to model a functional part and immediately test it. The physics engine obviously isn't going to be the most accurate of all time, but for a lot stuff that hobbyists do it can be useful, and being able to play with servos and motors really does open a lot of possibilities to avoid wasting time and prints.
I've actually played with ShapeScript but I admit that I didn't do anything terribly crazy with it.
Yeah I've only dabbled with it myself. Again it was part of this process of me orienting myself towards "thinking in 3D" and I'm really grateful to much more 3D-literate developers than me that we have so many choices.
This is a browser-based JS CAD thing built around an Emscripten cross-compilation of OpenCascade -- the fact that it works at all was revelatory to me about the capability of Emscripten, which had passed me by a little.
FreeCAD isn't perfect obviously (but neither IMO is the situation with any 'gratis' tier of commercial CAD). You pays your no money and you takes your complicated choice.
Rules for FreeCAD fillet and chamfers:
- In OpenCascade, dress-up operations like fillets and chamfers unfortunately can't wholly consume existing edges; this explains almost all the reasons why they fail.
- So if it's only dress-up, presentational stuff, do it last, or as late as you can in any given part
- If a fillet or chamfer is structural or fundamental, consider adding it to the sketch (there are constraint-preserving fillet tools, and now in 0.22-dev/future 1.0 the same is true for chamfers)
- If you need to fillet or chamfer generated geometry, consider how you might add it/cut it out with sweeps or grooves.
This is a bit of a pain, but it's nowhere near as much of a pain as trying to do them in OpenSCAD!
FreeCAD does a better job of it than OpenSCAD does, yes. ;) Agreed on all points; the reason why the rules you describe are the way they are make sense to me, and I could use FreeCAD if I had to. But I pay for Fusion because it's worth it to me.
Yeah. I've always been of the opinion that, having got myself from OpenSCAD to GUI CAD, I will jump from FreeCAD to onShape/Fusion360 if I feel I have to -- or do my CAD work on a Windows machine with Alibre.
I feel fairly at home on FreeCAD and some of the recent improvements and developments just make it even better. Plus there's a lot of actually good tutorial material on Youtube now. So for now I am happy not to jump.
(I do tend to make this decision individually for each software application, though; I'm unwilling to limit myself to GIMP when there are other alternatives to Photoshop. But I might well be willing to stick to Inkscape.)
> since SCAD is "just text", it is categorically easier to work with.
I'm happy that you have found the tool you like. I would be vary to be so categorical about something which is fundamentally a preference on your part. I'm not here to tell you that your choice of tool is wrong, and I expect the same courtesy back.
When I'm designing I'm creating 2d drawings and 3d bodies. Seeing those things and directly manipulating them is a big benefit for me.
This orrery is the most complicated 3d object I ever designed: https://www.youtube.com/watch?v=FGdjk5fY87s In particular the roundish bent shape which fixes the upper bevel gears together and holds the reducer gear train at the right depths while also holding the planet's shaft at the right angle. I have no idea how I could have designed that without graphical feedback.
Sure, I'll acknowledge that I might have made a bit of a sweeping statement.
I'm not an artist or anything, and while I have made some relatively complex models with Bowler Studio (probably the coolest being a functioning toy elevator for some action figures that I was able to test out digitally before building it IRL, which required a stepper motor and a Z-screw stolen from a broken 3d printer), I'll acknowledge that I am a software engineer first and so of course I stare at plain text multiple hours every day, and that of course defines how I think about problems.
I do think that there are aspects of code-based CAD that do meet some standard of objectivity of being "better", or at least more versatile. I think being able to easily define loops and variables is a feature that is remarkably useful and allows for a lot of flexibility that I haven't really seen in any GUI program.
Also, OpenSCAD renders a 3d image on every file save. You can even have OpenSCAD open and edit in a separate text editor and it still works. Is that not enough graphical feedback?
The mapping from geometry and back to definition (code) is pretty weak in tools like OpenSCAD/CadQuery, compared to a parametric solid modeler like FreeCAD/Fusion360.
It is a very indirect manipulation, and requires people to "play computer" (to paraphrase Brett Victor). Only programmers can do it efficiently.
> OpenSCAD isn't perfect, but it's so plainly obvious that code-based CAD is a better idea to me that it sort of bothers me that it's not the default.
Same reason people use Adobe Illustrator or Inkscape to create SVGs: when you're creating a visual end product it's often easier to use a visual workflow. You already have in your mind what you want it to look like, so you just need to draw it and you're done.
When it comes to specific dimensions it's often more convenient to use parametric modeling and integrated repeat features. Automate the repetitive and precise stuff, freeform draw the rest.
I really love the idea of openscad, but the execution is just not there, and I think it really does need the ability to explore the space via GUI and be able to snap to points/planes and have selection filters, etc. Think about the use case where you cut an object into two pieces, and then subsequently perform an extrusion off of a face of one of the pieces. With a purely code-based solution, you have to dig through the results to find the piece that you want to extrude, but with a GUI you can just point and click.
I think the holy grail would be a GUI-based CAD that stores your design history as a text-based editable script written in a very readable programming language.
I think with the growth of AI-assisted design, algorithmic engineering, and topology optimization, we will eventually get there. It practically requires it...you need to be able to specify the boundaries and constraints of what you need and let the system do its work, but you also need to be able to iterate off of the results and refine your boundaries and constraints to get to what you want.
> and I think it really does need the ability to explore the space via GUI and be able to snap to points/planes and have selection filters, etc.
I don't think the kernel OpenSCAD uses is capable of this; it's triangle mesh CSG so there's no representation of an edge or a face at all.
More to the point, it's all one way -- declaration to object -- and there is no reflection of the object back into the code.
CadQuery/Build123D can do this (Python), and I think the browser-based RepliCAD exposes faces and edges in its JS API. All of these use OpenCascade, one way or another, which is a proper (if flawed) bRep kernel.
Re: storing your design history as code -- it seems like FreeCAD could be moving back this way, in some small ways.
In 0.22-dev, if you copy a Sketcher sketch to the clipboard, what gets copied actually is the Python code to produce that sketch.
If you watch the Python console while you work in FreeCAD you will see it show you all the commands necessary to repeat what it is doing. Now, granted it's code more like a macro recorder would produce, but it's all you need. Even to the point of controlling the GUI (the commands for which get added to the console, commented out). In this aspect it's always been that way, which is its weirdo superpower.
Yeah, I was gonna add that FreeCAD probably has the best chance of becoming that sort of programming environment, and they've actually added a lot of great new features in the last year or so, including a reasonable solution to the topological naming problem [1]. Still a little clunky and has quite a few UI oddities, but overall it is taking shape a lot better than I ever expected. Really looking forward to their 1.0 release this year.
Yes -- the weekly releases have been really promising. The TNP mitigation is not yet bug-free but I think next week's weekly will have fixes for a few bits.
The most striking thing is that there's experimental support for multiple separate solids in Part Design. RealThunder's experimental version has had this for a good while but I wasn't expecting it to be user-facing in 1.0, because so much of his work has needed refactoring to fit.
OpenSCAD is great for things which one knows how to describe mathematically, but that puts a sharp bound on the possibilities for most folks.
My latest query in to the OpenSCAD mailing list is:
>How does one represent a 3 dimensional Bézier curve in OpenSCAD? How would that be extended so as to create an entire surface/object?
and my current project is wending its way down to doing wood joinery which seems to require conic sections (suggestions for texts to read for formulae which will calculate more quickly than the chained trigonometric calculations which only got me half-way or so?)
Tools like Fusion360 and FreeCAD have python scripting. You can definitely programmatically create entire models. But, because Fusion360 and FreeCAD are both parametric, you can also just define a number of parameters as global variables and then reference them in dimensions (with formulas). For KiCAD, I just export to STEP files (Fusion 360 has integrated physical and electrical design, but I found Fusion 360's electrical/PCB design to be worse than KiCAD).
I kind of fell out of love with openscad. I couldn’t find a workflow that didn’t involve tweaking x/y/z and width height etc parameters all the damn time. If anyone has any tips about workflow I’d love to hear them.
I found that I didn't really do that once I forced myself to avoid hard-coding numbers entirely. If I only defined variables, and defined variables in terms of other variables, I almost never had to do lots of x-y-z shifting.
Not sure what your workflow is or what you're building so of course what you're doing might be more complicated than what I did, or not lend itself to that, but I've managed to avoid headaches like that.
In theory you can do code-based CAD with FreeCAD, but it's going to be more verbose than OpenSCAD and I haven't come across anyone doing that in anger.
I feel like code/text first solutions make a ton of sense to programmers, after having learned how to program.
Once you wrap ur head around how to use text to describe behavior, it’s obviously the right way to do it.
I wonder what non programmers think about it though. It’s hard to see past the bias
It's definitely flatter. But I feel that the modelling techniques you need for successfully using these tools are no less rigorous than the design techniques you need to make 3D CAD work. They are just different.
I grappled with this idea of the stack/tree hiding complexity in FreeCAD but I've come to understand that once you get more confident thinking about design, it is more or less obvious where a given driving constraint should be derived from.
FreeCAD's expressions are no more complex than CadQuery paths, and they are certainly more expressive than OpenSCAD variables.
I would never diss the sheer coder-accessibility of OpenSCAD, which helped change my brain for the better, but GUI CAD models real-world thinking in often a very accessible way.
Just to play devil's advocate to my own point, there's really no reason you couldn't do source control for regular CAD programs is there? I know Git doesn't play super well with binaries from a space efficiency perspective, but it does work, and you could use something like Mercurial which does play ok with binaries I believe.
Mm. It strikes me that it might be more difficult to visualise changes.
e.g. in FreeCAD land:
FreeCAD uses a "zip-and-manifest" file format so there are ways to unpack that and manage it in git, but one of the challenges is getting useful human-readable diffs.
For those features which match up positionally with parameters --- often I have to brush up on my trigonometry to work out a calculation which will provide the position of features which do not.
Right -- my trig is weak. Joan Horvath's "Make: Trigonometry", which teaches with OpenSCAD, is on my reading list [0]
bRep environments liberate you from trig to some extent because you can build on arbitrary faces and edges, so you'd get some of those parametric, auto-updating benefits with Build123D or CadQuery.
FreeCAD's sketcher tool means I've only resorted to trig a few times.
What do you mean by a stack? Fusion360 for example doesn't use a stack, you can insert & delete operations in your history, not just push & pop off the end.
I certainly found code-CAD to be a useful bridge from abstract coder thinking to more concrete 3D thinking. It's liberating, and obviously it's potentially enormously valuable for parametric customisation.
But now I feel the sketch-and-constraints 3D CAD approach is more natural, even though I am still clumsy with 3D apps. It's also much, much faster once you know what tools are available to you.
So I find it difficult to believe that most non-coders would see code-CAD as superior.
It's at odds with the visualisations people use when working by hand with wood or metal, for example. It wasn't until I had to model a Leica M bayonet that I really grasped that CAD packages are to some extent built around analogues of real-world tools.
> OpenSCAD isn't perfect, but it's so plainly obvious that code-based CAD is a better idea to me that it sort of bothers me that it's not the default.
OpenSCAD was invaluable to me for getting started with CAD. I always considered myself somewhat "3D-impaired" when it came to software applications, but I wanted to make stuff, and OpenSCAD helped me get started and to explore some very basic concepts that gave me confidence (revolves, cuts etc.)
It gave me confidence I would be able to make my own things, however basic. But it is very simplistic and fundamentally limited.
For example, since it is not bRep, it cannot work with STEP, which limits its utility with existing components or exporting to manufacturing in other than 3D printing. And as it is declarative and lacks constraints or reflection capabilities you cannot measure models, loft generated faces, etc., and you end up doing endless, endless expression calculations to make parts that fit together, where parametrics and reflection would allow you to make one part based only on the final form measurements of another.
(If code-CAD appeals and Python is OK, look at Build123D as others have recommended. It is everything OpenSCAD should be, still lets you work with CSG operations, and can import your STLs. But it also gets you into a bRep world and that is, pun not intended, a step-change, as you can start to reason about and build on points and faces.)
So my next step was to look at CadQuery (which I don't recommend), and about three hours of that convinced me that I shouldn't get stuck in the mesh-modelling world. CadQuery led me to FreeCAD, and Mango Jelly Solutions videos and a free book got me started.
FreeCAD can work with OpenSCAD files (and it has a deprecated CadQuery 1.x workbench). It's also fundamentally parametric. You can write code to generate objects, or you can use expressions and spreadsheets with GUI tools; it's still wholly possible to make designs that are based on reasoning about measurements.
From there, I decided, if I hate FreeCAD at least I have liberated myself from the limitations and frustrations of OpenSCAD, and I can use other CAD packages as soon as I decide I have to. But I've never needed to.
I've been able to quickly make complex items, but also refine my designs to the point that they are more professional.
I would also caution you not to assume that it's "plainly obvious" code-CAD is better at all. It is great for simple objects and some programmatic generation, but relies on external files and tools for complex vector shapes, which is a usability/project management issue right from the start for a whole bunch of users. And then there's the frustrating handling of co-planar surfaces in the preview (though that may be mitigated? I gather there are speedups on the way too)
For the vast majority of users I would have thought it equally likely a constraints-and-sketches workflow is better, not least where implementing existing engineering sketches is concerned.
FWIW, those who've played with OpenSCAD and been annoyed at the holes in capability should take a look at CadQuery, which fills a very similar space but with a lot more expressivity:
* It's imperative python instead of a purely declarative custom language. Declarative DSLs are great when your problem is simple, but don't scale.
* The API design is sorta/kinda inspired by jQuery, operating on "selected sets" of subgeometry in a symmetric way, which recovers a lot of the "declarivity" for simple constructions.
* The underlying data model is a B-Rep thing built around OpenCascade. It has the same CSG primitives you're used to from OpenSCAD, but retains the ability to operate on faces and edges directly.
I'm no expert, but it's been a blast to play with. Definitely something to consider; OpenSCAD was sort of a mess back in the days of the RepRap Mendel, and frankly it hasn't improved much since.
> Declarative DSLs are great when your problem is simple, but don't scale.
Can you define "don't scale"? I keep hearing that but I feel like I've made relatively complex models with declarative DSLs and from a "writing code" perspective I do think they scale perfectly fine. I'll grant that performance gets a little bad, generally I end up having greatly reduce the face number when I'm working and bump it up when doing a final render.
Inevitably you want to do something that the declarators in your language don't support. Like, in this space you might have a parametrization function for a model (like... "swiss cheese" maybe) which needs to decide on a number of CSG child nodes ("holes") that is randomly generated. Your DSL (OpenSCAD) can't do that because it has a fixed graph. So now you need to write python to generate your DSL code in two separate layers. It would be simpler to have just started with python to begin with.
This pattern repeats again and again[1] every time someone tries to push a DSL for complicated problems. DSLs are a great way to address the boilerplate and copying and tedium of working with bad frameworks in imperative languages. But they don't work once you really get rolling, and you end up in some kind of imperative hell anyway.
Declarative programming as an API design style is hugely valuable and great. Declarative programming languages as an implementation choice are IMHO a bad smell.
[1] If you think about it, this is really just another corrolary of Greenspun's Tenth Rule.
Fair enough; it breaks some functional purity but in Bowler Studio you can have a mostly-scad-like DSL but you have access to the typical Clojure `rand` function. I'm pretty sure I could make that Swiss cheese pattern you described.
Meh. I mean, really both of these are semanticaly equivalent: they're python wrappers around a B-Rep toolkit (the same one, actually). On top of that they add, inevitably, a slightly opinionated API framework[1].
You don't like fluent APIs, which is your right. I think they have a place, and are a good DRY trick for grouping a bunch of things that would normally be "sequential" and making them look "declarative".
On the other hand I don't much like voodoo, and in my very limited experience with build123d it's sort of full of it. The very first "box" example looks like this:
with BuildPart() as ex1:
Box(length, width, thickness)
Why do we need a with expression here? What's the resource being allocated that must be freed? In particular why bother with "with" since the context appears to be implicit. The allocation gets bound to an "ex1" variable that is never used! How does Box() know where to put itself? It doesn't say, you just need to know what magic the toolkit is doing.
I mean, is that fatal? No. I'm sure it's reasonably easy to explain. But everyone has tastes, and mine (informed by decades of scars from APIs like this) run hard toward the "make things explicit" side of the theater.
[1] Because if they didn't they wouldn't have much value. There are OpenCascade python bindings already, after all. But they don't match the use case of "write a simple script to emit your object" and are more aimed at "build a CAD tool".
Build123D and CadQuery are actually compatible at the library level, I think? Certainly at the editor/viewer level.
In principle I think this means Build123D could even be given a FreeCAD workbench, but then there is no properly-supported CadQuery2 workbench at the moment (there's a fork that works but I don't think it has a real maintainer, and it's entirely possible that recent changes have broken it).
I definitely agree the implicit variable (in fact I don't think there is really an implicit variable, so much as dynamic scope detection, but we can imagine there is one) set up by the with statment is not particularly "Pythonic" but it is documented precisely here:
It's not ideal but it is still clearer than the CadQuery fluent API, which I don't really like, not because I think fluent APIs are bad at all (quite the opposite, actually) but because I don't believe the one in CadQuery makes a particularly good case for its existence (it's more the selector grammar I am unconvinced by).
Have you taken a look at the build123d "algebra API" yet? It is intended to be near zero magic without any of the with blocks from the "builder API". There are algebra and builder API versions of all of the introductory examples on this page https://build123d.readthedocs.io/en/latest/introductory_exam...
Since they're "just variables", not some funky CAD abstraction of variables (like you get with Fusion 360 I think?), you can do any level of arithmetic you want with them, and you can very easily define variables in terms of other variables and add conditionals.
Personally I absolutely hate measuring stuff, measuring stuff is my least favorite part of the entire 3d printing process. What I love about SCAD is I can just define my variables with dummy placeholder values, get a design that more or less looks right, and then measure everything right before I print, and everything will automatically readjust because it was all defined as variables.
This of course isn't specific just to OpenSCAD, but any code-based CAD program. I have no desire to try and go back to vanilla GUI programs.
Tbh, that workflow is also how you approach proper visual CAD programs. When I draw something in Solid Edge, I create sketches, extrude, etc until I've achieved roughly what I want, then I take measurements and set them as constraints in the model and it'll adapt accordingly.
And if I'm unsure about a measurement, I can just export a few models with slightly different values, 3D print all of them and try which works best.
Agreed, accounting for the complex imperfections in design specific plastic geometry can be hard to predict without successive approximation in parametric designs.
OpenSCAD does have some limitations, in that you will never really hit "perfect" tolerances in the output files either. However, the guess->print->measure->correct->repeat workflow is usually as good as it gets after a few cycles.
It can be more convenient than manually coding g-code macros, but OpenSCAD does certainly make 3D printing practical for actual parts.
Being able to utilize actual code to do anything allows you to use any kind of logic to create your models. I'm sure that someone could write something that would convert KiCAD stuff into a Fusion 360 model, but since SCAD is "just text", it is categorically easier to work with.
I was never able to really do anything productive with FreeCAD or CorelCAD, but I've been able to make tons of 3D prints from SCAD designs. The model just jives with my brain a bit better.
If anyone here likes SCAD, I highly recommend checking out Bowler Studio as well [1]. It's more robotics-focused than OpenSCAD, but free and open source, has its own "JavaCAD" DSL that lets you write in Java or Groovy or Clojure or Kotlin or Python to do CSG, and you can tack on a physics engine to test things out. The interface is still pretty clunky but it's definitely pretty cool software that I think is worth playing with.
[1] https://commonwealthrobotics.com/