CadQuery might eventually become more popular than OpenSCAD.
Many 3D printer operators have heard of OpenSCAD. It’s a 3D CAD system that’s quite different from most CAD tools. The typical CAD tool uses a visual interface to perform solid modeling: put a block on top of a cylinder, etc. OpenSCAD has quite a different paradigm.
Instead of visually building a structure, OpenSCAD uses a computer program. The language is specialized to invoke the creation and manipulation of solid objects. The result of the system is a 3D model, much like is produced with more common CAD tools.
Why use a program instead of a visual approach? The big advantage is that you can apply programmatic logic to the object’s design. This enables creation of highly complex 3D models that would otherwise be far to too tedious to make with a visual tool.
Another huge benefit to programmatic design is for customization. It would be possible to make a “base model” that can be tweaked by adjusting some of the parameters. For example, a plate with four holes could have six instead. Or seven. That’s easily done because the program can accept input parameters to do so.
For years OpenSCAD has been the king of programmatic 3D design, and has been widely used, particularly for customizable 3D models. However, there’s a new player on the scene: CadQuery.
CadQuery, like OpenSCAD, is an open source project hosted on GitHub. This means it’s entirely free to use, and if you’re capable you can even contribute to its design and coding.
Why jump to a new programmatic 3D modeling tool when OpenSCAD works quite well? There are several reasons, as stated by the CadQuery team:
- The scripts use a standard programming language, Python, and thus can benefit from the associated infrastructure. This includes many standard libraries and IDEs.
- CadQuery’s CAD kernel Open CASCADE Technology (OCCT) is much more powerful than the CGAL used by OpenSCAD. Features supported natively by OCCT include NURBS, splines, surface sewing, STL repair, STEP import/export, and other complex operations, in addition to the standard CSG operations supported by CGAL
- Ability to import/export STEP and the ability to begin with a STEP model, created in a CAD package, and then add parametric features. This is possible in OpenSCAD using STL, but STL is a lossy format.
- CadQuery scripts require less code to create most objects, because it is possible to locate features based on the position of other features, workplanes, vertices, etc.
- CadQuery scripts can build STL, STEP, AMF and 3MF faster than OpenSCAD.
These are significant advantages, particularly the first item. There is an astounding amount of Python code available for all kinds of purposes, and some of it can be leveraged by CadQuery to generate new forms of 3D models. This is an area that could enable considerable exploration.
The NURBS and splines capability will certainly result in more complex and interesting 3D models. The other natively supported features show the leverage of existing code.
One of those features is STEP integration, which enables a connection between programmatic design and commercial CAD systems that use STEP format. That alone could be quite an interesting space to explore.
It’s likely that opening the door to all this external code is something that OpenSCAD may not be able to easily match in the long term. Thus it is entirely possible that over time usage of OpenSCAD could fall below that of CadQuery.
CadQuery still seems to be a bit early in the lifecycle, as it is apparently a bit tricky to install. For example, the project strongly recommends using a virtual environment to isolate the “complex set of dependencies” from the rest of your system. You also need to use a specific custom editor for preparing the scripts used by CadQuery.
However, I suspect over time kinks of this type will be smoothed out and CadQuery will become more accessible to everyone in the 3D space.
Via GitHub (Hat tip to Benjamin)
