I'm helping CadHub out by designing the interfaces for the new editor, project viewer, and more. Right now we're focused on getting the Code-CAD user experience perfected so that users can try out all the great Code-CAD packages out there in a simple and sharable way. But we think that the future of Code-CAD will pull UX lessons from traditional, GUI-based CAD systems. So I'll be taking a look at the history and UX of some of today's CAD tools to see how we might bring them along with the Code-CAD evolution.
One of many aspects that makes the world of software unique is there is a limitless horizon of abstractions possible, "turtles all the way down" so to speak. It's truly an awesome tool, it allows use to move quicker, create expressive APIs for our users, "deploy anywhere™️" and more.
I know when I first made this discovery, I had a palpable sense that I'd be able to create beautiful software, where not a single piece of logic would ever repeat, from the power of my abstractions. But they come at a cost, it might be performance, it might be debuggablity or observability. Or to my horror, maybe the beautiful code I was writing was actually harder to understand, and more brittle than if I hadn't got so high on the abstraction drug.
CI/CD pipelines usually have at most two types of artifacts. Primarily it will be the program, (an executable, web-app static files etc), and also often test reports. If the process is a bit more exotic it might have a couple other outputs. CodeCAD however, has a multitude of different types of artifacts that can be produced.
- The 3d files is obviously the primary output.
- Test reports would be the same too but with some subtleties.
- Images/renders reproduced each merge would allow reports or webpages to stay up today with the latest model
- Bill of materials (BOM)
- GCODE or similar artifacts used for manufacture
Like many, OpenSCAD was my portal into the world of CodeCAD. Once I started making parts with deterministic scripts there was no going back. That doesn't mean that I wasn't frustrated by certain things, a big one for me was how difficult fillets and chamfers can be with OpenSCAD. So much so, I was driven to create a library to help with this and I even contemplated creating my own Code-CAD tool/language, in particular I was interested in introducing sketch mechanics.
CodeCad is software, and software should have tests right? is it that simple? Yes but also no.
Yes because unit tests will be fundamentally the same for testing any small part of the CAD code. But No because CodeCAD is a unique application of software, it brings with it it's own unique tests. Though tests might be too vague of a term. Let's keep "tests" for unit tests, but introduce "checks" and "analyses" to encompass other processes that we want to run as part of verifying changes to our CAD software.
When making a change to a repo, we're all familiar with code diffs, so common we don't give them a second thought. What's so powerful about code-diffs is they let us to apply our entire conceptual model of how the software functions to a laser focused section the code, to both check that the change is good, as well as giving us a chance to update that mental model incrementally.
CodeCAD is in a unique position that it outputs a 3d artifact, but we can also produce diff artifacts for the purpose of reviewing, it's so intuitive that it needs little explanation, so here's an example:
It's software that allows you to define 3D CAD models with code. It's a niche popular amongst software devs for obvious reasons — it gives you parametric models almost by default and it's easy to maintain and extend models within a team over time when paired with git. The coding nature of it allows teams to build their own abstraction for re-use and quick prototyping. The Cadhub homepage has a good breakdown of the potential of the Code-CAD paradigm. Code-CAD is not to be confused with 3d geometry libraries, Code-CAD instead has opinionated abstractions for quickly developing mechanical parts.
I recommend reading through the entire list below to see if one chimes with you and your needs, beyond that I can make the following recommendation and points:
This is an:
- Overview of OpenScad and where it fits in with other cad packages.
- What's it good for and not so good for,
- And whether I think it's worth learning.
Checkout out the video version here.