CAD in Julia?

Hi everyone,

I noticed there are some good packages for making meshes, instant access to GPU functionality, and we have packages for FEM. While working on my recent package I realized I was making a chopped down version of 2-D CAD system. Does anyone know if there is any effort for making a CAD type system in Julia? Or why there shouldn’t be?

I can see several use cases for a “basic” CAD package:

  1. Plain old CAD is nice for web-apps and things
  2. Design/manipulate complicated systems with ease for physical simulations IE: CFD, E&M, FEM, FDTD, etc.
  3. 3-D printer G-code?

Maybe I’ve gone too far with this, but I think the computational physics world may appreciate it. I know we have the talent here to do it in a way that a project like this could be extensible too.

3 Likes

If you are familiar with programmatic CAD like OpenSCAD and ImplicitCAD, I am working on something similar in Julia called Descartes: https://github.com/sjkelly/Descartes.jl. The project is very alpha, and I am focused on the general meshing infrastructure now (Meshing, DistMesh).

The idea for Descartes is to integrate meshing+FEA into the programmatic design process so you can do parametric studies and topology optimization, or just setup a solid model or boundary and get an optimal mesh in return. There are several benefits of a signed distance function, since we can optimize the mesh quality and even do mesh-free analysis. I’ve used Descartes to design and 3D print several models.

As for 3D Printer Gcode, this something Julia is great for. Especially more so with the recent multithreading work. We used Julia at Voxel8 to implement a full path planner, but most of that work was not open. It is perfect for experimenting with different geometric techniques for 3D printing really fast. I think the initial development cycle in Julia was about 3 months from zero to multi-material printing.

12 Likes

Super excited for this!

Now this is incredibly exciting.

Even though it’s pre-alpha I may want to leverage this sooner rather then later. Can I private message you with some simple questions about the project?

Another interesting possibility is to use geometric algebra for engineering, I am working on Grassmann.jl for that, although I have not done any work for visualization. A related project with visualization is ganja.js, together we are also starting a new discourse website at bivector.net to work on geometric algebra software. Some of the applications for Grassmann I envision for the future include FEM and CFD.

YouTube DropBox

3 Likes

Now this sounds fancy. I’ll admit - the title page for Grassmann.jl is a bit intimidating for someone who barely knows what a Grassmannian is. Sounds really cool. I bet if the user interface can reach out to more widely studied/applied areas that people use for things like FEM/CAD/etc people will really love having a backbone like this! Full speed ahead Chakravala

1 Like

Please do not be discouraged by the style, these are just fancy technical words to more precisely describe geometrical concepts you probably already are familiar with. The reason why I build my foundations from the terminology in a certain way is to be more efficient at expressing universal geometrical numbers. By adopting a universal mathematical language, many different domains and applications from distant fields will be able to become interoperable through the language of mathematics and programming. Since I am starting at the very bedrock of the foundations, this is a slower development and research process. However, over time by adopting this system I believe that at some point it will be more efficient.

3 Likes

This may be relevant: I do similar things to generate synthetic voxel-based geometry and mesh it with hexahedra or tetrahedra. Also there is a decimation algorithm to reduce the size of tet meshes.

6 Likes

Hi everybody,
Wouldn’t it be more efficient to try to interface Julia with existing CAD software like FreeCAD?
Cheers,
J

3 Likes

For my needs I decided I am going to release a really weird 2-D Geometry package as a subunit of an experimental package and get some feed-back from some of the smart people here. I realized It’s just too weird to build off of someone else’s work to get the functionality I want so yep another 2-D geometry package. I’m not sure what the most practical thing for everyone else is.

I know there are Julia specific operations that we could leverage in the CAD world. I’m just not sure what is the most relevent depth to pursue for everyone else in these fields.

4 Likes

Do you have a link?

I think we learned that geometry is hard to get right for all cases (API ergonomics, performance, names), so defining your own system is reasonable. Is it a vertex, a node, or a point? Facet, face, or edge? Do you store a polygon as a sequence of points or edges? Do you make p1 = pn? Do you care about color information or normals? These are all considerations that become highly domain specific.

My conclusion is that if we make algorithms generic and clearly state the assumptions we can still achieve good composability. The structure of types in generic geometry will always be a trade-off and compromise unless you define your own.

1 Like

Perhaps the Julian way is to focus on interfaces rather than types?

1 Like

A very good universal API for points, vertices, faces, edges, spheres, circles, lines, areas, volumes, etc can be phrased in terms of geometric algebra and homological algebra… So I recommend using the number system I am developing in the Grassmann package as an underlying type for the geometry. Then we can build the specific geometry types by storing the geometric numbers from Grassmann in that struct.

To see what I’m talking about, have a look at this presentation where conformal geometric algebra is used to compute intersections of spheres, lines, planes, and other geometric primitives. Another upside is that this immediately scales to any number of dimensions and also projective geomtery.

By relying on the geometric algebra of multivectors for storing geometric data, it is possible to do math with those objects much more easily… I think they would just need a wrapper Julia type struct so that the dispatch for geometric objects can be handled in a certain way in Julia.

2 Likes

@sjkelly

Here’s what I’m thinking - it may be naive/fool-hearty. I want to define a geometry package on the following premise:

Infinite shapes: parabola’s, ellipses, lines, etc. These are functions unbounded on X axis, represented by an equation.
Finite shapes: Truncations of infinite shapes defined by a domain on X.
Transformed finite shapes: rotations, translations, etc.

Intersections between shapes and things can then be found by solving the requisite equations straight-forwardly. Discretizations into visual/finite forms (in 2-D plots) are then trivial, but customizable. Operations such as finding surface normals are easily performed via function derivatives.

It’s kind of noncommittal right now, meaning, when we define a polygon by some points, it creates the line equations, and things, but is represented as a collection of finite shapes which are super structures of infinite lines. p1 = pn by user’s choice on the function call. So I’ve dubbed it “geoschism”…

Dunno if this idea is really dumb, it’s not the best idea for FEM, nor easily generalized to higher dimensions, but this is the easiest and most generic way for me to deal with the 2-D problems I want to solve.

@chakravala - I’d love to learn more formal geometry. Do you have any suggestions for a nonmathematician to edge into this world? I’m really fascinated by your posts I just lack a footing in it. I’ve watched lectures on tensor calculus, and differential geometry years ago, not sure if that’d help.

1 Like

We started a new discourse for this at bivector.net but it does involve studying some math. We are trying to make geometric algebra more accessible with that website, it is still very new. Indeed, I consider differential geometry and tensor calculus very important and closely tied together with all this, as I have stated before in my own presentation and paper. However, calculus not necessary for only geometric algebra on its own.

About 100 years ago, knowledge of projective geometry was more standard, but is almost never taught anymore in modern times. Luckily, we can still have access to those books like this one:

In modern times for the 21st century, we are having a revival of Projective Geometry with Clifford algebra

There are lots of other resources out there, I’m not gonna bother to list them all as you can easily find this stuff with a search engine, Vector algebra war and Bigger mathematical picture for Computer Graphics.

2 Likes

Relevant talk

3 Likes

Hello. I just wanted to say that I think this a great project. How usable is Descartes now, what needs to be done? For 3D modeling, I have been switching back and forth between OpenSCAD (also via SolidPython) and Cadquery, and I have also looked at ImplicitCAD. Unfortunately, they all seem to have their problems: In OpenSCAD it is very painful to do chamfering and filleting and some operations (like ‘minkowski’) are slow for detailed objects. The Cadquery “language” (a Python library) is more powerful but I have been running into many problems which I believe to be bugs, e.g. when the intersection of two 3d objects that visually overlap is calculated as empty, or when moving a shape from face to face introduces some unwanted rotations. ImplicitCAD has been abandoned by its original creator and some operations (hull, minkowski) are missing.

BTW, Descartes seems to be similar to ImplicitCAD in the design. Did you find a way to implement those operations that ImplicitCAD does not support? I do not know how to implement the convex hull but at least for the morphological operations, I think there is hope to calculate some reasonable approximations in reasonable time.

Would you mind sharing the models you did in Descartes, so that we can appreciate how capable Descartes is now?

Thanks again for starting this project and good luck. Yours,

Jan

1 Like

ImplicitCAD, Libfive, Curv, and Descartes are all in the same family of signed-distance field modeling tools. Descartes is very alpha, so I wouldn’t call it as usable as the other three modelers.

The convex hull problem really requires a mesh for arbitrary geometries, but there are some simple cases for primitives such as hull of two cubes or two spheres that can be done in certain cases. A pure approach to convex hulls on arbitrary signed-distance/implicit functions is not something I have encountered yet.

On the other hand, SDF->Mesh->SDF is something I am exploring now for tetrahedral mesh generation, particularly targeting grid-like structures (level sets, DICOMs, etc). This should set the foundation for convex hulls. I strongly agree with you that programmatic solid modelers need the basic operations (filet, chamfer, sweep, hull) to be usable and no tool has all of these yet.

This semester I am working to finish up DistMesh and work on a Descartes -> DistMesh -> JuaFEM/TopOpt pipeline for parametric design studies. As for things printed with Descartes just look at my profile picture! :smile: It was done by decimating the Stanford Bunny and calling this function.

6 Likes