Hacker News Reader

Comment by rowanG077 | Hacker News Reader

Honestly openSCAD is pretty cool but you quickly run into limitations because of it's DSL. One major reason I don't like it is that it uses mesh-based modeling and not boundary representation. With the former you can never get a "perfectly" smooth sphere for example. Most CNC shops require the latter. So a few years back I moved to CadQuery[1]. CadQuery uses boundary representation and uses Python as it's host language. This essentially makes it superior in almost every way to openSCAD.

[1] https://github.com/CadQuery/cadquery

View on HN

cadquery is great! I had been a Fusion 360 user for 3D printing, but then Autodesk started getting weird with hobbyist licensing. And Fusion's insistence on being cloud-based was frustrating. Anyway, I went hunting for something else and found cadquery and haven't looked back.

Modelling via code in cadquery is definitely a different approach in a lot of ways, but it is extremely powerful too: you get all the goodies like parameter-based, non-destructive history but also things that might not be obvious up front, like being able to "comment out" sections of your model (not just hide them - but skip generating them) temporarily, building up reusable helper routines, easily swapping out rough prototype vs thoroughly designed parts that are depended upon downstream in the model, and being able to organize complex models into separate modules.

I don't think I'd necessarily recommend this approach to modelling to a non-developer, but if you're already a developer, it is tough to beat (for 3D printing at least).

Worth noting that this product is able to operate on CadQuery and JSCAD in addition to OpenSCAD.

Oh wow, I've never heard of this and might have to check it out. I love OpenSCAD in contrast to other free CAD programs I've tried, but not being able to directly work with STEP has been a limitation.

I really would like to know how programs like CadQuery maintain a robust geometric representation given the inevitable rounding errors that will occur in floating point. For example, how can CadQuery guarantee that a surface will never self-intersect after a number of operations have been performed on it?

Wikipedia has a page on it [1], but quickly skims over some techniques without much details.

[1] https://en.wikipedia.org/wiki/Robust_geometric_computation

Cadquery uses opencascade under the hood. I think your best bet is to open an issue and ask: https://github.com/tpaviot/oce

Actually, you can get a perfectly smooth sphere both with constructive solid geometry and boundary representation. Where you cannot get a perfect sphere is mesh-based modelers.

You are right. I was confusing the two. I have edited my comment.

Isn't OpenSCAD based on CSG and not mesh based?

It's CSG using CGAL which is mesh based.

Unfortunately CadQuery (primarily its GUI) seems like its development has fizzled out, without getting it to the point of functionality on macOS. OpenSCAD, on the other hand, works quite reliably on Mac.

Also, it's clunky, but I've had success by using Python to generate OpenSCAD code. The best application of this was an SVG to OpenSCAD path converter.

Doesn't https://github.com/CadQuery/CQ-editor work on MacOS? I don't really see how development has fizzed out. There have been quite a few commits the last couple of months.

I wanted to kick the tires on CadQuery, but I had to install and understand Anaconda first. Any tool that requires me to understand a build system or a language package manager to correctly and safely build the software before I can use it is not ready for prime time.

If this was important for my life, I might put in the effort. If it is for passing curiosity, I probably won't. Especially when it impacts not just this software but opens an entire universe of what exploits can now be run on my PC.

When I have to set up a VM to sandbox an environment for a tool, it stretches my patience. It makes the tool extremely cumbersome.

Of course, when the tool is actually a library for a particular programming language, considerations of build environment and package manager are more germane. But you still might question if it is worth it.

FWIW I'm not familiar with Anaconda either and it took about 10 minutes to get it and the cadquery editor up and running. To each his own though!

I feel you. (Un)fortunately for me CQ is important enough because OpenSCAD and similar are not CADs... they are just simple generators without an ability to reference, use already drawn things. Whereas CadQuery has the main feature which is missing from OpenSCAD directly in its name: "Query".

I'm actively working on bringing CadQuery and all its dependencies to Nix because *Conda is an abomination of highest order.

Moreover the pywrap and OCP which are CadQuery's dependencies are even much worse. They are like galleries of every DevOps anti-pattern ever invented. The more you dive into them the more horrible it gets.

CQ is actually nice though.

Which is ironic given that Anaconda was made to simplify package management and deployment.

Yes I agree. Anaconda is one of the worst pieces of software on earth. In fact I have never gotten it to work with anaconda. I use this nix-flake: https://github.com/marcus7070/cq-flake which is faaaaar easier to use and setup and includes the editor. But the README says it probably won't work on non-nixos systems so your mileage may vary.

Oh no. Somebody has already created flakes for CQ :( But also oh yeah, somebody has crated flakes for CQ! (and it seems I was only 1/2 ~ 2/3 way there anyway)

Since April 2021, and at the time of the OP, there had been one non-readme related commit to the linked repository. And no, CQ-editor does not work on Mac for a variety of reasons, including code signing errors.

Reply on news.ycombinator.com