I've made a bunch of stuff in OpenSCAD and it can be really nice to work with but... it does have a bunch of weirdnesses like not being to find the size of a compound object, having to micro-manage your objects to avoid the spinning beach ball render, fillets/chamfers/rounded edges/etc. are dark arts, etc.
If you're basically sticking simple shapes together or cutting simple shapes out of other shapes, it's fine enough.
I have an openscad-alike that supports fillets/chamfers, but unfortunately getting it to support importing any third party file formats (DXF, SVG, STL) is a bit beyond me right now.
I'd also love to find the time to rewrite the geometry kernel in something like taichi (python DSL running on GPU) or maybe JAX instead of numpy. And of course it doesn't yet pass most of openscad's test cases.
Don't miss the https://github.com/nophead/NopSCADlib library for OpenSCAD, which includes a tremendous amount of useful shapes, functions, and the ability to produce exploded diagrams, assembly instructions, etc.
There hasn't been a release in 3 years and no news updates in 2 years until the recent GSoC announcement. Modern linux distros are still shipping a version from 2021 on a older version of Qt, unless you get a nightly unofficial release from the snap store. That's not a great sign even if there are commits happening. I used OpenSCAD a lot in college and I really hope it has a future. I'm glad to see it's getting sponsors now.
I understand that but a project can still be active even if there are no releases. A lot of software doesn't even get published as packages in distros.
I ran into rendering limitations when modeling a multi cyclonic add on for my shop vac, and manifold saved this project. I used one of the nightly builds for this.
What are people's thoughts on CAD generation with LLMs for OpenSCAD and other proprietary GUI-based softwares? I imagine soon we will also be able to "autocomplete" or "semantically edit" feature trees in SolidWorks, Fusion, etc.
The problem with most CAD tools is they don't represent "design intent" or high-level components well, and I believe this is mostly due to the language's not being sophisticated enough
e.g. a human says "these holes need to be separated by 2mm", but when we program in OpenSCAD and other CAD languages we usually specify x={-1} for one component and x={1} for the other (just an example of how design intent is being lost)
When we can represent design intent well, we'll have something that LLMs can really grab hold of and build higher level components
> e.g. a human says "these holes need to be separated by 2mm", but when we program in OpenSCAD and other CAD languages we usually specify x={-1} for one component and x={1} for the other (just an example of how design intent is being lost)
What you mean there is constraints, I suppose?
And yes -- there's some work to add constraints to CadQuery sketches/cqparts, but it's early.
I suppose the logic has always been that if you control the placement of parts in code, you can build your own quasi-constraint logic to make reactive, parametric designs. And you might argue that "having complete control over this in code" is its own kind of "design intent" with its own potential justifications.
Specifying constraints in the way the CadQuery development does may not be natural.
But both CadQuery and Build123D have kernel-based tools like face finders, vertex finders etc., that are capable of things that OpenSCAD definitionally cannot do at kernel level.
Replicad (a JS OpenCascade environment) has face and vertex finders, face-based sketching, etc.
OpenSCAD has been great for simple projects. It’s very easy to get productive with if you know basic programming concepts. However, I’ve run into frustrating limitations on more complex projects. The core geometry engine is skittish.
I still use OpenSCAD, but I’m diving into the OCCT ecosystem. It has a steeper learning curve, but seems to be significantly more robust.
I think if you want to do complex things in OpenSCAD, you have to use someone's library or write your own.
For example, I wrote centering code that basically work for arbitrary length, which then become a frequently used part of the codebase. Then when I faced the limitation of the centering code, I wrote more code for arbitrary subdivision of elements.
I haven't extracted the new arbitrary subdivision of elements out into a module for my library, but I will eventually.
Yes, it’s a wonderful tool. This post kind of upset me; it’s comparing totally different classes of program.
SolidWorks is subscription based, so your $50 buys access this year and probably you won’t want to use the model again next year, right?
OpenSCAD is free software, and that matters.
Hopefully readers know it’s decades behind and very rough to use. Your example of “superpower modern CAD” could have been a whole lot simpler... probably some simple 2D geometric construction would be enough to show a big gap.
SolidWorks is locked to Windows - out in the real world that might be 95% of the users but here it’s probably 50%.
To finish my defense of OpenSCAD: there’s a place and an upside to all-text source and coding parameterized with traditional variables that you can change in your editor and recompile just like any other code. No GUI is only 80% bad.
There's a difference between noncommercial and barely commercial; if you model something on OpenSCAD and sell a single copy for $5, is that commercial? Lawyers say yes. But no amount of productivity from Solidworks will make spending $3000/year be worthwhile here.
Solidworks says noncommercial but then gives you $2000 leeway on commercial use before you need a commercial license. I’m not sure how they square that with later saying the watermarked files you’ve created don’t work in a commercial version.
And it leaves you with an awkward gap where you sell $2000 and need a commercial license, but even ignoring income tax you don’t have enough revenue to afford that license.
First of all, I'm sorry I upset you! That was definitely not intended.
I'm not comparing the two, I want to show what's possible. I often see people finding OpenSCAD, getting comfortable with it because it's all code, and stopping there. But there's so much more to solid body modelling, it's not too complicated to learn, and a bit more advanced CAD really expands the range of physical objects we can create! This is why I chose those slightly more complex examples, I'm not trying to gotcha OpenSCAD, I tried to show why one might want to branch out, despite all the downsides (subscription, non-code source files, Windows*, etc) you mentioned.
Fwiw I dream of a good open source CAD that syncs code and GUI (like KittyCAD) but doesn't fall into the trap of "procedural" modelling like OpenSCAD or KittyCAD. The combination of sketches+constraints+3D operations+projections is perfectly representable as code, it's just much more work than raw CSG, requires a geometric kernel, and is more mind bending. Still, I hope we will get one some day.
*: it does run perfectly well in Parallels though, so between Mac and native Windows I suspect it's more like 80% here
You had me tricked into thinking Solidworks was $50/year.
I was about to impulse purchase a license and switch over from Fusion. That would be an incredibly attractive hobby license and would probably take a lot of money from Autodesk.
Imagine being new to the CAD landscape. There are so many technologies, and approaches. Different resources talk about the merits of the individual techs.
I would rather someone just flat-out tell me that OpenSCAD etc is ineffective for most projects compared to SolidWorks, Fusion etc; save the trouble of finding out the hard way. Your points are all great, but I don't mind the post you're replying to for this reason.
I've never been comfortable drawing or drafting with GUIs. This is true for "drawing" graphics, laying out boards, or building 3D models for printing or CNC. OpenSCAD has been invaluable to me.
Usually, I'll hand draw what I need, then work out the equations, then build the models. No need to figure out what certain icons mean or to learn accelerator commands. I've built some fairly intricate designs with OpenSCAD. CSG is quite intuitive.
You might like the PCB constraint system we're building at tscircuit for laying out boards, the biggest issue with most systems imo is that you can't cleanly specify constraints. In tscircuit you can just use a <constraint /> component to lay out PCB elements
which finally made it possible for me to finally have the ability to write out G-code (allowing one to use OpenSCAD as a CAM tool) and DXFs (allowing one to have fully control and to create not-closed/unconnected geometry, and to write out arcs rather than only polylines):
For people interested in coding CAD in React, my team built a react fiber layer over jscad and are investing heavily into building an MIT-licensed 3d electronics library: https://github.com/tscircuit/jscad-fiber
I don't think you need a custom language to declare CAD, typescript/python have heavily invested in type systems so I hope the world moves more toward using existing languages.
The biggest limitation with code-CAD today is the lack of a constraint system (e.g. a clean way to say "these edges are 3mm apart") without X/Y coordinates everywhere. We're slowly building higher-level components that allow you to specify constraints so that you can write CAD in a way that more closely mimics the design intent, rather than a bunch of calculations.
OpenSCAD started it all so we're very grateful, but it's also time for some innovation to bring the language closer to design intent
I've been using jscad for years. Love it, still using it actively almost every day. I also use React/JSX every day for work and personal projects. That said, I'm not sure I like the mash-up of jscad-fiber after taking a look at the github page. Maybe it just doesn't fit my use-case of building several complex parts that have to interface with each other. I'm sure there is a use case for it though. It doesn't seem like jscad-fiber supports things like measureBoundingBox or any lower level stuff. There's a lot of depth to jscad, it's an amazing project.
A few years ago I worked with some fellow artist to design a rubiks cube around a large steel ball bearing using OpenSCAD. We machined the pieces out of aluminum (using a sweet 5-axis mill) and glued magnets into them. https://vimeo.com/322284709
As cool as OpenSCAD is, it's just one way of writing code to work with CAD.
The commercial CAD systems all have APIs to do the same kind of stuff, but they also have sophisticated UIs on top to make them easier to use visually. NX even lets the user record UI interactions as a function to make creating initial code faster.
In fact, there's a whole niche of CAD programming.
I made macros for Solidworks and Catia v5 during my Mechanical Engineering days and Visual Basic for applications + most Windows program is so powerful. But at the same time, VBA can be such a painful language because some language behavior is not typical.
I bought into Plasticity in the hope that it would gain such facilities, but the dev said that that sort of thing was being pushed off to v3.
Tried Dune3D and was moderately successful, but couldn't see where in the U.I. such numeric/programmatic access would be afforded and it doesn't seem to be on the roadmap there either.
I suppose I should break down and buy Rhino 3D and use Grasshopper, or Moment of Inspiration and use its Node Editor, but for now, I've been using:
> This is a sign that the software has grown to become its own operating system. They also have to add their own version control… remote editing, etc.
Not really, though most of the commercial CAD systems are comparable in size to an operating system already. NX just spits out the journal file, it's assumed the dev will take the code and modify it to their needs using their normal dev workflow and their own version control, IDE, etc..
The new Manifold library is blindingly fast for most things --- even things which bring the previous renderer to its knees complete in a reasonable timeframe for Preview(ing), though Render(ing) can require a measurably long wait.
i always thought I'd love openscad, being from a more coding background, but it turns out I'm not too fond of it. I eventually used freecad after watching some YouTube videos when I needed to make something.
For those who are interested. I have been working on a similar CAD Modeler. I think of it as a spiritual successor to OpenSCAD.
It has support for bidirectional modeling (ex: get the height and width of an object and use it later) and multi part workflows to design more complex works.
TBH I am not sure but I suspect the answer is yes. I use OpenCascade as the base CAD kernel and it handles things like Z-fighting a lot better. I built DSLCAD after completing porting OpenSCAD to wasm because I wanted a better programmatic CAD platform. It's development is really "as I need it" from then on.
> On the example above, the second cube sits exactly on top of the first cube. This is something that should be avoided as it’s not clear to OpenSCAD whether the two cubes form one object together. This issue can be easily solved by always maintaining a small overlap of about 0.001 - 0.002 between the corresponding objects.
This goes against the whole point of doing parametric design and should be logged as a bug. If the CAD software is unsure whether object spanning [0 to 1] and object spanning [1 to 2] are physically fused, that should be a bug. Mathematically they are fused.
I am referring to the specific case of the tutorial, where second box is exactly on top of first box. By design, there is no overlap and there is no gap, just a continuum of solid.
However, such continuum of solid can't be declared with exact coordinates in OpenSCAD, and instead one has to add intentional error to coordinates so that the solids overlap and the continuity is guaranteed.
It is a bug (well, a limitation), but AFAIR from my own designs, it generally only affects the low-precision, "fast" preview; in the final calculation it won't be an issue.
Nevertheless it is one of the things that is annoying as hell with the OpenSCAD previewer; constantly having to over-join to avoid it just makes the code more painful.
Coplanarity is generally a challenge in fast CAD previews.
OpenSCAD is amazing, especially for highly detailed geometry. Fusion360 was crashing when I modelled a honeycomb structure of ~2000 cells, while OpenSCAD easily handeled a similar model.
Nice! Great to see (Open)PythonSCAD listed! (I know this sort of thing is hard to keep up with --- I was trying for a long while on the old Shapeoko wiki (see link elsethread)).
(below has been edited to reflect my reading the entire page)
A tool which I didn't find and thought wasn't included is:
I don't say it's impossible but I believe it's quite near to impossible for most of OpenSCAD users to model this relatively simple drawing[1]. It's a breeze in CAD with constraint solver. Also it's viable in code-first systems with access to shape coordinates (build123d) using only construction geometry and projections. OpenSCAD requires hard trigonometry and math skills to pull it out.
OpenSCAD has amazing community though and part libraries celebrates human ingenuity despite tool restrictions.
This is good -- but they aren't quite the same? [0]
And the way they are not the same is (as the GP is saying) rather telling about the challenge of getting really precise things working in OpenSCAD without a pretty solid grasp of maths.
[0] they might be functionally equivalent in application, which is not nothing, of course
Couldn't let it go, but got everything except for the positioning of the small radius and maybe the height of the web slope is off (had to increase 2 to 2.05 to keep a gap from appearing).
I think if one laid out the radius stuff flat and then rotated it things would be easier to visualize.
This does not match the drawing. In addition it only took 4 minutes to do it correctly in a normal CAD package [1]. OpenSCAD is cool, but it's not at all a replacement for traditional 3D CAD and I wish people would try to sell it on its strengths instead of selling it as a replacement for traditional CAD.
OpenSCAD is really neat! It comes at the model representation process in a very different way.
In it's current form, it will never replace CAD as we know it today.
People have a hard enough time breaking an object they can see into features they can draw and combine, or modify as is done today. Add in the need to work with 2D drawings, sketches, photos, and it gets a bit harder for them still.
I have been training people to use CAD since the days of serious transition away from drafting boards. Very few of them would be able to author the descriptive text examples up thread.
And to be fair, parametric CAD, with or without history is powerful, but hard enough for plenty of people to really struggle, but that difficulty seems a couple orders below what we are discussing here.
Frankly, a better developed OpenSCAD could become a very powerful tool to be used in tandem with traditional CAD. It could even make use of the mature geometry kernels that way too. Those make more complex object and feature create actually work well because they have solutions for the almost innumerable corner and edge cases which always come up.
It is possible to create things largely OpenSCAD style in some CAD programs too. NX has a variety of programming interfaces, one being essentially Visual Basic with CAD appropriate functions.[2] (NX SNAP, as I recall)
You get entity create, query, rename, transform (full transform, scale, translate, rotate), modify like adding a fillet to an edge, boolean cut, join, intersect, split, add, partition... and a whole lot more! (It may not support partition, but it is supposed to for SDRC compatability, and that isn't the point anyway, so... yeah)
And there is the general purpose programming environment. Useful in all the obvious ways we here know well.
The main point is one can take an entirely analytical approach to model create, while also having the robust 3D and on NX 3D stereo[1] even, GUI to evaluate, debug, and all the other good CAD stuff!
To me, that is the OpenSCAD strength. The team can take a peek at the tools I just mentioned, add features and Open Cascade will do way more geometry cases than people think, and now you have model and entity create that can really work for some tough use cases:
--catalog parts with conditional features
--simulation and or analytically driven model shapes, many of which could be used as base features to be finished into manufacturable things
--coupled with an LLM trained on geometry, could result in Star Trek like plain language model create
There is more.
But the actual engineering, product design and manufacturing use cases are not going this way at all. It is too obtuse. People need to see, and I would argue benefit from haptics for interrogation, assembly and more.
Don't get me wrong here. All the open CAD tools are awesome. Open CAD is important and we just don't have much yet, and more is better. We do not have much yet because CAD is really hard, and the robust, mature geometry kernels out there have gazillions of man dev hours in them. Open Cascade is actually quite impressive to be for how well it really does work Given the tiny fraction of dev hours it has by comparison.
And what this means is CAD inertia is a problem likely an order harder than say the replace C code inertial some feel is worth doing.
Best bang for the dev hour investment us to augment and compliment traditional CAD, IMHO of course!
[1] All you need is a stereo capable GPU and display. I used my laptop with nVidia Quadro series and a fast Samsung 3D plasma TV for huge stereo modeling. Frankly, it was crazy good for evaluating technical surfaces and complex, think airplane internals, assembly was down right fun! Recommended and I am unsure why this is not more widely done.
[2] I used SNAP to convert bitmaps into voxel objects, where each voxel was a cube, and from those, combine them into larger voxel objects that were the basis for tooling models to make the desired shape. The retro pixel look you are picturing ...
I appreciate your attempt and time spent. It's an amazing showcase how simple things could be easily expressed in OpenSCAD. But the part in question sadly is not that simple. All tangents are wrong.
Erh? Are you complaining about some minor adjustment, so that lines are not meeting the curves smoothly? I did not even understand what TANGENT means, cause I know much nothing about CAD.
You absolutely don't need to get into the maths to get value from this idea. The maths terrifies me. Just know this core concept: a tangent line meets a circle only once and is at right angles to the radius when it does.
Here's why this is valuable in CAD environments that properly support it: once you know how a tangent line works, and see how a constraint-based modeller represents them, it is possible to understand how to model a whole set of smoothly rounded features that the CAD package can automatically adjust to changes made to core measurements, retaining this perfect "join". Rounded slots, curved rounded slots, fillets, all sorts of interesting motion components, etc.
Yes. Lines should touch circles in a smooth way. There could be many arguments why it's kinda important. Like fit to other parts in a final assembly or production complexity. But even for DIY purposes this minor adjustments would suck a lot of blood in prototype phase, it's a way more simpler to constraint it to be smooth (tangent) and forget about all tweaks needed after dimension changes.
I've overlaid your part on the correct part (as best I can when working with the mesh files that come out of OpenSCAD). Your part is drawn in red: https://i.imgur.com/12y5q1t.png
r1, r2 = 55/2, 30/2
cd = 125
# construct rib profile, start with slope and oversized arc
# reposition line to be constrained on arc center height and Y axis
l = build_line(O, op_line(-8, 30, name='l1'), op_arc(30, -90, name='a1'))
l.move(Vector(77-r1*2, 0) - l.a1.center_point)
ip, = intersections(l.l1, Axis.Y)
l.move(Y(50 - ip.Y))
# Now we know first arc center and could project it on a second arc center
# axis with known distance and get tangent point. Use point to trim oversized fist arc
# and create second tangent arc.
a2c = point_on_axis_with_dist(l.a1.center_point, Axis.X.offset((0, 66+32)), 66+30)
ip, = intersections(l.a1, axis_from_points(l.a1.center_point, a2c))
l.append(op_trim(ip), op_arc(to=(a2c.X, 32)), XA(cd-r1), YA(0), (l.s.X, 0)).close()
# Convex hull of base cylinders would have correct tangents
base_sk = make_hull((X(cd) * Circle(r2) + Circle(r1)).edges())
# Contruct final part
obj = extrude(X(r1) * RX(90) * l.face(), 11/2, both=True) + extrude(base_sk, 11)
obj += Cylinder(r1, 60, align=A.d)
obj += X(cd) * Cylinder(r2, 32, align=A.d)
obj -= Cylinder(35/2, 60, align=A.d)
obj -= X(cd) * Cylinder(20/2, 32, align=A.d)
It took 15 minutes and I used my helpers to aid rib profile construction. With stock build123d it's quite a chore.
This was my impression with build123d and Cadquery.
On paper they have a better abstraction than OpenScad. Yet, the code to express the same output is more bloated.
I was never able to get over the yak shaving learning curve to be proficient. Openscad mental model is a lot simpler to sustain momentum to go build something.
How did you get around to prefer Cadquery/build123d?
> Yet, the code to express the same output is more bloated.
But it's trivially ready to be parameterized and reused. Model is easy to change, you could think about relations between features not absolute entities.
It's my 3rd attempt to use code-CAD to be honest. OpenSCAD -> CadQuery -> Build123d. I have past experience with SolveSpace and OnShape. GUI CAD approach with drafting in 2D and making solids as late as possible works perfectly well and you could transfer spatial thinking as-is to model coding.
I have somewhat frustrating experience with OpenSCAD and CadQuery. OpenSCAD is perfect for simple things but gap to complex parameterized models was to big for me. CadQuery looks great in examples, but I could not grasp how to use it for my tasks. State tracking is crazy hard.
There are three major factors it clicked for me with build123d.
First is explicit algebra mode. My little coder brain could not comprehend large object trees from OpenSCAD or hardcore chain dance of cadquery. But I know what an object and mutability are. Build123d is amazingly intuitive and has tight primitive set large enough for complex things and small enough to be memorized by heart. Also Build123d has nice docstrings and type hints. I mainly use IDE help instead of online docs.
Second is a good interactive visualizer. I use yet-another-cad-viewer[1]. It allows to quickly debug issues and use my favorite editor. It's crucial to have visual representation and ability to know object bindings to variable name in source code. Killer features for me are on-hand access to per-object transparency setting and selection tool to measure distances between features. It really helps during learning.
Third is I actually sat down and spent around 10h with TTT practice models[2] :))
I believe I'm already effective with Build123d on the same level as with OnShape.
There is a major weak thing with code-CADs though. It's edge selection for fillets. I think about custom filters to narrow edge location. But now it's largely a guess work with edge visualization on fail.
Looking back at your build123d code, it looks like the biggest differentiator compare to OpenSCAD and CadQuery is the expressiveness to assign shapes to variables, right?
I was able to check that box with PythonSCAD thus far, so that's "solved" for me.
Otherwise, I see a lot of vector/coordinate manipulation that isn't too different from OpenSCAD/PythonSCAD.
However, I can see there's some additional abstraction primitives with arc and tangents that looks nice. That doesn't quite exist in any OpenSCAD based or similar engine since there's no built-in way to get info out of the shapes in a reflection-like way.
Maybe I will give Build123d another go and see if I can sustain some sort of momentum.
The best thing about the challenges from 3d CAD Speedmodelling is that they needed a quick way to validate submissions, so they do it by validating the mass of the design. The density to use is included in the problem. The answer is on this page: https://build123d.readthedocs.io/en/latest/tttt.html#t-24-cu...
Last January I offered a course on OpenSCAD in my university, perhaps the first one in Brazil or even in Portuguese. The lectures are available here (but it's in Portuguese, perhaps someday I'll translate it to English...): https://lucasoshiro.github.io/posts-en/2024-03-24-openscad/
OpenSCAD of course is not as powerful as other tools, but it has a lot of pros (depending on what you consider a pro):
- Free, unlike other tools such as Fusion or SolidWorks
- Open Source, unlike other tools such as Tinkercad or OnShape
- 100% based on a programming language: compared to others is like comparing plain HTML with HTML + JS
- Parameterizable (as a consequence of being based on a programming language), makes it a lot easier to adjust the model in a second iteration
- Lightweight (it runs ok in my 12 year old desktop)
- It can be used in CLI to generate STL files, makes it easier to automate the model generation
But of course it has a lot of cons:
- It isn't multithreaded, so, it doesn't matter if you have an 32-core CPU or a single core. It also doesn't matter if you have a GPU. So, there's no "best machine" for running it
- You can't compute the size of a shape, unless you know a formula for it. It's specially bad if you are dealing with texts, as you can't predict their shapes unless you're using a monospace font
- It has some bugs in visualization
- Even though it's on active development (you can see that in their Git), its latest release was in 2021
> But of course it has a lot of cons: - It isn't multithreaded, so, it doesn't matter if you have an 32-core CPU or a single core. It also doesn't matter if you have a GPU.
FWIW these don't have massive benefits for CAD modelling either. Most CAD kernels, even commercial ones, are sort of stubbornly single-threaded.
Sure, multi-threading can really help make the wider application feel more responsive, and a GPU is enormously useful for high-level photorealistic rendering as an end product. But it doesn't bring that much to bear on geometry solving, and the kind of 3D you need for CAD modelling and viewing is pretty old hat in OpenGL terms, I think?
- re-setting the text using METAPOST embedded in LuaLaTeX so as to write out an SVG
- reading the SVG back into OpenPythonSCAD
Bailed when it looked as if the latter step would require using Inkscape to convert to paths (at that point it seemed it would just make more sense to do it all in Inkscape)
Multi thread support is an experimental feature available on nightly build (and needing to be enabled). The bug tracking it is interesting to read, it has been a long journey... https://github.com/openscad/openscad/issues/391
99 comments
[ 3.5 ms ] story [ 167 ms ] threadIf you're basically sticking simple shapes together or cutting simple shapes out of other shapes, it's fine enough.
Being able to easily reference existing edges and faces for future operations is one of the things that make other CAD so simple.
https://github.com/traverseda/PySdfScad
I'd also love to find the time to rewrite the geometry kernel in something like taichi (python DSL running on GPU) or maybe JAX instead of numpy. And of course it doesn't yet pass most of openscad's test cases.
God, yes. Allegedly the BOSL library has some support for this kind of thing but I've not got around to trying it yet.
Great library, thanks for sharing!
https://github.com/BelfrySCAD/BOSL2
its under the "features" preference, doesn't work for everything yet, but is worth investigating if you haven't.
https://github.com/elalish/manifold
e.g. a human says "these holes need to be separated by 2mm", but when we program in OpenSCAD and other CAD languages we usually specify x={-1} for one component and x={1} for the other (just an example of how design intent is being lost)
When we can represent design intent well, we'll have something that LLMs can really grab hold of and build higher level components
What you mean there is constraints, I suppose?
And yes -- there's some work to add constraints to CadQuery sketches/cqparts, but it's early.
https://cadquery.readthedocs.io/en/latest/assy.html https://cadquery.readthedocs.io/en/latest/sketch.html#constr...
I suppose the logic has always been that if you control the placement of parts in code, you can build your own quasi-constraint logic to make reactive, parametric designs. And you might argue that "having complete control over this in code" is its own kind of "design intent" with its own potential justifications.
Specifying constraints in the way the CadQuery development does may not be natural.
But both CadQuery and Build123D have kernel-based tools like face finders, vertex finders etc., that are capable of things that OpenSCAD definitionally cannot do at kernel level.
Replicad (a JS OpenCascade environment) has face and vertex finders, face-based sketching, etc.
I still use OpenSCAD, but I’m diving into the OCCT ecosystem. It has a steeper learning curve, but seems to be significantly more robust.
https://dev.opencascade.org/
For example, I wrote centering code that basically work for arbitrary length, which then become a frequently used part of the codebase. Then when I faced the limitation of the centering code, I wrote more code for arbitrary subdivision of elements.
I haven't extracted the new arbitrary subdivision of elements out into a module for my library, but I will eventually.
A few examples of simple fillets in SOLIDWORKS: https://www.youtube.com/watch?v=f78gblpqxHc
Higher level continuity: https://www.youtube.com/watch?v=h5QN40d02cw
A good example of nontrivial surfacing: https://www.youtube.com/watch?v=cujS1icUTtg (the entire channel is a goldmine of surfacing tutorials)
Not every part needs G3 smooth curves, but being able use those tools when appropriate is a superpower.
SolidWorks is subscription based, so your $50 buys access this year and probably you won’t want to use the model again next year, right?
OpenSCAD is free software, and that matters.
Hopefully readers know it’s decades behind and very rough to use. Your example of “superpower modern CAD” could have been a whole lot simpler... probably some simple 2D geometric construction would be enough to show a big gap.
SolidWorks is locked to Windows - out in the real world that might be 95% of the users but here it’s probably 50%.
To finish my defense of OpenSCAD: there’s a place and an upside to all-text source and coding parameterized with traditional variables that you can change in your editor and recompile just like any other code. No GUI is only 80% bad.
And it leaves you with an awkward gap where you sell $2000 and need a commercial license, but even ignoring income tax you don’t have enough revenue to afford that license.
I'm not comparing the two, I want to show what's possible. I often see people finding OpenSCAD, getting comfortable with it because it's all code, and stopping there. But there's so much more to solid body modelling, it's not too complicated to learn, and a bit more advanced CAD really expands the range of physical objects we can create! This is why I chose those slightly more complex examples, I'm not trying to gotcha OpenSCAD, I tried to show why one might want to branch out, despite all the downsides (subscription, non-code source files, Windows*, etc) you mentioned.
Fwiw I dream of a good open source CAD that syncs code and GUI (like KittyCAD) but doesn't fall into the trap of "procedural" modelling like OpenSCAD or KittyCAD. The combination of sketches+constraints+3D operations+projections is perfectly representable as code, it's just much more work than raw CSG, requires a geometric kernel, and is more mind bending. Still, I hope we will get one some day.
*: it does run perfectly well in Parallels though, so between Mac and native Windows I suspect it's more like 80% here
I was about to impulse purchase a license and switch over from Fusion. That would be an incredibly attractive hobby license and would probably take a lot of money from Autodesk.
All I see is closer to $3000/year :(
I would rather someone just flat-out tell me that OpenSCAD etc is ineffective for most projects compared to SolidWorks, Fusion etc; save the trouble of finding out the hard way. Your points are all great, but I don't mind the post you're replying to for this reason.
Usually, I'll hand draw what I need, then work out the equations, then build the models. No need to figure out what certain icons mean or to learn accelerator commands. I've built some fairly intricate designs with OpenSCAD. CSG is quite intuitive.
https://github.com/tscircuit/cli/blob/main/example-project/s...
https://pythonscad.org/
which finally made it possible for me to finally have the ability to write out G-code (allowing one to use OpenSCAD as a CAM tool) and DXFs (allowing one to have fully control and to create not-closed/unconnected geometry, and to write out arcs rather than only polylines):
https://github.com/WillAdams/gcodepreview
For the current state see the latest preview of the current unit test:
https://forum.makerforums.info/uploads/default/original/3X/1...
I just hope we can get more folks using PythonOpenSCAD (or ideally, get it merged into the main branch).
Just finished up unit tests for the current state of gcodepreview:
https://raw.githubusercontent.com/WillAdams/gcodepreview/mai...
as part of my reading https://www.goodreads.com/book/show/39996759-a-philosophy-of... and applying what I learn from each chapter to it --- a bit more than a third of the way through, and it has already helped immeasurably.
I don't think you need a custom language to declare CAD, typescript/python have heavily invested in type systems so I hope the world moves more toward using existing languages.
The biggest limitation with code-CAD today is the lack of a constraint system (e.g. a clean way to say "these edges are 3mm apart") without X/Y coordinates everywhere. We're slowly building higher-level components that allow you to specify constraints so that you can write CAD in a way that more closely mimics the design intent, rather than a bunch of calculations.
OpenSCAD started it all so we're very grateful, but it's also time for some innovation to bring the language closer to design intent
Also written to be a follow along example to help understand how to think about writing OpenSCAD programs.
https://github.com/joewalnes/toybrick
The commercial CAD systems all have APIs to do the same kind of stuff, but they also have sophisticated UIs on top to make them easier to use visually. NX even lets the user record UI interactions as a function to make creating initial code faster.
In fact, there's a whole niche of CAD programming.
Tried Dune3D and was moderately successful, but couldn't see where in the U.I. such numeric/programmatic access would be afforded and it doesn't seem to be on the roadmap there either.
I suppose I should break down and buy Rhino 3D and use Grasshopper, or Moment of Inspiration and use its Node Editor, but for now, I've been using:
https://github.com/derkork/openscad-graph-editor
This is a sign that the software has grown to become its own operating system. They also have to add their own version control… remote editing, etc.
Unix style versions of tools are interesting in their own right (photoshop vs imagemagick).
Not really, though most of the commercial CAD systems are comparable in size to an operating system already. NX just spits out the journal file, it's assumed the dev will take the code and modify it to their needs using their normal dev workflow and their own version control, IDE, etc..
https://news.ycombinator.com/item?id=41545100
I didn't have problems, uh, thinking in parametrics, but lordy was the rendering slow. I might try it again.
It has support for bidirectional modeling (ex: get the height and width of an object and use it later) and multi part workflows to design more complex works.
https://www.dslcad.com/
> On the example above, the second cube sits exactly on top of the first cube. This is something that should be avoided as it’s not clear to OpenSCAD whether the two cubes form one object together. This issue can be easily solved by always maintaining a small overlap of about 0.001 - 0.002 between the corresponding objects.
This goes against the whole point of doing parametric design and should be logged as a bug. If the CAD software is unsure whether object spanning [0 to 1] and object spanning [1 to 2] are physically fused, that should be a bug. Mathematically they are fused.
I am referring to the specific case of the tutorial, where second box is exactly on top of first box. By design, there is no overlap and there is no gap, just a continuum of solid.
However, such continuum of solid can't be declared with exact coordinates in OpenSCAD, and instead one has to add intentional error to coordinates so that the solids overlap and the continuity is guaranteed.
It is a bug (well, a limitation), but AFAIR from my own designs, it generally only affects the low-precision, "fast" preview; in the final calculation it won't be an issue.
Nevertheless it is one of the things that is annoying as hell with the OpenSCAD previewer; constantly having to over-join to avoid it just makes the code more painful.
Coplanarity is generally a challenge in fast CAD previews.
(below has been edited to reflect my reading the entire page)
A tool which I didn't find and thought wasn't included is:
https://github.com/derkork/openscad-graph-editor
(which I was expecting would fall under "GUI", but is instead near the end under "Wrappers")
OpenSCAD has amazing community though and part libraries celebrates human ingenuity despite tool restrictions.
[1]: https://build123d.readthedocs.io/en/latest/_images/ttt-23-t-...
And the way they are not the same is (as the GP is saying) rather telling about the challenge of getting really precise things working in OpenSCAD without a pretty solid grasp of maths.
[0] they might be functionally equivalent in application, which is not nothing, of course
https://www.blockscad3d.com/community/projects/1814083
Trying to work out the triangles/chords to get the radiuses positioned --- a workable approach should be to:
- use a triangle to determine the position of the 8 degree rotation and position elements which define the top of the web offset by that distance
- use a chord/triangle to determine the position of the circle for the smaller radius
- chain another calculation from that to determine the position of the circle for the larger radius
- chain one final calculation to get the flat element which makes the end of the web co-planar with the flat top of the small cylinder
I need to go work in the yard for a bit, but I'll keep thinking this through and hopefully will finish it up this evening.
I think if one laid out the radius stuff flat and then rotated it things would be easier to visualize.
[1]: https://youtu.be/aL5KLXNV-FI
In it's current form, it will never replace CAD as we know it today.
People have a hard enough time breaking an object they can see into features they can draw and combine, or modify as is done today. Add in the need to work with 2D drawings, sketches, photos, and it gets a bit harder for them still.
I have been training people to use CAD since the days of serious transition away from drafting boards. Very few of them would be able to author the descriptive text examples up thread.
And to be fair, parametric CAD, with or without history is powerful, but hard enough for plenty of people to really struggle, but that difficulty seems a couple orders below what we are discussing here.
Frankly, a better developed OpenSCAD could become a very powerful tool to be used in tandem with traditional CAD. It could even make use of the mature geometry kernels that way too. Those make more complex object and feature create actually work well because they have solutions for the almost innumerable corner and edge cases which always come up.
It is possible to create things largely OpenSCAD style in some CAD programs too. NX has a variety of programming interfaces, one being essentially Visual Basic with CAD appropriate functions.[2] (NX SNAP, as I recall)
You get entity create, query, rename, transform (full transform, scale, translate, rotate), modify like adding a fillet to an edge, boolean cut, join, intersect, split, add, partition... and a whole lot more! (It may not support partition, but it is supposed to for SDRC compatability, and that isn't the point anyway, so... yeah)
And there is the general purpose programming environment. Useful in all the obvious ways we here know well.
The main point is one can take an entirely analytical approach to model create, while also having the robust 3D and on NX 3D stereo[1] even, GUI to evaluate, debug, and all the other good CAD stuff!
To me, that is the OpenSCAD strength. The team can take a peek at the tools I just mentioned, add features and Open Cascade will do way more geometry cases than people think, and now you have model and entity create that can really work for some tough use cases:
--catalog parts with conditional features
--simulation and or analytically driven model shapes, many of which could be used as base features to be finished into manufacturable things
--coupled with an LLM trained on geometry, could result in Star Trek like plain language model create
There is more.
But the actual engineering, product design and manufacturing use cases are not going this way at all. It is too obtuse. People need to see, and I would argue benefit from haptics for interrogation, assembly and more.
Don't get me wrong here. All the open CAD tools are awesome. Open CAD is important and we just don't have much yet, and more is better. We do not have much yet because CAD is really hard, and the robust, mature geometry kernels out there have gazillions of man dev hours in them. Open Cascade is actually quite impressive to be for how well it really does work Given the tiny fraction of dev hours it has by comparison.
And what this means is CAD inertia is a problem likely an order harder than say the replace C code inertial some feel is worth doing.
Best bang for the dev hour investment us to augment and compliment traditional CAD, IMHO of course!
[1] All you need is a stereo capable GPU and display. I used my laptop with nVidia Quadro series and a fast Samsung 3D plasma TV for huge stereo modeling. Frankly, it was crazy good for evaluating technical surfaces and complex, think airplane internals, assembly was down right fun! Recommended and I am unsure why this is not more widely done.
[2] I used SNAP to convert bitmaps into voxel objects, where each voxel was a cube, and from those, combine them into larger voxel objects that were the basis for tooling models to make the desired shape. The retro pixel look you are picturing ...
The balance is a bit more involved --- I'll see if I can find time to model this in a couple of ways....
You are right on a precipice between what you know, and falling into a deep, deep trough of CAD knowledge!
https://en.wikipedia.org/wiki/Tangent_lines_to_circles
You absolutely don't need to get into the maths to get value from this idea. The maths terrifies me. Just know this core concept: a tangent line meets a circle only once and is at right angles to the radius when it does.
Here's why this is valuable in CAD environments that properly support it: once you know how a tangent line works, and see how a constraint-based modeller represents them, it is possible to understand how to model a whole set of smoothly rounded features that the CAD package can automatically adjust to changes made to core measurements, retaining this perfect "join". Rounded slots, curved rounded slots, fillets, all sorts of interesting motion components, etc.
On paper they have a better abstraction than OpenScad. Yet, the code to express the same output is more bloated.
I was never able to get over the yak shaving learning curve to be proficient. Openscad mental model is a lot simpler to sustain momentum to go build something.
How did you get around to prefer Cadquery/build123d?
But it's trivially ready to be parameterized and reused. Model is easy to change, you could think about relations between features not absolute entities.
It's my 3rd attempt to use code-CAD to be honest. OpenSCAD -> CadQuery -> Build123d. I have past experience with SolveSpace and OnShape. GUI CAD approach with drafting in 2D and making solids as late as possible works perfectly well and you could transfer spatial thinking as-is to model coding.
I have somewhat frustrating experience with OpenSCAD and CadQuery. OpenSCAD is perfect for simple things but gap to complex parameterized models was to big for me. CadQuery looks great in examples, but I could not grasp how to use it for my tasks. State tracking is crazy hard.
There are three major factors it clicked for me with build123d.
First is explicit algebra mode. My little coder brain could not comprehend large object trees from OpenSCAD or hardcore chain dance of cadquery. But I know what an object and mutability are. Build123d is amazingly intuitive and has tight primitive set large enough for complex things and small enough to be memorized by heart. Also Build123d has nice docstrings and type hints. I mainly use IDE help instead of online docs.
Second is a good interactive visualizer. I use yet-another-cad-viewer[1]. It allows to quickly debug issues and use my favorite editor. It's crucial to have visual representation and ability to know object bindings to variable name in source code. Killer features for me are on-hand access to per-object transparency setting and selection tool to measure distances between features. It really helps during learning.
Third is I actually sat down and spent around 10h with TTT practice models[2] :))
I believe I'm already effective with Build123d on the same level as with OnShape.
There is a major weak thing with code-CADs though. It's edge selection for fillets. I think about custom filters to narrow edge location. But now it's largely a guess work with edge visualization on fail.
[1]: https://github.com/yeicor-3d/yet-another-cad-viewer [2]: https://www.tootalltoby.com/practice/
I was able to check that box with PythonSCAD thus far, so that's "solved" for me.
Otherwise, I see a lot of vector/coordinate manipulation that isn't too different from OpenSCAD/PythonSCAD.
However, I can see there's some additional abstraction primitives with arc and tangents that looks nice. That doesn't quite exist in any OpenSCAD based or similar engine since there's no built-in way to get info out of the shapes in a reflection-like way.
Maybe I will give Build123d another go and see if I can sustain some sort of momentum.
https://www.blockscad3d.com/community/projects/1814083
which is mostly parametric --- only the placement of the rounding of the last radius is hard-coded/fudged.
Last January I offered a course on OpenSCAD in my university, perhaps the first one in Brazil or even in Portuguese. The lectures are available here (but it's in Portuguese, perhaps someday I'll translate it to English...): https://lucasoshiro.github.io/posts-en/2024-03-24-openscad/
- Free, unlike other tools such as Fusion or SolidWorks - Open Source, unlike other tools such as Tinkercad or OnShape - 100% based on a programming language: compared to others is like comparing plain HTML with HTML + JS - Parameterizable (as a consequence of being based on a programming language), makes it a lot easier to adjust the model in a second iteration - Lightweight (it runs ok in my 12 year old desktop) - It can be used in CLI to generate STL files, makes it easier to automate the model generation
But of course it has a lot of cons: - It isn't multithreaded, so, it doesn't matter if you have an 32-core CPU or a single core. It also doesn't matter if you have a GPU. So, there's no "best machine" for running it - You can't compute the size of a shape, unless you know a formula for it. It's specially bad if you are dealing with texts, as you can't predict their shapes unless you're using a monospace font - It has some bugs in visualization - Even though it's on active development (you can see that in their Git), its latest release was in 2021
FWIW these don't have massive benefits for CAD modelling either. Most CAD kernels, even commercial ones, are sort of stubbornly single-threaded.
Sure, multi-threading can really help make the wider application feel more responsive, and a GPU is enormously useful for high-level photorealistic rendering as an end product. But it doesn't bring that much to bear on geometry solving, and the kind of 3D you need for CAD modelling and viewing is pretty old hat in OpenGL terms, I think?
- writing out a text from OpenPythonSCAD
- reading it into LaTeX to measure it[1]
- re-setting the text using METAPOST embedded in LuaLaTeX so as to write out an SVG
- reading the SVG back into OpenPythonSCAD
Bailed when it looked as if the latter step would require using Inkscape to convert to paths (at that point it seemed it would just make more sense to do it all in Inkscape)
1 - https://graphicdesign.stackexchange.com/questions/31088/any-...