|
|
|
@ -0,0 +1,59 @@
|
|
|
|
|
+++
|
|
|
|
|
title = "Design ideas for a Code-CAD package"
|
|
|
|
|
template = "page.html"
|
|
|
|
|
date = 2022-02-18T20:00:00Z
|
|
|
|
|
[taxonomies]
|
|
|
|
|
tags = ["CAD"]
|
|
|
|
|
[extra]
|
|
|
|
|
summary = "Basic high-level collection of ideas about a CAD package"
|
|
|
|
|
mathjax = "tex-mml"
|
|
|
|
|
+++
|
|
|
|
|
|
|
|
|
|
# Goal
|
|
|
|
|
The goal of this project is to make a [CAD](https://en.wikipedia.org/wiki/Computer-aided\_design)-system which is mainly accessed by a powerful functional programming interface.
|
|
|
|
|
It will be [Free and Open Source Software](https://www.gnu.org/philosophy/free-sw.en.html).
|
|
|
|
|
|
|
|
|
|
# Requirements
|
|
|
|
|
- Functional programmable interface
|
|
|
|
|
- Mechanical CAD
|
|
|
|
|
- Basic shapes
|
|
|
|
|
- Basic boolean operations
|
|
|
|
|
- Electronic CAD
|
|
|
|
|
- Basic components
|
|
|
|
|
- Simulation
|
|
|
|
|
- A (more or less) standardized way of exchanging programs in form of modules/packages
|
|
|
|
|
- A way of deconstructing the part(s) by virtually mimicking the assembly/fabrication process to get to the starting materials
|
|
|
|
|
- A way of dealing with units, that doesn't feel like an afterthought
|
|
|
|
|
- Synthesis of constraints for the parameters
|
|
|
|
|
- Support for tolerances
|
|
|
|
|
|
|
|
|
|
# Reasoning
|
|
|
|
|
|
|
|
|
|
> Combining forms can use high level programs to build still higher level ones in a style not possible in conventional languages.</p>
|
|
|
|
|
> — <cite>[John Backus](https://doi.org/10.1145/359576.359579)</cite>
|
|
|
|
|
|
|
|
|
|
One can think of these forms as basic shapes like for example cubes or spheres and the programs as functions, which combine them and return a "higher level" shape.
|
|
|
|
|
This way very complex final outcomes can be generated. The ability to build a new layer of abstraction above the underlying principles and parts can make it easier to discuss them.
|
|
|
|
|
This is why a functional approach to building this is superior to others.
|
|
|
|
|
|
|
|
|
|
The distribution system is already a solved problem, since there are already many different build systems and methods of distributing software and code. In this case [Nix](https://nixos.org/)
|
|
|
|
|
seems to be a good choice because it is already functional at its core. Especially Nix flakes seem to be a good fit for this task.
|
|
|
|
|
|
|
|
|
|
The functions which describe a part can have different parameters. As described [here](https://www.youtube.com/watch?v=MhlDpMZUTrg) not all combinations of them lead to a valid result.
|
|
|
|
|
A system to find the constraints would eliminate a lot of guesswork.
|
|
|
|
|
|
|
|
|
|
Idiomatic support for tolerances would similarily help with this.
|
|
|
|
|
|
|
|
|
|
# Existing solutions
|
|
|
|
|
|
|
|
|
|
[Solidworks](https://www.solidworks.com/), [Freecad](https://www.freecad.org/), and others are graphical CAD packages, which offer many features and are (mostly) easier to learn than a Code-CAD package.
|
|
|
|
|
|
|
|
|
|
[OpenSCAD](https://openscad.org/) is a Code-CAD package, which means that it offers many advantages over Graphical packages like the ability to be versioned with Git. But it does not offer a
|
|
|
|
|
functional interface. The output is implemented as a set of commands, that show a object on screen and not as a value, that is returned from the function.
|
|
|
|
|
|
|
|
|
|
[FunCAD](http://gramlich.net/projects/funcad/introduction.html) is a work (kind of) in progress CAD package. It aims to provide a operation for every step that could be done in a workshop.
|
|
|
|
|
I believe this is the wrong way to do go about that because the user should be able to think abut fabrication after the shape is already done.
|
|
|
|
|
|
|
|
|
|
[ImplicitCAD](https://implicitcad.org/) is a functional Code-CAD package, which is licensed under [AGPL 3](https://github.com/Haskell-Things/ImplicitCAD/blob/master/LICENSE). This is a problem
|
|
|
|
|
because it restricts the users to the same license for their projects. I think more permissive license would be more suitable (at least for the basic libraries that will be imported in the
|
|
|
|
|
code of the part itself). The viewer/editor can be under a GPL license without any problem.
|