Main concepts of madcad¶
Comparison with existing CAD softwares¶
Current CAD softwares, are based on a full GUI oriented approach, with parametric features bases on dynamic relationship between the scene objects. This can leads to many problems:
Objects relationships are never visible, thus tricky to understand and to manage. On most of these softwares it’s in fact impossible to manage it.
The software has to be very complex to handle all possible behaviors in parameters change in order to update the model.
The primitives is always limited to a small set fixed by design.
The GUI has to be very complex to allow the user to deal with every aspect of the objects (thus many tools, many object menus, sub-menus, context-dependent behaviors). The softwares are very hard to maintain, and often buggy
When a CAD file grow in complexity, we must avoid to modify it deeply or the entire build-tree fails and it’s no more possible to repair.
The build tree is rarely human-readable.
The current library differs in its approach by the following points:
- MADCAD is a script based CAD
all the functions of madcad are available in the current API. Nothing is hidden. The python script is the build tree, it is as readable as the user makes it. We strive to keep all the functions simple and intuitive to allow a good readability and a fast scripting.
- MADCAD is not a parametric software
a madcad script is just a regular Python script. What makes the madcad files parametric is the ability to change variables and reexecute the script.
So madcad is generative, for implicit geometry definitions, the user has to use a solver before constructing the objects.
- MADCAD is extensible
As it’s a regular script, it’s possible to use from simple to complex programming concepts (if/else, loops, tables, functions, classes, module imports, generators, …). Giving it infinite more possibilities, and in an easier way than with other softwares.
Design and concepts¶
The last section describe the guidelines. Here is what these considerations brought us.
The build tree is replaced by a script, thus a programming language was needed. For the best readability it had to have a very clean syntax. But for the highest flexibility it has to be very dynamic and powerful. Object orientation is necessary for transparent data manipulation, as well as dynamic typing. Functionnal programming and generators are welcome.
Choice is Python
The object oriented system helps to get each variable an identity depending on the true meaning of the contained data. We choose to get the classes the closest to the mathematical instrinsic meaning of the data.
- Choice is to split types across their geometric nature:
for both points and directions
for direction associated with an origin, as well as for planes
for affine and linear transformations, rotations, bases
only for surfaces
only for lines
for objects inside the same movement
For efficient and simple linear algebra operations (vectors, matrices), We needed a library. It has to get very short type names (as often repeated in scripts and library). Few but universal operations. Compiled runtime and memory.
It appeared that the GPU shader languages already fixed that for us, with a sort of universal API for 2-4 dimension types.
Choice is PyGLM
It’s always a difficult way to stop a decision on the way to represent 3D objects. In most cases we represent it by its exterior surface, but the problem of the polygons remains:
ngons, quads, triangles, bezier, … ? And the way to put it into memory also:
simple unit elements, dynamically typed polygons, halfedges, quadedges, … Or even the way to access it:
arrays, chained lists, octree, hashmaps.
- Choice was not easy but is in favor of simplicity:
- array storage
- simple unit elements
vec3for points and
tuplefor edges and trangles
- surface is only made of triangles
This structure is very simple and common in the 3D computing, and it makes easy to write most of the operations. Therefore the storage is exposed to the user.
As 3D manipulation can be complex, it’s mandatory to visualize any kind of objects. A part of the library is dedicated to display the objects in an OpenGL scene. But to allow user interactions and allow to embed the scene widget, we had to focus on one only panelling library.
We prefered to bet on the most - advanced and feature-complete - free library despite its differences with the python environment.
Qt5 is not very pythonic (it’s designed for c++, no functional programming, huge inheritance instead of python protocols, string typing, enums, camelcase, …). But it may evolve in the future, according to the Qt6 guidelines