[ANN] I started a package for writing CAD design in Julia

As the title says, I started writing a package for defining CAD objects in Julia.

Why would this be useful?

I believe it is useful to have an alternative to OpenSCAD which offers all the advantages of a full-fledged programming language (including for example the ability to include external libraries, or to read files), and the capacity of directly manipulating the contents of the objects (whereas OpenSCAD’s modules are completely opaque to the script). Moreover, extending OpenSCAD is always quite hard, because that programming language is so limited (it has all the inconvenients of a functional language with few of their advantages — although recent releases promise function values, that’s still very experimental). Writing new packages directly in Julia would be easier.

Given its easy syntax and its speed, I believe Julia to be the right tool for this project. We can also leverage the rich ecosystem of geometry, computation and visualization modules. (This is one reason why I did not just use ImplicitCAD. The other is that some operations are probably easier to write with meshes than with signed distance functions. However, note that the Solids package is quite open to a SDF back-end!)

What can it do right now?

Not too much right now.
As a small proof of concept, the package Solids.jl today has more or less the following capacities:

  • a full syntax for defining and transforming “ideal” 2d and 3d objects (without too many parentheses), which is similar to OpenSCAD but full-fledged Julia code;
  • an almost complete 2d subsystem (= conversion of ideal 2d objects to a set of polygons);
  • a convenient way of reading all the objects in a script;
  • OpenSCAD output (only for objects which also exist in that language though).

An example of code written with this module follows:

using Solids

Square(20)

linear_extrude(30) * [
  intersection(
    translate([10,0]) * Circle(3),
    translate([13,0]) * Circle(3),
  ),
  color("pink") * scale(2) * Square(1),
]

What should it do next?

The next big steps would be writing the full 3d system (using one of the packages which interface CGAL for example); providing visualization (using e.g. GLMakie); and exporting directly to 3d file formats such as STL. These steps, while big, do not seem impossible given all the variety of packages in the Julia ecosystem.

As I’m quite a beginner in Julia (this being my first attempt at a package), this is as much of a call for help as it is an announcement. Any help or advice is welcome!

26 Likes

I would be really interested in this, but such a package won’t be a small endeavour. I think designing complicated geometries can really benefit from parametric modelling with Julia at the back. I think we are also moving away from traditional CAD, where one would make a 2D outline and then sweep or extrude it to a 3D shape. Instead I think we are going towards generated designs or designs that are described by parametric equations. As far as I know, there are no really good tools for that, and I am not really sure a graphical tool would be the best even. My interest would be to drive geometry using constraint solvers and optimizers coupled to (finite element or finite volume) models. (My background is in mechanical engineering and topology optimization)

Do you already have ideas on how you want to structure your package?
And how the user should interact with geometry?
I can see some of it through your example, but I’d really like to hear about your assumptions, vision and what you are planning to use it for.

I’d recommend to checkout OpenCascade and its PythonOCC interface, if you haven’t already. Also Rhinoceros’ grasshopper might also be good source for inspiration. There might also be intersections with Paraview and how it builds up a 3D scientific visualization.

1 Like

Nice.

I love OpenSCAD.
I have done a couple of really cool things in it.
It does seem odd though to have to learn a esotetic programming language just to do CAD.
So a julia package makes sense.

I suggest it would be good to looking into cutting OpenSCAD out of the pipeline, and exporting straight to STL.
MeshIO.jl has functions for that.
(I have never used them).

And using Makie for visualization GitHub - JuliaPlots/Makie.jl: High level plotting on the GPU.

OpenSCAD is incredibly slow.
I am not sure if can do faster in julia, but i think it is worth a shot.
My last project incolved a few dozen extrusions of a logo in different sizes to make a trophy.
I think it took about 10 minutes to render in OpenSTL

5 Likes

FYI, here’s a related thread:

And here’s another Julia CAD package that was mentioned in that thread:

3 Likes

@Floris

The workflow I imagine for now for a end-user is entering geometry in a .jl file and having a separate REPL session where the file can be displayed and compiled. Of course, it is really simple to make various workflows possible (including compilation to STL from command-line, or automatic update of display when the file changes).

I still think that, even though this is not a tiny project, at least achieving a compiler with similar features to OpenSCAD is manageable, simply because we can use the already-rich Julia ecosystem to do most of the work; all that remains to do is interfacing between stuff. (This is what I wrote for the 2d part: it’s mostly a set of wrappers around Clipper.jl).

@oxinabox

Cutting OpenSCAD out of the pipeline is indeed a medium-term goal, and not too hard once the 3d system is in place (by then the only remaining parts will be STL I/O and text rendering). Makie is indeed what I plan to use for visualization (it seems able to display 3d meshes already), but this is probably the part where I most need help - I’ve never used that package before, and the docs are a bit daunting.

@CameronBieganek

Yes, I know about Descartes.jl. However that package seems very much focused on signed distance fields, whereas I prefer remaining backend-agnostic as long as possible; moreover it uses GeometryBasics.jl, which seems quite broken as of now (at least its online documentation is! it is only a set of “missing docstring” warning boxes…).

3 Likes

By the way, I got path extrusion to work in some cases, which is something OpenSCAD does not implement:

(The image is generated by OpenSCAD, but its input is an explicit polyhedron(...) computed by the Julia package).

11 Likes

I have used Salome-Meca on a few occasions. I consider it to be the most polished and most capable open source solid modeling / FEA combination. It combines Open Cascades, Code Aster and Paraview for solid modeling, FEA, and post-processing. I am not sure about the Open Cascades part which seems to be the interest of this thread, but the FEA part uses Fortran code modules that are strung together with python. Code Aster the FEA portion is written by the French electrical utility research organization, EDF. It would certainly be a good place for inspiration.

2 Likes

I changed the name of the package (Solids just felt a bit silly). It is now called ConstructiveGeometry.jl and version 0.2.0 is out.

@Jake: I will definitely have a look at Salome Meca, if only by patriotism… thanks for the pointer!

5 Likes

Are you aware of the CSG bits in this recently released optical simulation package? CSG · OpticSim.jl

2 Likes

There’s also another cool julia package https://github.com/avigliotti/AD4SM.jl

2 Likes

I recent discovered the Khepri series of packages, which seems to be in the process of being redesigned, but can control a large amount of both open source and proprietary CAD, computational design, and visualization tools.

It is being created by: ADA

3 Likes

It took me a while to figure out what this Khepri thing is about. There are no docs on the GH sites… This might help: algorithmicdesign.github.io/tools/kheprigh.html

4 Likes

That video is a nice find.

I thought about creating a Julia package to drive Houdini, for a procedural visualization workflow similar to the workflows here but with some synchronization like in Khepri:
http://wordpress.discretization.de/houdini/

Julia has a lot of promise due to the “two language problem” in all of these apps. In Houdini, for example, the old and ancient “HScript” was finally replaced with python3-based API, however, python is too slow to drive many of the core hot paths in Houdini, so there is a separate proprietary lang (VEX) that is JIT’d via the C++ engine.

The embeddability situation seems to be incrementally getting better with Julia’s runtime, hopefully at some point it is as easy as with Python or Lua. The potential reach is very high.

1 Like