Jonathan Westhues released SolveSpace, his parametric 2D/3D CAD software, under terms of GPLv3.
The project was started in 2008 and is based on a an earlier application called SketchFlat which was a two-dimensional technical drawing program. SolveSpace goes a lot further and focuses on accomplishing tasks like modeling 2D and 3D parts, preparing models for 3D printing and generating CAM data, simulating planar or spatial linkages etc.
There are quite a few amazing things about the application: from a tiny executable file that would fit a floppy disk, to feature set that includes advanced geometry constraints solver, as well as an output to STL, DXF, PDF, and SVG.
SolveSpace is currently built just for Windows, but it does run under WINE, as demonstrated in this silent video where Christopher Madsen demonstrates using SolveSpace to draw a Sonex flap detent.
Despite of somewhat unusual user interface the application seems rather easy to grok. As one of its users mentioned on CNC zone , even his son was able to pick up basics very fast:
There’s a little bit of a learning curve, but my 11 year-old was able to start using it effectively after about 30 minutes of watching the tutorials. He certainly wasn’t an expert (neither am I), but he got enough to use start making things.
We asked Jonathan a few questions about the background of the project, his reasons to liberate source code, and further development plans.
What kind of a problem were you trying to solve when you started working on SketchFlat, later replaced by SolveSpace?
I developed these programs (a) for my own use, and (b) out of dissatisfaction with the constraint solver used in most commercial CAD software. In most commercial solvers, a user who partially constraints a sketch and then drags a point will get a poor solution—the solver may satisfy constraints by moving point A through a very large distance, when it could have satisfied them by moving point B through a much smaller distance.
SolveSpace improves that behavior, and also offers various exotic constraints (in particular, relating to entities in 3d, not just projected into some workplane) that aren’t readily available elsewhere.
SketchFlat was my first attempt at a geometric constraint solver. SolveSpace shares many of its basic architectural decisions (in particular, the Newton’s method, and the use of a symbolic algebra system to write our equations), but is sufficiently better to make SketchFlat obsolete by any standard now.
What is your own typical use for the application? Judging by the feature set, I’d say, personal manufacturing or prototyping?
My mechanical design work tends to be fairly straightforward. I do stuff like test fixtures for electronics, or microwave components (antennas, shields, filters, …), or machines with a few axes of motion. So that’s a fairly good fit for SolveSpace, with simple surfaces and not too many parts.
Most of my parts are made by some kind of rapid prototyping process, like laser-cut plastic or Polyjet from a service bureau, or CNC machining (like from Firstcut, or from a smaller shop with less automated CAM work).
I also use SolveSpace to solve geometry problems not relating to parts that I’ll draw in 3d CAD. It’s a quick way to calculate an area to estimate a capacitance, for example, or to map dimensions in a datasheet to the (x, y) coordinates of the points (for entry into a non-parametric CAD system), or to prepare a human-readable sketch.
What was the reason for publishing the source code of both SolveSpace and SketchFlat?
I see opportunities (and get requests) for a lot of additional work within SolveSpace, which is unfortunately beyond my ability to implement alone, even before considering any other demands on my time. The basic structure of the code seems fairly good now, and I’m hopeful that other developers will be able to extend, port, and otherwise improve the program.
Beyond that, I’m unaware of any free geometric constraint solver with performance comparable to that of SolveSpace. That’s a useful feature, and one that’s historically been available only in high-end mechanical software; so by releasing that solver under the GPL, I hope to decrease the barrier to implementing that elsewhere, for example in artist-oriented tools or in EDA software.
In the past you discussed the licensing of your constraint solver for use in Grasshopper by McNeel. My understanding is that you didn’t reach consensus on terms of licensing. How much did this story affect your decision to release the source code, if at all?
I’ve had various discussions with them since. I’m fairly confident that I can provide McNeel with a license to the solver on terms they’ll find acceptable. That’s a big project for them, though; it’s not just a question of integrating the library, but of fundamentally changing the way a lot of things work in the greater program to make good use of the constraints. So I understand completely their reluctance to take that plunge, though I of course would still be glad for them to do so.
All that is independent of my decision to release SolveSpace under the GPL. And of course, nothing in that release stops me from licensing the solver as it stands now under other terms, since I’m the sole author.
Do you have any particular plans for further SolveSpace development?
A lot of people have been asking about Linux support. The program runs correctly under WINE now, but a real native port would be nicer. At this point, from my discussions post-release, I believe it’s likely that another developer will take that work on relatively soon, perhaps for Mac OS too with a portable GUI toolkit.
The constraint solver should perform as well as or better than commercial alternatives for most sketches, but I still want to make certain improvements. In particular, we rely heavily on a numerical solver now; I believe that opportunities exist to take advantage of the symbolic structure of the problem, to solve faster and with better convergence, and perhaps to provide certain feedback to the user.
The biggest practical limitation within SolveSpace right now is its NURBS Booleans. They’re rather slow, and limited to a narrow class of input surfaces (i.e., surfaces of extrusion or revolution), and not too robust even then. These are of less personal interest, but it’s an obvious area for enhancement.
Do you think it would make sense to move the solver code to Boost or lib2geom—to improve shareability?
The solver isn’t a natural fit for any library that I’m aware of. In lib2geom, for example, I might be able to use their floating point vector stuff in a few places, but most of the real work happens in the symbolic algebra system.
So I don’t think much real benefit would arise from that move; even if the solver were developed in the same repository as such a library, it wouldn’t share much code. The solver, as implemented now, is also rather tightly coupled to the greater application. That interface could be formalized, but at the cost of quite a lot more lines of code.
The exception I would see to that is the NURBS (strictly, piecewise rational polynomial; so the same thing expressed a bit differently) curve and surface operations, like to compute intersections and Booleans on shells and such. That’s a well-defined problem, with a simple interface to the rest of the program and a lot of complexity to implement it.
I’m unaware of any good free libraries of that form, though. A few people do robust 2D operations, but the shells add a lot of nasty special cases.
Just to start, for example, the intersection of two NURBS surfaces isn’t generally a NURBS curve; so any shell of NURBS surfaces trimmed by NURBS curves must, in general, either leak, or contain surfaces trimmed by curves that don’t lie exactly in that surface. So everything’s approximate, and it gets messy fast.
I’d be interested to hear from anyone doing (or interested in doing) work of this form.
Are you up to managing SolveSpace as a free software project? That is, reviewing incoming patches and suchlike? Or is it more like “you are free to do whatever you like with this provided you stick to GPL”?
My current intent is to review incoming changes, with a fairly liberal acceptance policy. I’ve tried keeping tight control of projects before (like for LDmicro), and I’ve tried abandonment to the community (like for my proxmark3), so I was thinking that I’d try something in between this time.