I tried this a couple of months ago, I found what it's trying to do very pleasant to use but the tooling around it is very annoying. The up-to-date version 2 isn't on pypi, conda is thoroughly unpleasant to have as an environment. There seems to be a drive to using it inside it's own editor https://github.com/CadQuery/CQ-editor while nice seems like wasted engineering effort in developing an editor when the language needs so much work. I didn't have much success structuring cad into modules as they wouldn't import well.
The point IMO of parametric cad in an existing language is to use the ecosystem. Lots of choices in this project make that really hard.
Fully agree that the tooling and setup are not ideal. In case this may help others, I've been using Jupyter-CadQuery [0], an extension for JupyterLab to view your models in a side panel within the Jupyter notebook web interface.
There's a docker image that packages the whole thing (CadQuery + JupyterLab + the extension) in the docker folder, making it easy to run and to update. The image is also available from docker hub [1].
On a more general note, I've mostly been using CadQuery to model pieces for 3d printing and the experience has been quite fun. Errors are not always easy to figure out and there's a learning curve to consider, but being able to "simply" describe my model in code instead of relying lots of [point|drag|click] is totally worth it. It was also a nice way to refresh my geometry knowledge.
Yeah, I think their approach to blaming PyPi for not being able to distribute their 1GB standard install is really putting the blame on the wrong people.
I actually found it fairly intuitive to use for an admittedly simple use-case, but I agree with you on CQ-editor being sub-optimal. The docs could have provided an example of displaying / saving assemblies to popular image formats
I made this keyboard case with CadQuery. In the long run I'm working towards generating cases (and PCBs) for keyboards with many parameters available for configuration (e.g. number of columns, number of rows, number and position of thumb keys, case style, rotary encoders, etc).
Ergogen is a project in a similar spirit; it takes a YAML as an input and uses this to generate files for plates, or (unrouted) Kicad PCBs.
I was also interested in having parametric CAD related to custom keyboard PCBs. The approach I took was to copy the PCB module data to a format the CAD program could use. That way, the Kicad PCB files would still be the "source of truth" for the PCB design, but I could use OpenScad to come up with the plates for the case. https://github.com/rgoulter/keyboard-labs/
Slight aside, does anyone know of a more modern open source parametric CAD kernel than OpenCascade (which this is built on)?
When I have looked into it before it seems to be criticised for being somewhat dated and not have the power and developer ease as Parasolid (which costs big bucks). Having both a software and mechanical engineering background (I spent a lot of time in SolidWorks) I regularly get the itch to try and combine the two and create a CAD tool.
I've never tried BRL-CAD but it looks really big and complex. The only other one I'm aware of is Solvespace:
https://solvespace.com/index.pl
It uses it's own B-Rep for NURBS and can export STEP files. The basics are there for extrudes, revolves and helixes. Booleans are still a bit buggy, but we occasionally fix a bug or two.
It's definitely the smallest NURBS kernel around at about 8000 LoC and the full program comming in at ~5MB. There is no real API for geometry though, just the constraint solver.
"[there are] ASIC and Parasolid, others are not really as good"
and "[CAD] Research disconnected from reality [compared to CG research]"
One might expect a whole range of CAD kernels floating around, since these kernels are such a fundamental part of civilization in some way. Doesn't seem to be the case, tho..
I started parametric geometry or CAD with AutoLISP, but you were tied to AutoCAD.
Then I found Blender in the late 90's and early 2000's, and used Python to do some cool stuff. FreeCAD was my next attempt at using the engine without the GUI, but most of my daytime work in engineering is on Autodesk Fusion or Inventor, or in Rhino. Then I found Rosetta[1], a cool attempt at creating a geometry grammar and a backend for popular CAD programs like AutoCAD or Rhino. You code in Rosetta, a Racket DSL/library, and it renders in the CAD backend. I actually used it to generate a spherical truss dome that I could analyze structurally, change parameters, and reload in the analysis. I was almost at the point of doing my own version of generative design assist that Autodesk now has working. I started to think about writing a backend for FreeCAD, because I prefer Lisps over python for creative coding. I'll have to check CadQuery out now that it has moved from FreeCAD to OCCT. I still like writing AutoLISP for fun. Still not a fan of python for no good reason other than the biased reason that Lisp makes me happy, and python doesn't. CadQuery's Jupyter interface seems like a good sandbox to experiment with if the speed is good for iterative or historical design.
One thing that kept me using OpenSCAD was the section of additional modules for it, including a decent involute gear creator. For those of you diving into CadQuery, here’s the equivalent: https://github.com/meadiode/cq_gears
This is absolutely an impressive toolset, because it provides a bridge between the CSG => STL world (OpenSCAD, boolean operations, cutting shapes out of other shapes) and the STEP world of GUI CAD (faces, fillets, chamfers).
I struggle with GUI CAD and I'm still learning all of this stuff at the most noddy level, but I am very conscious that I will want to send stuff out to be manufactured one day, and that means I have to be able to get beyond STL to STEP. So I am going to be spending more time with CADQuery and trying to use what it helps me visualise in FreeCAD as well.
There is now a FreeCad workbench for CadQuery 2.0 which I have not yet tried:
When I read parametric CAD I was hoping to see a tool that can automatically assemble full floor plans from just XYZ dimensions. Wiring, plumbing, structure, lighting, insulation, etc. Everything maybe except paint color. It's just another constraint solver, not sure why that doesn't exist yet and why we need to cough up billions in engineering and architecture costs every year.
With a tool that can provide normalized, structured data corresponding to buildings, then for sure we could save on manufacturing too, every wall panel +- the same you could mass produce them. With a clever concept with datacenter-like floating floor you could even change and adapt the rooms (including plumbing) to suit needs without having to rebuild.
The "design space" of architectural CAD models is mostly illegal (e.g. does your AI know how many parking spaces you must provide?) and/or lethally dangerous (e.g. is that beam strong enough?) so in the real world a constraint solver that saves time by automatically drafting, according to detailed specifications, detailed plans that certified architects and engineers can then analyze and sign off is the most useful possible tool.
For anyone interested in this, I would also recommend checking out the [antimony project](https://github.com/mkeeter/antimony). It's a parametric modeling program, but you can also pretty easily produce new scripts for its visual nodes.
Cut and paste of a recent comment I made in a similar thread:
I've started to switch to Cadquery from OpenSCAD because OpenSCAD lacks proper fillets and chamfers.
I usually prefer the CSG (arithmetic tree of union/difference/intersection + transforms + base shape leaves) to model 3D objects, as opposed to Cadquery's "draw on 2D surfaces and extrude" approach, but OpenSCAD's lack of fillets / chamfers combined with the "everything is a polygonal mesh" approach of the rendering engine is just too limiting.
Cadquery has a lot of potential (the underlying engine uses a traditional hierarchical NURBS BREP, IIUC), but it also has a lot of shortcomings:
Here are some I've bumped into:
. very strange "stack-based" model. For complex objects, it's hard to wrap your head around it, and the workflow it forces on you as a user does not always fit your mental model of the object.
. the underlying hierarchical nature of the object (the BREP) is forcibly hidden from the user, which leads to kafka-esque situations when one wants to e.g. select parts of an object.
. selecting parts (faces and edges) in a object is a nightmare. cadquery has "selectors", which are a) its own weird little DSL b) very difficult to use on complex shapes c) does not support name-based retrieval: can't label things and get to them later by name.
- the UI (cq-editor) is unusable for real-world work: no perspective rendering, no graduations in ortho views, no way to measure things on the object, no way to examine the BREP, etc ... Generally speaking, the UI is only a visualizer, and does not let you query / inspect the model in any detailed way.
- fine-grain control over tessellation (conversion to mesh) is lacking.
- good for modeling mechanical parts / lousy for modeling anything organic-looking
- importing external models that don't fit the cadquery BREP-based represention is basically impossible.
TL;DR: a nice tool to add to your belt, but not a very mature environment yet, and certainly can't replace OpenSCAD yet.
> - good for modeling mechanical parts / lousy for modeling anything organic-looking
SDF modeling is great for organic shapes.
On the surface, it feels similar to OpenSCAD since CSG operations are natural primitives (min/max/...). Fillets / chamfers are easier to produce, compared to OpenSCAD: http://mercury.sexy/hg_sdf/#snippet
Libfive is one implementation geared towards CAD work. One issue with SDFs for CAD is that it can be difficult to work on complex models. The representation is not minimal: two SDFs can represent the same volume, but act differently when you combine them with other bodies.
Libfive's "stdlib" is quite minimal. For anything fancy, you have to build your own "DOM" on top of it, in order to organize your parametric models. I have not enough experience for that, but I think that it should be possible to build a DSL that render to an SDF expression, while supporting introspection, constraint solving, AD for gradients, etc, with goals similar to CadQuery (I don't like the stack API either). This might also help with the normalization issue above.
> c) does not support name-based retrieval: can't label things and get to them later by name.
I think I saw somewhere in the docs that you can tag items and reference them in the selector DSL. Maybe this is possible now? I haven't tried it though.
One other small gripe about CadQuery that I'd add is that its error messages (via its CAD kernel) are typically very opaque.
AFAIK there isn't really another reasonable way of rendering other than having render meshes attached to everything (due to GPU architecture), but they shouldn't be getting used for any calculations so it also shouldn't matter very much.
[+] [-] Already__Taken|4 years ago|reply
The point IMO of parametric cad in an existing language is to use the ecosystem. Lots of choices in this project make that really hard.
[+] [-] ireneu|4 years ago|reply
On a more general note, I've mostly been using CadQuery to model pieces for 3d printing and the experience has been quite fun. Errors are not always easy to figure out and there's a learning curve to consider, but being able to "simply" describe my model in code instead of relying lots of [point|drag|click] is totally worth it. It was also a nice way to refresh my geometry knowledge.
[0] https://github.com/bernhard-42/jupyter-cadquery [1] https://hub.docker.com/r/bwalter42/jupyter_cadquery
[+] [-] bb88|4 years ago|reply
https://github.com/CadQuery/cadquery/issues/153#issuecomment...
As an example of an approach that doesn't break Pypi, nltk distributes through Pypi but has an download() method for installation.
https://pypi.org/project/nltk/ https://www.nltk.org/data.html
The fact they're hostile towards pip (and ergo pipenv and poetry) just make it less than appealing software to want to use.
[+] [-] jkic47|4 years ago|reply
[+] [-] ur-whale|4 years ago|reply
Understatement, if there ever was one.
Installing conda will maim your system irrevocably.
[+] [-] mikebannister|4 years ago|reply
https://imgur.com/a/VfOyAjP
https://github.com/possibilities/unkeyboard
Note I chose a somewhat non-idiomatic approach (in terms of cadquery) writing this and I'm new to python.
[+] [-] rgoulter|4 years ago|reply
I was also interested in having parametric CAD related to custom keyboard PCBs. The approach I took was to copy the PCB module data to a format the CAD program could use. That way, the Kicad PCB files would still be the "source of truth" for the PCB design, but I could use OpenScad to come up with the plates for the case. https://github.com/rgoulter/keyboard-labs/
[+] [-] _benj|4 years ago|reply
[+] [-] samwillis|4 years ago|reply
When I have looked into it before it seems to be criticised for being somewhat dated and not have the power and developer ease as Parasolid (which costs big bucks). Having both a software and mechanical engineering background (I spent a lot of time in SolidWorks) I regularly get the itch to try and combine the two and create a CAD tool.
[+] [-] phkahler|4 years ago|reply
It uses it's own B-Rep for NURBS and can export STEP files. The basics are there for extrudes, revolves and helixes. Booleans are still a bit buggy, but we occasionally fix a bug or two.
It's definitely the smallest NURBS kernel around at about 8000 LoC and the full program comming in at ~5MB. There is no real API for geometry though, just the constraint solver.
BTW the constraint solver has also been used in one of the FreeCAD assembly workbenches, and also in this sketcher add-on for blender: https://blenderartists.org/t/geometry-sketcher-constraint-so...
[+] [-] rjsw|4 years ago|reply
[+] [-] ramboldio|4 years ago|reply
Here are two quite remarkable statements from a MIT lecture on CAD (https://stellar.mit.edu/S/course/6/fa19/6.807/courseMaterial... ):
"[there are] ASIC and Parasolid, others are not really as good"
and "[CAD] Research disconnected from reality [compared to CG research]"
One might expect a whole range of CAD kernels floating around, since these kernels are such a fundamental part of civilization in some way. Doesn't seem to be the case, tho..
[+] [-] eggy|4 years ago|reply
[1] http://web.ist.utl.pt/antonio.menezes.leitao/Rosetta/index.h...
[+] [-] jker|4 years ago|reply
[+] [-] unfocussed_mike|4 years ago|reply
I struggle with GUI CAD and I'm still learning all of this stuff at the most noddy level, but I am very conscious that I will want to send stuff out to be manufactured one day, and that means I have to be able to get beyond STL to STEP. So I am going to be spending more time with CADQuery and trying to use what it helps me visualise in FreeCAD as well.
There is now a FreeCad workbench for CadQuery 2.0 which I have not yet tried:
https://github.com/jpmlt/freecad-cadquery2-workbench
[+] [-] gxt|4 years ago|reply
With a tool that can provide normalized, structured data corresponding to buildings, then for sure we could save on manufacturing too, every wall panel +- the same you could mass produce them. With a clever concept with datacenter-like floating floor you could even change and adapt the rooms (including plumbing) to suit needs without having to rebuild.
[+] [-] HelloNurse|4 years ago|reply
[+] [-] l00sed|4 years ago|reply
[+] [-] traverseda|4 years ago|reply
[+] [-] rajnathani|4 years ago|reply
[+] [-] ur-whale|4 years ago|reply
I've started to switch to Cadquery from OpenSCAD because OpenSCAD lacks proper fillets and chamfers.
I usually prefer the CSG (arithmetic tree of union/difference/intersection + transforms + base shape leaves) to model 3D objects, as opposed to Cadquery's "draw on 2D surfaces and extrude" approach, but OpenSCAD's lack of fillets / chamfers combined with the "everything is a polygonal mesh" approach of the rendering engine is just too limiting.
Cadquery has a lot of potential (the underlying engine uses a traditional hierarchical NURBS BREP, IIUC), but it also has a lot of shortcomings:
Here are some I've bumped into:
See this github issue for example: https://github.com/dcowden/cadquery/issues/29 TL;DR: a nice tool to add to your belt, but not a very mature environment yet, and certainly can't replace OpenSCAD yet.[+] [-] Piezoid|4 years ago|reply
SDF modeling is great for organic shapes.
On the surface, it feels similar to OpenSCAD since CSG operations are natural primitives (min/max/...). Fillets / chamfers are easier to produce, compared to OpenSCAD: http://mercury.sexy/hg_sdf/#snippet
Libfive is one implementation geared towards CAD work. One issue with SDFs for CAD is that it can be difficult to work on complex models. The representation is not minimal: two SDFs can represent the same volume, but act differently when you combine them with other bodies.
Libfive's "stdlib" is quite minimal. For anything fancy, you have to build your own "DOM" on top of it, in order to organize your parametric models. I have not enough experience for that, but I think that it should be possible to build a DSL that render to an SDF expression, while supporting introspection, constraint solving, AD for gradients, etc, with goals similar to CadQuery (I don't like the stack API either). This might also help with the normalization issue above.
[+] [-] ssl232|4 years ago|reply
I think I saw somewhere in the docs that you can tag items and reference them in the selector DSL. Maybe this is possible now? I haven't tried it though.
One other small gripe about CadQuery that I'd add is that its error messages (via its CAD kernel) are typically very opaque.
[+] [-] defterGoose|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]