Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CadQuery –- A Python parametric CAD scripting framework based on OCCT

github.com

Post reply on HN
Print view View original

21–30 of 45 posts

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#21

Post by samwillis »

phkahler wrote: post #19
samwillis wrote: post #2

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…

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 comm…

That blender add on looks awesome! Thanks, I hadn’t see that.

Watching Solvespace with great interest, who hung it could one day become a full brown kernel.

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#22

Post by samwillis »

ramboldio wrote: post #18
samwillis wrote: post #2

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…

same itch here. 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 s…

That confirms the impression I had, I guess they are just so complex that building a new open source one from scratch would be Herculean effort. Guess OCCT is the only option for now.

The itch I would love to scratch is an online real-time collaborative parametric cad app using CRDTs. Current thinking is combining OpenCascade compiled to WASM [0] with Yjs[1], but frankly don’t have the time.

A kind of Figma but for 3D cad. (There is obviously onShape but I’m thinking something a little simpler)

0: https://github.com/donalffons/opencascade.js/

1: https://github.com/yjs/yjs

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#23

Post by ireneu »

Already__Taken wrote: post #7

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…

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.

[0] https://github.com/bernhard-42/jupyter-cadquery [1] https://hub.docker.com/r/bwalter42/jupyter_cadquery

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#24

Post by ur-whale »

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.
See this github issue for example: https://github.com/dcowden/cadquery/issues/29

     - 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.

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#25

Post by defterGoose »

ur-whale wrote: post #24

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 th…

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.

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#26

Post by julbaxter »

ramboldio wrote: post #18
samwillis wrote: post #2

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…

same itch here. 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 s…

What about CGM?

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#27

Post by Piezoid »

ur-whale wrote: post #24

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 th…

> - 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.

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#28

Post by ssl232 »

ur-whale wrote: post #24

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 th…

> 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.

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#29

Post by ramboldio »

samwillis wrote: post #22
ramboldio wrote: post #18

Earlier quoted context omitted.

same itch here. 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 s…

That confirms the impression I had, I guess they are just so complex that building a new open source one from scratch would be Herculean effort. Guess OCCT is the only option for now. The itch I would love to scratch is an online real-time collaborative parametric cad app using CRDTs. Current thinking is combining OpenCascade compiled to WASM [0] with Yjs[1], but frankly don’t have the time. A kind of Figma but for 3…

that sounds very exciting! I also think that a physics / game engine environment would make CAD a lot more accessible. Right now, these two world are very distinct from each other..

Re: CadQuery –- A Python parametric CAD scripting framework based on OCCT

#30

Post by bb88 »

Already__Taken wrote: post #7

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…

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.

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.

Post reply on HN