Author here. Sorry, I abandoned this two or three years ago. Please look at this in the context of a project done several years ago and never completed. (I do ML research these days -- you can see my blog here: http://colah.github.io/)
Julia Longtin took up working on ImplicitCAD a few months ago. I'm not sure how much she's progressed with it.
Honestly, I no longer believe ImplicitCAD was the right approach to the problem, or that there's even as much of a problem as I originally thought. In particular, the system ImplicitCAD uses to represent objects, a variant of f-rep (http://en.wikipedia.org/wiki/Function_representation) has issues. (f-rep is awesome, I just tried to have my cake and eat it too with some trade offs, and thought I was being really clever! :P)
After ImplicitCAD, I worked with Rob Gilson on a SVG/WebGL constraint-based modelling tool, mech.ly. We got some neat stuff working, but never got to a point where we wanted to release things. I'm pretty persuaded this is the right direction to go.
I learned a lot from both projects. I also matured a lot intellectually. For example, I now review academic literature before diving into solving hard problems! :)
As the submitter I just want to say thanks for dropping in to comment. As a professional CAD user and hobby Haskell learner, I found the project very interesting and thought it was worth sharing. If you ever feel like sharing I'd be very interested in reading a post-mortem of your work on ImplicitCAD or any other CAD-related software.
I second this; it's really motivating to learn about an emphatic approach to an idea that ultimately resulted in an oblique transition. A post-mortem would help those interested in solving similar problems start from a more informed base.
Some time ago ImplicitCAD inspired me to try a somewhat different approach: using the same OpenSCAD source language, generate OpenCL kernels for efficient, explicit CSG splicing (no meshes, triangles and stuff, only the nice continuous surfaces).
So I've looked at potentially working with OpenSCAD before, but unfortunately had to go back to something like Autodesk Inventor before really starting. The biggest problem I have with all open source 3D CAD systems are the lack of parametric modeling.
If you're unfamiliar with this, this basically is setting constraints on your geometry. For example, you can say that edge A has the same length as edge B, and it mirrors across plane C, which is 10 cm away from the primary XY plane.
This is essential to my workflow in 3D modeling and makes most geometry based operations (such as specifying that edge A is 10cm and starts at 3,4) obsolete. It also allows easy assemblies: you can specify the axis of shaft A need to be coincidental with the axis of hole B.
Plain text based 3D modelling would be awesome as you can use reasonable revision controls and have reasonable merge strategies.. but the lack of parametric modelling, at least for me, is a deal breaker. I've looked into writing a library for parametric modelling in Python, but then I realized that you probably need to be a PhD in geometry to write a correct implementation with reasonable speed....
At first, I tried to implement constraints in a Haskell DSL. Unfortunately, constraints usually only partially describe your object. Even a well-constrained object can be flipped and maintain the constraints, in most systems. I coudln't find a reasonable way to implement a text-based interface for this. It really needs to be graphical.
I abandoned ImplicitCAD to write a constraint-based CAD program with my friend Rob Gilson. (I handled constraint solving with gradient descent, which worked surprisingly well, and a dab of grobner bases here and there.) We got some neat stuff working, but eventually got pulled away to other projects.
I think there's a lot of interesting work to be done linking programmatic and graphical CAD. In particular, I think there's neat connections between constraint based CAD which is a form of visual logic programming, and functional programming. (Aside: I like Bret Victor's talk "Stop Drawing Dead Fish" which is on a kind of related topic.)
Unfortunately, I'm too busy with ML research these days to work on this stuff!
As a frequent user of Solidworks for ~4 years, I'd have to guess that CAD constraint solvers are not an easy problem.
It happens pretty often that you'll modify a single constraint (flipping it is a common culprit), the solver will get "confused" and flip a bunch of your other constraints around. Constraint conflict resolution also often gets very hairy to almost impossible. Sometimes the fastest thing to do is to nuke a good part of your constraints and start over -- in a saner way.
I guess the BIG CAD packages (CATIA, NX) might be a bit better at this, or at least better at strongly encouraging saner ways of build parametric constraints (which is what I've heard).
It's too bad that there isn't a simple, intuitive and useful free/oss CAD software out there. With the whole hobbyist maker movement explosion out there, a lot of people would be thrilled to have something like that. Though, it seems that things are not very much better in the PCB CAD/CAM world either.
I was really excited about handling some of the messy constraint situations better than existing tools. I'll split this into two pieces:
> It happens pretty often that you'll modify a single constraint (flipping it is a common culprit), the solver will get "confused" and flip a bunch of your other constraints around.
For "confused" constraint solvers, I see this as largely being a problem of there being lots of solutions to a well constrained system, because of flips and such. It needs to be easy for the user to specify which one they want.
Our approach was to have fast pulls of the mouse temporarily over ride the constraint solver. So, if you needed to flip the model, you do a really fast pull and it would flip. This works much better with multi touch, where you can just grab a few points with different fingers and force your model into whatever shape you want.
> Constraint conflict resolution also often gets very hairy to almost impossible.
There's some really powerful tools from algebraic geometry I tried to apply to this. In particular, there's these things called Grobner Bases which you can use to test if certain polynomials imply that another is true, false, or if it's independent of them.
From the users perspective, I wanted to use these to do a few things.
(1) Display implied constraints. If you make three corners of a quadrilateral perpendicular, the fourth is forced to be perpendicular. I grayed out perpendicular constraint could alert you to this, and prevent you from adding a conflicting constraint. Obviously, that example is kind of silly, but I think that propagating constraints through the whole model would really help people understand how more complicated models are constrained.
(2) If you try to add a constraint which conflicts with preexisting ones, highlight in red a minimal set it conflicts with.
I never got this part of the project to work though. I did some very small proof of concepts in sage, but couldn't really get things to work. I'm not really sure how realistic it is to make these work for real models.
It's not FOSS, but the new WebGL-based Onshape[1] from the original Solidworks team looks like it is going to be making waves. It's free for small public projects (Github-style). They are licensing the existing Parasolid and D-Cubed libraries to do constraint-solving[2], which hints at the a) separation of concerns from the CAD UI and back-end layers, and b) complexity of the CAD kernel problem.
> I think there's a lot of interesting work to be done linking programmatic and graphical CAD.
I thought about this as well, but I don't know anyone who works with CAD who would likely switch their work flow from GUI to text-based, other than people in this thread, I suppose.
Furthermore, while I don't know about the details on how to implement a text-based 3D modelling language for constraint based modelling, I don't think there's a lot of point if a GUI is going to be attached to it anyway. Existing systems already do a reasonable job.
One of the most annoying part of the confused constraint system, for me, is that it is difficult to fix the constraints. Options are likely to be hidden behind layers and layers of menus and dialog. A text file can be easily searched and diffed, which in my mind should make a confused system easier to resolve. So maybe this kind of constraint based CAD should have both a language and a revision control system built into it, or something.
> but I don't know anyone who works with CAD who would likely switch their work flow from GUI to text-based, other than people in this thread, I suppose.
Programming doesn't have to be writing text. :P
Everyone seems to be thinking about APIs to the CAD program, which solidworks, autodesk, and presumably others provide.
I had in mind a pretty deep way to embed a lambda calculus into the visual interface. The hope was to make it intuitive to create powerful parametric models, where every sketch is a function of different parameters. We never implemented that part, though. :/
I think CAD constraints would always be expressed in a linear system. I'm wondering if one could use Cassowary for constraint solving here ?
Somehow UI-control-layouting with constraints feels similar to constraints in CAD drawings ? :-)
+ How does gradient descent work with over-constrainted models ? (as in: impossible to satisfy all constraints). You need some way to back out of those or relax one of the constraints.
> I think CAD constraints would always be expressed in a linear system
Typically, you want to at least be able to express the lengths of lines, and the values of angles. I don't know how you could do this without using at least quadratic terms. So you have to do at least quadratic programming, and there's some things that can add higher degree terms.
Moreover, extremely similar problems are studied in automated geometric theorem proving, and they also get pulled into using polynomials.
Unfortunately, these problems are much much harder than linear programming.
There's some really powerful tools from algebraic geometry, mainly Grobner Bases, which you would ideally want to use. They're ridiculously powerful. Not only can you use them to solve systems of polynomial equations, but you can also test whether a set of equations implies another polynomial, or conflicts with another polynomial -- super useful for dealing with over-constrained models.
Tragically, the relevant algorithm is O(exp(exp(n))) -- well, or at least, that's the best upper bound anyone can probe, in practice it isn't that bad. Still, I quickly ran into computational problems. Grobner bases, also, while great are tricky to work with if you only want real valued solutions. They like to give you complex valued solutions to problems, and complex valued solutions to your CAD constraints are usually not what you are looking for.
> How does gradient descent work with over-constrainted models ? (as in: impossible to satisfy all constraints). You need some way to back out of those or relax one of the constraints.
In my implementation, each constraint was a separate cost function, which I added together. Normally, when you run the solver, it pushes all the constraint costs to zero, and you know you've solved everything.
Sometimes it would get stuck in a local minimum and require user intervention to help it get to the right solution. That was surprisingly rare.
If you have conflicting constraints it simply fails to reach a cost of zero at all. You can handle that in your interface however you like. The obvious thing is to try and solve a constraint immediately after adding it and then reject the constraint if you can't.
(I really didn't expect a local optimization method like gradient descent to work so well, but it did. That said, if I attacked the problem again I would try to use some sort of second order optimization method, I think.)
> * this line needs to be 1/3 the length of that line
> * these set of lines should start 50mm left of this line
Remember that you're working with points. So, to express the length of a line, you need something like (x1-x2)^2 + (y1-y2)^2 .
If you just wanted to do things like "this point is +(0,10) of this other one", you're doing a really simple constructive system, which is easy to evaluate, but not anywhere near as flexible or powerful. ImplicitCAD/OpenSCAD trivially do that, just without a nice interface.
I've had an interest in constraint-based CAD programs (with an interest in designing things for 3D printers), and was wondering if you could recommend any literature on the subject.
That said, I naively tried a bunch of naive approaches and had quite a bit of success with plain old gradient descent -- it was really surprising. I'm not sure if it would scale to really significant models, but it's something you could implement in a few hours and you could use to get a project off the ground.
For some reason it's barely known about, which is a shame. It's truly fantastic - once you understand the UI it's almost as powerful as SolidWorks or other commercial parametric CAD systems (for smaller tasks anyway - once you get larger and more complex models it starts to struggle).
I've been doing some work on this -- not a full-on parametric solver, but setting a directed acyclic graph of relationships then evaluating the graph to produce a set of solid models.
The tool is being beta-tested in fab academy [1] this semester; shoot me an email (in my profile) if you're interested in learning more.
> The biggest problem I have with all open source 3D CAD systems are the lack of parametric modeling.
I remember doing that in FreeCAD. Maybe I didn't get all the intrincacies and you mean something bigger than what I tried, but there was definitely a constraint system.
That part is constructed using a series of 2D sketches with 2D constraints. It is still difficult to create complex assemblies in FreeCAD with 3D constraints between parts (such as aligning two faces of different parts or constraining different parts to the same axis)
An assembly module is being developed which addresses this problem, but it's a recent addition and still has some limitations
FreeCAD is a very good piece of software none the less
Same here. I'm stuck with SolidWorks and thus Windows. My workflow involves running the output of the CAD program through a simulation and using that to optimize the parameters of the CAD model, relying on the various geometry constraints being solved by the CAD program. SolidWorks is great for modeling the devices in a parametrized fashion, but it really isn't meant to be scriptable.
And yet it still manages to be the ugliest kludge in my workflow. Just getting it to rebuild and reexport an updated model requires at least a full minute of it popping up windows all over the place—one each for every part, assembly, and spreadsheet holding the parameters—and I have to structure the rest of my code around the limitation that I can only have one SolidWorks instance running at a time while everything else is highly parallel. There's a problem when the CAD program is a noticeable bottleneck in a process that also runs multi-GB FEM simulations.
I'm not sure; I didn't write that component and I don't think it's been rewritten in probably a decade, just linked against newer versions of SolidWorks. It's ugly but it works, so we only start looking at the internals of SolidWorks when they introduce a new bug that affects us, which hasn't happened in several years.
I'm not optimistic, though. Even in normal interactive use, SolidWorks cannot manage to read updated values from a linked Excel spreadsheet upon opening a part (or writing while saving the part) without the embedded Excel window flashing up briefly. Getting SolidWorks and it's Excel child process to both stay in the background isn't really worth much effort to us at the moment, and I do occasionally get the benefit of spotting something breaking when the model flashes up on screen, instead of discovering it much later.
It's really something that shouldn't even require COM/OLE style stuff, just some basic command line functionality. But why would a Windows-only app support that method of interaction?
> I've looked into writing a library for parametric modelling in Python, but then I realized that you probably need to be a PhD in geometry to write a correct implementation with reasonable speed....
It's a neat tool for programmers, but mechanical engineers don't want no part of this. What they want is something that operates visually and lets them design parts and assemblies with direct manipulation and shaping of 3D objects, applying constraints and invariants, etc. This is why the industry has standardized on tools like SolidWorks and Inventor -- those tools operate the way a mech eng thinks.
Knuth ran into the same problem with METAFONT for typography: 99% of designers were not skilled enough at programming to effectively create beautiful fonts with METAFONT, nor did they wish to be. And today METAFONT is nowhere while Type1, TrueType, and OpenType proliferate.
I agree with this, the process of mechanical design very much involves messing around with things visually.
I've interned in a place that still used "good old" 2D, non-parametric autocad, and a lot of the "premilinary" design work took place on scratch pieces of paper. Sketch stuff up quickly, see how it looks and fits together iterate. Move to autocad for a to-scale sketch, then to drafters to the official engineering drawings.
Really? I've been working for a CAD company which only recently (about 10 years ago) got visual modelling for their 30+ years old product, and still a majority of their customers do not want to use it, preferring a huge, convoluted, awful text-based language instead.
For some reason it's barely known about, which is a shame as it's by far the most powerful open-source CAD system I've used. The parametric modelling system is very similar to that of commercial CAD software.
Working with FreeCAD means maintaining OpenCASCADE, here's my notes (hopefully this will help you get a sense for what you're signing up for): http://diyhpl.us/wiki/cad/opencascade/
I think that OpenCASCADE is very difficult to maintain. At least half the variable names are "aMPBLPB" and "aMPBLI", the other half are some strange combination of Russian, English and French. I think that to insulate yourself from the actual CAD engine it would be a good idea to use cadquery, a python library that is aiming to let you switch out the actual CAD implementation without (dramatically) rewriting your source code.
At the moment, I think the two biggest players in the CAD kernel landscape are verbnurbs ( http://verbnurbs.com/ ) and solvespace ( http://solvespace.com ) (which includes parametric modeling and constraint solving, btw). Both are very well written, well documented, and well tested. BRLCAD also has surface-surface intersection for NURBS, although I don't remember all the caveats....
First off, thank you for mentioning Cadquery and Verb. I've never heard of either, and they're both interesting. Cadquery in particular looks very promising.
Solvespace is a genuine joy to use. If making chamfers, path-based operations, and other such features were better supported, I'd gladly make it my primary CAD package.
It was released as open source pretty recently. I really hope some more development takes off.
> As mentionned there is a python interface for FreeCAD. There is no need to know OpenCascade.
Ha, well someone has to know OpenCASCADE to maintain FreeCAD. And someone has to fix OpenCASCADE when bugs are found, and when it's time to refactor legacy junk...
They're using different representations for solid geometry.
ImplicitCAD is using implicit surfaces / functional representations, while OpenSCAD is using a boundary representation (which is a lot more common in commercial packages).
Implicit surfaces are a very nice representation and make certain operations very easy: booleans become MIN or MAX functions between two functions. However, it becomes much harder to do feature-based operations -- a task like "bevel that edge" is tricky when the edge is an emergent property of the function, rather than as part of the model's explicit representation.
I had some neat tricks that made beveling most edges really easy! (Though, when the didn't work, it was pretty messy.)
Please keep in mind that I abandoned this project 2+ years ago, and started it four years ago. Things have come always since then. OpenSCAD was less mature when I started.
Back in '91, there was a mini putsch by the TAs of Columbia GSAPP's CAD course. The existing course and supporting software were based on computational geometry and a scripting language to go with it. The new regime brought in Maya, et al. I think I was the only one who lamented and found it a step backwards..
Julia Longtin took up working on ImplicitCAD a few months ago. I'm not sure how much she's progressed with it.
Honestly, I no longer believe ImplicitCAD was the right approach to the problem, or that there's even as much of a problem as I originally thought. In particular, the system ImplicitCAD uses to represent objects, a variant of f-rep (http://en.wikipedia.org/wiki/Function_representation) has issues. (f-rep is awesome, I just tried to have my cake and eat it too with some trade offs, and thought I was being really clever! :P)
After ImplicitCAD, I worked with Rob Gilson on a SVG/WebGL constraint-based modelling tool, mech.ly. We got some neat stuff working, but never got to a point where we wanted to release things. I'm pretty persuaded this is the right direction to go.
I learned a lot from both projects. I also matured a lot intellectually. For example, I now review academic literature before diving into solving hard problems! :)