Hacker News new | past | comments | ask | show | jobs | submit login
A New Era for Mechanical CAD (acm.org)
126 points by jasim 5 months ago | hide | past | favorite | 107 comments

>> Most parametric CAD operations are single-threaded; however, the open-source project SolveSpace [solvespace.com], which uses NURBS (nonuniform rational basis splines), has some parallel operations.

Current Solvespace maintainer here if you have questions on that. I did most of the work on making NURBS boolean operations use OpenMP for parallel operations. The code is highly functional, so that was mostly adding the appropriate #pragmas, but some things needed fixes, and some required tricky critical sections.


3.0 is out, congrats on the release! I'd built that myself to try it out earlier this year, IIRC the previous stable build was 5 years old. Guessing I didn't have the OpenMP version from my build, so this should be a performance boost.

Unrelated to parallelism, is there a way to lock the vertical axis for orbit, what blender calls "turntable" style rather than "trackball"? Coming from an AutoCAD and Blender background, I'm a lot more comfortable in that mode.

>> Guessing I didn't have the OpenMP version from my build, so this should be a performance boost.

The performance in 3.0 is dramatically better, not just from the OpenMP. We still have a lot of code that doesn't scale well because it's O(n^2) but what is there is much faster. There's also a post-3.0 improvement already in one slow area, and we hope to get Eigen in there to speed up the constraint solver.

>> is there a way to lock the vertical axis for orbit, what blender calls "turntable" style rather than "trackball"?

Oh man I forget. You might want to comment on this pull request: https://github.com/solvespace/solvespace/pull/956

We obviously can't implement every option under the sun, but I think turntable is more asked for than the one implemented in the PR (which I haven't even had time to test properly).

Never mind, I found it! Turntable already exists, it's in the second block of checkboxes on the config screen, between "enable automatic line constraints" and "edit newly added dimensions."

I think that issue is looking for a toggle like Apple's "natural scroll direction" where it's a question of whether you want the metaphor that pushing your scroll wheel is pushing the content up and down or moving the scroll bar grip which makes the content go the opposite direction.

Hey, I just downloaded 3.0 and, wow, the performance is really fantastic! It's a really welcome change - I was starting to dread making complex models because I'd have to make them with another program, at which point I would be continually frustrated by the other program's inferior UI.

Anyway, solvespace is the first CAD program where I've actually enjoyed myself while designing things, rather than just viewing it as necessary work for a project. So, thanks for all the great work you guys are doing, it's much appreciated.

How are you handling the fact that it seems like none of the computational geometry algorithms parallelize?

Even something as fundamental as line segment intersection doesn't seem to have any good parallel algorithms.

>> How are you handling the fact that it seems like none of the computational geometry algorithms parallelize?

>> Even something as fundamental as line segment intersection doesn't seem to have any good parallel algorithms.

We don't need parallel algorithms at the lowest level. A NURBS model consists of a large number of surfaces and trim curves. You'll be hard pressed to find "standard" algorithms for NURBS boolean operations, but jwesthues (creator of solvespace) chose a fairly good process for handling them. To combine 2 NURBS shells we compute intersections of each curve from A against each surface from B as one step in the process. Finding all those intersections can be done in parallel. Each step in the boolean process can similarly be done in parallel at either the curve or surface level.

We also do triangle mesh creation in parallel now, as each surface patch is triangulated separately it was easy to run them in parallel. This was a huge win for things like a torus where there are many surface patches with compound curvature and lots of triangles.

We had one nasty bug where dragging some geometry around would start to distort a couple surfaces. Turns out there is a function to intersect a ray with a NURBS surface that recursively subdivides the surface. The recursive subdivision was altering the weights of the original surface control points and then putting them back. Running that on multiple threads at once could lead to corruption. I don't recall how I tracked that down, but the fix was to simply make a copy of the surface and discard it when done rather than changing the original. This whole ray-surface intersection thing is another example of an algorithm that doesn't really benefit from parallelization for a single call, but there's no reason we can't go up a level and have multiple threads calling that function with different ray/surface combination.

I was really pleased that most of the complicated code in Solvespace is written in a functional style - meaning it doesn't mutate data. Another part of the NURBS boolean process is to create a BSP-tree for each surface, which is then discarded after the operation is complete. Once again, that can be done in parallel over all the surfaces even though it'd be hard to create a single BSP-tree using parallel code.

I love Solvespace. It really changed the way that I perceive CAD when I got into designing 3d printed parts that needed to fit together.

>> I love Solvespace. It really changed the way that I perceive CAD when I got into designing 3d printed parts that needed to fit together.

The next version should be able to link STL files into your models - complete with boolean operations. The linking code exists on one of my branches, but I still need to work out which verticies get point entities created for building geometry on. I know how to do it, just not efficiently yet.

I admittedly know very little about CAD internals, but I design models for 3D printing and STL seems so ... awful ... yet as the lowest common denominator it has a tremendous support everywhere. What are the alternatives? I assume Solvespace uses something better natively, but you still have to export to STL to go through a slicer to get G code? It really seems like a better job could be done without both STL and G code.

> What are the alternatives?

The main alternatives are IGES and STEP files. STEP is an ISO standard CAD interchange format, and the most modern of the bunch.

STEP is a huge standard. Solvespace can export it because it only needs a small portion of the standard. I'm guessing the slicers used for 3D printing have avoided it due to the complexity, but it would be nice to hand them actual curved surfaces and spit out G-code with arcs if not splines.

It seems to me that slicers must replicate a lot of tools and information that CAD tools already have; driving this directly from the CAD database could avoid the information loss and ugly facets introduced by the export to STL.

Heck, I'd even like to take a step further and eliminate G-code which has a lot of limitations, added extrinsic complexity, and doesn't allow for feedback.

What do you think of non-history based CADs using direct constraint solving? Can they even hypothetically match history based ones on functionality?

As I understand history is a "hack" for low capabilities of 3D constraint solvers, which are limited in shapes they can express by what the solver can express.

>> What do you think of non-history based CADs using direct constraint solving? Can they even hypothetically match history based ones on functionality?

I may not be the right one to ask. jwesthues wrote solvespace originally for his own reasons, I think partly to experiment with better ways of solving constrained sketches particularly during user interactions (dragging).

I'm not sure about the history aspect of these programs. The group structure of a solvespace model is not really as necessary as it may seem. I don't think the capabilities of the constraint solver are even close to being fully utilized.

>> As I understand history is a "hack" for low capabilities of 3D constraint solvers, which are limited in shapes they can express by what the solver can express.

We could in theory apply the constraint solver to any set of points and lines - Vertexes and skeletal structures in Blender for example. It gets tricky to make predefined geometry with only some specific degrees of freedom. You're basically using automatic constraints to define the non-movable parts of an object, but leaving out just the right constraints to allow the user to move/stretch/bend the thing in an intuitive way. Again, we're just scratching the surface now with extrude/revolve/helix operations.

Extrude-along a path is a long sought feature that I plan to implement. It will be like chaining multiple extrude or revolve segments (with uniform cross section) in a single group. The solver will be maintaining that cross section while allowing the user to drag an awful lot of stuff around. Most other CAD has the feature but they seem to want you to define a path ahead of time and then just create the geometry to follow it. We can do better.

Once thing I've always wanted in Solvespace is the ability to type up a file using a description like to OpenSCAD, then open that file in Solvespace --- is that on the radar?

>> Once thing I've always wanted in Solvespace is the ability to type up a file using a description like to OpenSCAD, then open that file in Solvespace --- is that on the radar?

Not really? The thought went though my head, but I've never looked at OpenSCAD close enough to even say how complex their interpreter is. Then there's the question of how much of that could reasonably be created with the NURBS subsystem in Solvespace.

IF you're OK with the STL output from OpenSCAD, our next release should include the ability to link those files into an assembly. Maybe that will help. It won't solve the problem of people wanting to write scripts and output STEP files.

The problem is, STL won't work for me --- I've been working on wood joinery, and I keep coming up with designs which between their geometry, and the tooling which should be used to cut them out, 3D CAM tools simply won't cut them out w/ the accuracy necessary for a good fit.

Philosophical question but why do we still use nurbs instead of, for example, subdivision surfaces? Is that mostly because users want to export to nurbs after editing?

>> Philosophical question but why do we still use nurbs instead of, for example, subdivision surfaces?

Subdivision surfaces are a generalization of B-spline surfaces that predate them. History aside, sub-d surfaces can not exactly represent circles, cylinders, or torri. When you're designing real objects - rotating machines in particular - you want perfect circles. Round wheels and bearings. Trimmed NURBS (which result from itersections) are also easy to model features like chamfers, where again subdivision surfaces may fall down. Pixars creased subdivision surfaces probably do a bit better for things like chamfers. Nurbs are a better fit for modeling the kind of surfaces created by traditional machining operations. You wanna make movies? Use subdivision surfaces. Wanna design mechanical devices? Use NURBS.

I'd like to see something better, but the industry isn't likely to change. Open source is IMHO the way to go with any fundamentally new representation.

Any thoughts/recommendations on how to get started in the software development side of things coming from a mechanical engineering background?

>> Any thoughts/recommendations on how to get started in the software development side of things coming from a mechanical engineering background?

That's an interesting question. I know a guy who was (is) an ME. He worked in the auto industry calibrating ABS and traction control systems. That's an area where torques/forces/dynamics are required, but no real software background. He would either come up with new ideas, or try to track down bugs in the algorithms - he had access to the code since we were all at the same company. He moved on to fixing problems (the software team had a lot of things to do so weren't as responsive as he wanted?) and even implementing features. When I met him he was a solid embedded software engineer and I was a bit surprised to hear his path to get there.

So I guess find some niche that has overlap between what you know and what you want to do. Then gradually leverage that as you improve (and prove to others) your capability in the "other" area. How you find that overlap is up to you. For one guy it meant calibrating stability control systems was the start.

I've come to think the most flexible place to branch out from is product testing or manufacturing. You can learn a lot about a lot of different aspects of things there. Just don't let yourself stagnate.

I have a BS & MS in Mechanical Engineering, but I have spent the last 15+ years in Software. I first got my start learning to code on the side, but eventually made my way into Product Management. I would look for software engineering companies in the ME space think CAD, PLM, FEA type software companies and look for jobs in PM or even customer success and pre-sales engineering. Some of the best PM's that I've hired come from the customer success groups.

Robotics. I work at a robotics company. A lot of our folks are Mech E turned SWE. I myself am a SWE, but the amount of knowledge of forces, torque, controls, etc. I have had to pick up is huge.

Read up on Walter Bright

He’s around here somewhere … oh, there he is!


There are a few problems with making new CAD, especially open source:

- CAD math is hard and severely limits contributors. Unlike many open source projects, you need a pretty big core team to make something worth using. FreeCAD/OpenCASCADE, etc. have remained hobbyist CAD, where we've seen the success of open source in software.

- Another core problem is that MechE's can't easily edit the tool they're using when they run into a bug/feature they want to work on, unlike open source software where the users can more easily be contributors.

- High switching costs: there are four big CAD companies: Dassault, Autodesk, Siemens, PTC, and once a company commits to one ecosystem, it's very hard to change. Ex: Boeing isn't putting the CAD for the 787 in OnShape - ever. There also aren't that many new huge hardware companies, meaning that folks like OnShape get SMEs, but virtually all enterprise is taken. This has essentially led to an oligopoly in mechanical CAD, and slow pace of innovation in the space. I believe CAD tools have 50x less $ investment (including big companies) than software dev tools.

- InterOp is also hard, file formats are complex/proprietary/inconsistently implemented. There are kernels like ParaSolid with import/export/conversion systems, but they're not trustworthy enough to really put the 787 into new CAD without so many bugs that you'd lose a year fixing them and likely be paranoid forever wondering if you got them all.

- Folks like nTopology have done a good job side stepping these concerns as they built a CAD tool that does a specific function (generative design) that can't be done in traditional CAD kernels and can be sold for very high value-add situations - ie designs that need very high performance from the uniquely optimized geometries that they're able to generate, and export files that play nice with regular CAD. This means Boeing can have some fancy nTopology-created parts in their planes without having to blow up their CAD/PLM systems.

CAD math is hard and severely limits contributors.

Yes. Autodesk used to have a staff geometer, and probably still does. Constructive solid geometry is hard, because you can use complex forms to cut into complex forms, and have to represent the result.

A typical exercise in a good CSG program is to model a bolt. You start with a cylinder. Then you draw and dimension a thread cross section. Then you extrude the thread cross section along a spiral, subtracting that from the cylinder, to cut the threads. Then, at the end of the bolt, you cut a chamfer by extruding a triangle around a circle and subtracting that from the bolt. The CAD program must correctly and precisely describe what happens to the thread as it is cut by the chamfer. You can zoom way in and take a close look. You might have a design constraint that the chamfered thread can never be thinner than some specified width, to avoid bits of metal flaking off as the bolt is tightened.

Most of the free CAD programs bail before they deal with problems that hard.

I'm not certain about that very last constraint (the chamfered thread not being thinner than X) but other than that, precisely what you describe is a workflow I've been following for the past couple of months in FreeCAD: not for metal threads, for plastic, printed ones, but the workflow is the same. They added helical cuts and additions in the most recent version, but even before that you could get the same effect with a helical path (so a few more steps for the same result, essentially).

Oh, good, FreeCAD is catching up. It's been a few years since I tried it.

Yeah. 0.19.2 is good, at least for the stuff I need; 0.20 is shaping up to be full of good stuff too (and hopefully won't take as long as the 0.18->0.19 cycle did). On-topic, though, if you're doing threads and gears, it gets slow quickly. It doesn't take very much for me to start needing to switch parts of the design off for the UI to stay usable because recalculations kick in that I know shouldn't be needed, but the dependency tree isn't detailed enough to filter out.

it's been able to do everything you just described for at least 5 years (with the exception of that last constraint, I think).

Not only that, but that is the workflow if you were making a custom bolt on the lathe. Machining experience is invaluable when designing mechanical parts.

>>Then you extrude the thread cross section along a spiral, subtracting that from the cylinder, to cut the threads.

Whoa! Whoa! Whoa! No Helix geometry in this office, are you trying to get us all killed?!

And the BREP math is even worse... And the implementations are pretty dirty too

Also, good to see you John :-)

This hits the nail on the head. All of the CAD kernels basically date from the 1980s. The mathematics involved in extending them is not widely taught, and while this knowledge still lives in books, it is not finding its way into minds.

Another blocker is that CAD is a relatively small part of mechanical engineering. Pretty much all software engineers use version control, but depending on subfield/company, maybe 20-50% of mechanical engineers will use CAD significantly. Mostly the design guys. The engineers in test, analysis, materials will barely touch it.

Though interestingly if you look at the numbers there are more CAD seats than MechE's, so I'm guessing a lot of other engineers, technicians, etc. are using it.

Test folks have totally different systems like LabView for data logging and analysis that don't really talk to the simulation tools, CAD, etc. - very fragmented dev tools.

I really like Bret Victor's "Seeing Spaces" vision for a more integrated hardware dev environment where it integrated software and workshop into an real-world "dev environment": http://worrydream.com/SeeingSpaces/

I can confirm that. While it's true that the MechE's at my workplace all have CAD seats, we also have a number of floating seats that get used by a variety of people. There are things you can do in the CAD tool, but not in the free "viewer" tool, so we provide CAD seats to our manufacturing engineers, who also use CAD to design things like jigs and fixtures.

I believe it actually takes a bigger and more hierarchical engineering organization to have MechE's who are not busy at the CAD terminal a lot of the time.

In addition, our machinist has a CAD seat, the machine shops that we use all have CAD seats. And while optical engineering is a small field, most OE's have CAD skills.

Peter of Edge Precision recently released a video on the CAD and CAM he does in a typical machining job[1]. The video of him turning the part[2] is also good.

Machinists running any sort of CNC machine will need both CAD & CAM seats.

[1] https://www.youtube.com/watch?v=yPtoxEgzrhE [2] https://www.youtube.com/watch?v=3-jT3HrSHjE

I had a SW license for sure when I was a stress analyst . I'd use it to look at a part to take a dimension, and maybe once a month use it to make a drawing from an existing part that would go into a report. I never modeled in it. By far the most important software for me was Excel though.

>more CAD seats than MechE's

Unless you're an EI fresh out of college, engineers probably won't spend many billable hours in CAD. Your time is too valuable, and most contract rates won't be high enough to have engineers doing drafting.

(EI = Engineer Intern, for getting your 4 years of experience for becoming a PE, which is similar to a Medical Resident for physicians.)

We have a pool of draftsman that handle most of the actual drafting, at the direction of PEs, which let's the PEs focus on actual design and other things that can be billed at higher rates.

But since CAD is still installed on the PE's computers, they're probably still counted as users, even if it's mostly for review, printing, minor redlines, etc.

Hint: Don’t let a CAD designer give you a model that is not fully resolved (i.e. constrained.)

Sometimes closed source software gets open sourced for business reasons, and backed by a big consortium, rather than being written from the ground up by hobbyists.

I wonder if big aerospace and defense companies like Boeing, and automakers, and heavy industry, and so on, might decide it's in their interests to collectively buy and open-source an existing commercial CAD package rather than risk being held hostage to the vendors that gatekeep their engineering.

Dassault Systems was spun off from the european fighter plane manufacturer with the same name. They bought up solidworks and Catia and runs as a standalone business.


Yea, I believe most (all?) CAD systems are spin outs from industrial programs. Pierre Bezier (of the curve) was actually an automotive engineer at Renault as they were trying to better define shapes.

here's a short but fun bit with bezier unisurf system


BRL-CAD was created by the US Army Research Laboratory (then the Ballistic Research Laboratory, hence 'BRL') and was released in 1984, and became free software in 2004.


BRL-CAD is fascinating in how different it is from ux point of view. It is almost like a window to alternative universe where old fashioned UNIX and CLI won with interesting mix of graphics.

> I wonder if big aerospace and defense companies like Boeing, and automakers, and heavy industry, and so on, might decide it's in their interests to collectively buy and open-source an existing commercial CAD package rather than risk being held hostage to the vendors that gatekeep their engineering.

I doubt it. The vendor/client relationship is a lot more collaborative and symbiotic than most people would think. I'm not sure about Boeing specifically, but I do know that their competitors work very closely with their CAD vendors. Part of the contracted agreement is to have a software team on the vendor side work with the engineering team on the design side to produce essentially a custom fork of the software.

On one hand, yeah, the CAD vendor could play hardball and hold a client hostage. But on the other hand, there are only so many Boeings out there. So if you push them away, that revenue will be hard to replace.

Most likely situation is the one that's played out a few times before: acquire your vendor.

I think the companies want an independent for-profit maintaining the business because they don't trust the dynamics of open source / non-profit to actually provide good products/services. Which I think is actually a reasonable argument given the issues in my OP.

I wish the FTC, etc. tweaked how the CAD industry was handled to increase competition / decreasing switching costs, etc. This relates to them preventing people from being in their equivalent of the "app store" which Dassault has been particularly aggressive about.

I wonder how much it would cost to open source AutoCAD or Solidworks lol. Blender was only $100k.

I'm surprised the article doesn't mention Rhino/Grasshopper, considering how prevalent it is.

3D modelling !== solid modelling.

Because they are programs used to do industrial design and general aesthetic 3D modeling, they aren't CAD programs.

A b-rep is a b-rep. It's not Solidworks, but it's also not trying to be. It'll spit out a STEP file or a set of plans like anything else. Consider a second look.

There's a whole subquestion the article mentioned mostly as an aside: version control systems don't facilitate multi-way merging of binary/complex file formats. I don't know that anybody has developed a good solution to this (that scales to large numbers of different formats), and "just use a text file format" doesn't really work for complex models where changes don't appear like minimal diffs.

I invested fully in FreeCAD, it does support pointers and instances for many ops, but the reality is that you have to instantiate all the instances in 3-space if you want to do complex geometry conflict checking.

I'm a mechanical engineer.

The version control software that we use (I'm most familiar with Windchill, and just a wee bit familiar with SolidWorks PDM) is dumb. It's a B2B market with fat margins that is ripe to be disrupted.

Typically in Windchill, a part has a part number, and can be checked out and checked in, iterated, and revised, in operations that are non-intuitive and difficult to reverse. If you ever wanted to build an assembly using older versions of current parts, the process to figure it out might take 100 clicks, or might not be possible depending on how your system administrator set things up.

Merging (in the style of git) is generally a completely foreign concept, and engineers generally avoid collaborating on a single part or assembly file for that reason. Dividing up the interior of a vehicle's engine bay, for example, is best done as separate assembly files that are only later brought together as a parent assembly. Communicating about the volumetric boundaries of these assemblies is complicated.

I'm often aware that I could be more productive and adaptable using a git repo (or similar) containing my parts, assemblies, and drawings than I currently am with Windchill's specialized system. Haven't ever seen it in the wild, though.

I've used Windchill extensively and I've set up a Vault instance (the Autodesk equivalent). I completely agree with what you are saying. At most companies, there is a "Emperor's Clothes" scenario where even the expert users and administrators have no idea what's going on under the hood, or how to execute advanced operations. (granted, Git has the same issue sometimes, let's face it) To make matters worse, Windchill has quite possibly the worst UI of any software I use --- first off, it runs in an instance of Internet Explorer embedded in the Creo CAD package. Few icons are labeled, and the UI is not discoverable at all. Google is often no help, since it is relatively niche BTB software. Doing what the parent suggests, using old versions of parts in new assemblies, is only reliable when saving the old versions out as a "dumb solid" like a STEP and re-importing them into Windchill. Part of the issue is that version control and databased file systems as a mental model do not align very well with how the human brain operates. The hierarchical structure rules the day in the end, because it aligns well with how we think.

I met the founder of Grabcad when he made a trip to Shenzhen China around 2012. I took away that he was trying to build the "github for CAD". We tried the Grabcad system out in our office for a while and it was useful but didn't really meet that vision. I haven't tried it since the company was acquired by Stratasys in like 2014 but a quick login looks like it hasn't changed much.

I deployed PDM at my company. It works fine, and even for people who don’t really know what version control is.

Multiple downsides though… cost, only really wants Solidworks files (although does handle everything as binaries), but the worst and most unforgivable issue…

They keep full versions of every file, at every check in… forever.

If you have a 500MB file, change the color, and check it it, you now have 1GB of file space taken up, with no clear way to cut that down! Coupled with the fact that deleted files don’t delete until someone manually does a destroy operation, it’s a storage space murderer.

You can setup a cold storage scheme or enable vault compression for old versions to save space on your archive server to save space.

There was something that was a super pain in the ass about their cold storage solution, but I haven’t ever seen a vault compression. I wonder if it’s new or I just missed it.

Completely agree, there is a lot of opportunity here. I have extensive experience using Solidworks, its PDM and another vault software (Adept, don't get me started). Collaboration on reasonably complex assemblies is rarely worth the effort, it's easier to communicate in other channels and link up at the end. File versioning is needlessly complicated and often frustrating, especially for less tech-savvy designers.

I’ve spent thousands of hours on pro|e and sw. the past few years it’s been mostly onshape. Their implementation for version control is the best I’ve seen, and is continuously improving. Def check it out if you haven’t

I'm not sure what method it's using (if any) but Perforce is the prevalent version control system for most industries with large files. I think most programmers have heard about it from it's integration with the Unreal engine but as a hardware guy I know it's used at a lot of semiconductor companies for things like managing versions of the various CAD required (layout, schematic, HDL, etc.)

It has the great advantage of being a company you can pay to fix problems. I don't know who you can pay to implement some custom git system for handling huge files and repos. GitHub/Atlassian/GitLab are not interested in working on your company specific workflow.

This might be possible if the binary format encodes a sequence / tree of CSG operations. A binary blob might be difficult to merge / conflict-resolve for humans.

Even if you had that representation, resolving merge conflicts would be a huge headache. Imagine resolving code conflicts by resolving things at the AST level.

Forget CAD, we don't even have a good way to version control images, something programmers work with every day, besides "use Git LFS and pretend an image is just a pointer".

edit: just saw GumTree mentioned above. Guess I have something to check out...

Of course not possible with images as a binary blob but it could be possible with a series of operations on a (vector) image ("event log").

>Imagine resolving code conflicts by resolving things at the AST level.

This sounds extremely nice actually. The more semantically aware the version control system is, the more likely it can gracefully handle merge conflicts. A textual diff is a very low level transformation primitive; composing them doesn't guarantee very much at the higher level.

Coming at it from the other end, you may or may not already be aware that one of realthunder's branches (can't remember which right now but probably LinkStage3 since that's where the action seems to be) lets you save the .FCstd file as a directory so that you can commit it to git. I've not tried it myself yet to see how useful the diffs are, but it's not unfeasible to think there's some value there.

GumTree does AST level diffing, hypothetically one could build VCS on top of that. That would work for binary files as long as they are parseable to some sort of sensible AST.


I worked on this type of problem in the context of structured data in a version managed database, and you need more than just an AST.

These types of systems have lots of extra cross dependencies and complexities so to resolve changes you need enough to effectively replay changes from one branch onto another. You’ll find points where this will not work and at that point you need to be able to present the user with self consistent alternatives to choose between, and a way to safely save and recover the other data while they do this. That goes through the entire application stack and UI.

The stuff I worked on all worked, but every application and customer that built on our core needed to develop custom rules for their work flows, and I’m not sure many ever did.

> you need to be able to present the user with self consistent alternatives to choose between

That seems very high bar to aim for compared to git (and other traditional VCS), which do not ensure that the end-result of a merge (or rebase) is in any way sensible.

It is a high bar, but consider what happens when you get an inconstant merge. With text representing a program you get a compiler or interpreter error and can view and edit the text to fix things up. With something like a CAD drawing you may not be able to open the file, or it might be almost incomprehensible to the user (if you broke coordinate transforms or accidentally combined sub assemblies or something). If you are really unlucky you end up with something that looks okay but subtly breaks the application in a way you will not notice for a long time, and then it’s going to be hard to fix.

Oh, and you need to implement this for every file type.

Lots of programs have an "undo" feature, perhaps the history of this could be saved along with the files.

EDIT: that is, saving all user inputs used to generate the binary files in a text format.

This article smells like a software person looking at CAD from a technical standpoint without significant experience with complex product development or production. The reality is, the processes around CAD (namely R&D iteration, tooling production, fabrication and assembly process iteration, management thereof) cost far more than CAD does.

In short: who cares if something is single threaded when you are paying literally 100 times that person's salary per day in idle equipment, space and so forth? It's a rounding error. Buy a faster machine.

The industry broadly agrees with the author that greater integration between factory floor equipment and digital models is desirable and/or coming (Industry 4.0, etc.) however the complexity of this space is staggering.

To briefly explain: every fabrication process (or 'unit' operation in process management terms) has theoretical abilities in terms of part generation, modification or assembly but these are limited by equipment at hand (speeds, tolerances, tooling compatibility, maximum and minimum dimensions, etc.), time, knowledge/training, material and other inputs. Furthermore, equipment-specific maintenance schedules, power requirements, failure modes, consumable replacements and environmental parameters cannot be ignored. And that's before you have to look at aggregate tolerances, lasting effects of these processes on part materials, variations caused due to environmental conditions, temporary storage and movement of parts and inventory during production, secondary processes, human error, regulatory ingress, supply chain complexities, etc.

Typical products may include somewhere between 5-100 unit operations to produce, some can take 1000s or 10s of 1000s, especially if you include electronics fabrication, packaging and testing. Individual tooling assemblies often take months to produce, even years if multiple iterations are required. It's not something you use a single program to plan for. You need an experienced team, time, money and a plethora of systems.

I was going to write a similar comment. The CAD part of mechanical engineering is usually a really small part of the overall process. Furthermore, there are really good tools in existing CAD to act as "pointers", they just aren't necessarily how a computer scientist would invent them. They are usually called configurations and indeed they can be automated. Normally "32 instances of a part" would not need to be manually updated either, one update would do it. Finally, it's naive to think simulation is analogous to CI. In some cases it can be pretty close to automated, but normally there is a lot of expertise and interpretation required to get useful results and there are a lot of steps between or instead of simply inputting geometry to the simulation program.

It's true that interoperability and version control should be improved, but configuration control is more important and engineers like the author are the ones that try to parameterize too much and cause hidden mistakes and extra work for everyone else.

OpenSCAD exists, is perfectly usable, is very cool, and stores CAD models 'as code' which is git-friendly. Professionals don't use it. I like it, but I would never standardize on it at work. I'm sure a more point-and-click front-end is certainly possible, but that nobody has tried something quite so obvious probably speaks to its incompatibility with use common use cases. I use Autodesk software daily, and merely representing 3D objects is a very small part of the utility it provides. The software is undoubtedly an unstable mess, but feature parity with Revit or just Fusion 360 is far beyond a pizza-box team of 'disruptors'. There is also a culture of professionalism and practicality in AEC that I don't see folks used to coastal VC/startup playgrounds doing well in.

I also find it pretty hard to take the contents of an article seriously when there's name-dropping of celebrity-developers whose business appears to be self-promotion. "I use vim, btw ;)" really puts the nail in the coffin for me. I'm sure CAD-but-on-electron would look great on a slide deck, though.

OpenSCAD is cool and I do use it when it is the most convenient tool, but I find it to be incredibly slow, and if you don't want the output to be all blocky polygons (which you can only achieve by increasing $fn AFAIK) then it gets even slower.

It also suffers from not having any general-case way to fillet or chamfer edges, which means you have to bear your fillets/chamfers in mind throughout the entire design if you want any (which is why most OpenSCAD designs don't bother).

There is actually a general-purpose way to do fillets in OpenSCAD, using a slightly Rube-Goldberg combination of booleans and minkowski sums. Unfortunately it is, again, far too slow to be usable in 3d at anything like an acceptable resolution. It works great in 2D however.


> it is, again, far too slow

It also fails miserably as soon as the geometry you're trying to fillet is complicated.

It shouldn't? The one bright part of it is it's completely general. I've never known it to fail - although again, it's too slow to be useful in 3d.

It's general if you want an equal fillet on every edge, but it's not "general" in the sense that you can apply fillets and chamfers of different sizes to different edges.

Unless you plan to do so from the very start and design your entire part accordingly.

OpenSCAD is fine so long as:

- the model is describable mathematically - the model description is simple enough that performance isn't an issue - a supported form of output is workable (DXF, SVG using straight lines, STL)

It's not possible to get a nice text file out of it w/o jumping through hoops, doing CAM directly is frowned upon, and quickly brings the program to its knees (just modeling cutting out a hemisphere w/ an endmill resulted in a file which took minutes to render, and left the program barely usable).

Apparently these folks did an article on Medium.com as well:


OpenSCAD is a neat tool, but it has a few huge drawbacks for real world use:

    - a weird domain specific language that only adds a bit of syntactic sugar and is a pain to learn. They would have been *way* better off using Python and extending it.

    - no filet / chamfer tool. No CAD program can be taken seriously unless it has those.

    - the CAD core is (IIRC) CGAL, which only works with polygonal models and is god-awful slow as soon as the model gets complex. For example, Minkowski sums are basically unusable on any real-world model.
What is really neat about OpenSCAD is the notion that a 3D object is basically code.

This brings in for free a ton of very nice things:

    - version control
    - collaborative editing
    - parametric modeling
    - object optimization

As for your first point, this is a pretty clunky workaround, but at least it exists: https://github.com/SolidCode/SolidPython

Or https://libfive.com/, which is less clunky (but no longer OpenSCAD-based).

OpenSCAD is great for distributing singular models intended to be customized but I can't imagine using it for multi-part or really complex models.

I used to use something in school that would auto save versions apparently. I think it was either pro-e or ansys.

I suspect another breakthrough will be of a completely different nature: having the computer reverse engineer voxel or polygon models back into a tree of features (something like solidworks). The user gains much easier editing an object as a series of understandable steps instead of a blob of polygons.

This is a pretty crazy difficult CS problem! There's a bunch of research papers using deep learning to solve this, and it is starting to work, although in very limited domain. (Relatively prismatic objects.)

User of 3D CAD here. The reason this is so hard is that a part's geometry will be governed by a different set of parameters, depending on its function, and the software will not know the function of the part, unless is was written by a domain-specific expert.

I'll give the simple example of a hex-headed nut: how will the software know that the flat-to-flat measurement is critical (since it corresponds to the wrench/spanner needed to drive it) rather than the point-to-point measurement? In less trivial examples, questions like this need to be though out when creating models, and require domain-specific knowledge that a ML model will not have.

This is something I've given some thought to recently. I'm surprised that no CAD software (or at least none that I've used) has a, for lack of better terminology, "functionality markup." There's extensive infrastructure for mating parts in assemblies and validating designs with simulations, you'd think that someone could think up a good way of going in reverse, at least for common use cases. There should be a way to feed in some abstraction of the design requirements and get a design tree that meets those requirements. For example in the case of the hex head nut, there should be a way to describe a wrench as a combination of mates and simulated loads such that a CAD program can figure out that the flat-to-flat measurement on the nut is critical, and I should be able to open up a model of a nut and mark it up in such a way as to communicate "this gets turned by a wrench."

While probably useless for such a trivial case, one can easily imagine a case where multiple very different geometries might be appropriate for a task depending on the value of some other parameters, for example maybe I have a design with everything on one side to make machining easier, but the moment I have to add a feature to the other side it makes sense to switch a bunch of those features to the other side as well.

>having the computer reverse engineer voxel or polygon models back into a tree of features (something like solidworks)

As a ME with extensive CAD experience, there is nothing that annoys me more about the 3D Printing community than the insistence to transmit files in a non-editable format. If the file is released under a license that permits editing, then please provide me a parametric CAD file that I can open and edit in my CAD software of choice.

> This is a pretty crazy difficult CS problem!

I suspect machine learning, and specifically GPT-3 style transformers, is the perfect tool to solve this.

Especially given the fact that you can basically generate an infinite training set automatically using a parametric modeler.

Onshape is briefly mentioned. Yes, it’s online only, but it’s also free if you make your designs public, and as a hobbyist tinkering with 3D printing, I find it a good tradeoff.

The constraint system is elegant but took some learning since there’s a geometric puzzle aspect to it. I find it nice for making simple revisions like changes in dimensions. (For more extensive revising, it seems easier to delete that part of the sketch and redraw it.)

I have been working to script Autodesk Fusion 360 with python recently. Programming against this environment is tough and frustrating. A couple of things I have noticed

1. Using the API is far from intuitive. There are many objects that you have to use from the API that have no named corollary in the UI. I know BReps are a thing (probably faces) but there is no way to name a face in the UI and find that via the debugger. I have to poke and prod to try to create the objects to build the things I want to. 2. Limited documentation. The APIs and object tree are documented, but examples are often limited 3. Poor programming environment. It is nice that there is a debugger mode that works with vscode, but this debugger connection frequently breaks, requiring tabbing back into fusion, restarting the debugger, tabbing back to vs-code, restarting the debugger... 4. Most examples are written by non-programmers. I have seen a couple of examples of object graph printout programs, instead of building up a list of lists or objects, these programs intertwine navigating through the tree with print indentation.

That said, I just found this repo [1] which looks well written.

On the other hand, CAD software is much more complicated than most systems I interact with. CAD platforms are one of the few remaining software systems that are written for experts. Experienced practioners are very productive [2]. So programming these systems will also be complicated.

FWIW I'm trying to template a bunch of part imports and their layouts. I'm surprised that this isn't built into the system. You can edit variables for almost (almost) every input in the system, you can name variables and elevate them to file wide variables - all without touching programming. I wish importing was parameterized such that upon import I got a chance to edit the filewide variables as parameters in the new document.

[1]https://github.com/JesusFreke/fscad/blob/master/src/fscad/fs... [2]https://youtu.be/G3rho-24DWQ?t=184

> Just as I would use Vim for side projects as well as professional jobs, I would expect my CAD tool to work just as well for building a toy for fun as it would for a complex project.

Not picking on the specific editor there, but that's a high skill tool we're talking about which is full of repeated memory effort (or "muscle memory"), with layers in it.

The reference to Jai in this context is probably equivalent, since it is a programmer's tool for a programmer's need to automate/repeat the same operation.

The best thing in this whole article is that as more programmers work on problems which require CAD, the more likely they are to solve the problems they run into, but in ways that works for them directly (think Linus, git and emails).

The second part was always the hardest (the "make") at the toy project level.

In the bay area, the death of TechShop is unfortunate though, where getting a CNC machine time (& my python madness with printf of g-code) meant things went from patterns to real.

Like, I'd love a 3-d equivalent to graphviz's dot for representing a 3-d scene in a minimal way for navigation through it, but not for actual manufacture (though things like SPICE went both ways in the end for me).

So Jessie is looking for people building KittyCAD. I'd rather improve SolveSpace, because this is open source and already operational. Solvespace branded as VsCode with collaboration tools? Ok, why not.

I think OpenMP is back in again, but the database format is important, agreed.

In her vision I miss the importance of CSG, where the brep surfaces are created dynamically. Looks like she thinks the history and construction of the solid can be thrown away, but with thin shells (3d printing!) Lost precision will haunt you. You need CSG. This is not modern, this is antique.

I work with NX and Teamcenter(central data storage amd PLM software) daily and find the single threading during almost all the design work annoying (except for FE, drawings and maybe a few other things). On the other hand the backwards compatibility is exceptional, opening 20 year old models exactly as they are and rendering the drawings exactly as 20y ago is quite useful (using the renderer of the version it was created with, sometimes with the ols bugs too ;) ). Expanding NX with custom features and custom scripts is quite easy (plugs into MS VS). Afaik as i know you could use C, C++, C.net, python or even Vjsual Basic to access/modify the data.

Sorry for the typos; was in a hurry before :/

NXOpen is probably the best thing about Siemens NX and Siemens PLM platform in general. Too bad they completely screwed up the forum

We are talking here about a mature technology. Not a bleeding edge area. Modeling a part, making a drawing of the model, and creating a fabrication strategy and code are all problems solved by multiple competing vendors who interact with customers on a daily basis. It’s sufficiently hard to do WELL that open source, or free solutions are mostly for hobbyists.

There's a difference between well established and mature. I've been using CAD software for nearly two decades and even now hardly a day goes by when I don't curse solidworks for doing something stupid or making something unnecessarily complicated, and it's one of the more user friendly options out there. I think most engineers would describe CAD as slow and tedious, even if they are experienced users. If you look at things like writing or digital art software, experienced users can utilize those to express the ideas in their heads about as quickly and easily as they could with pen and paper, whereas modeling even simple things takes way longer in CAD than a beer-napkin sketch, and there are plenty of cases where I can imagine a geometry but I have no idea how I would model it in CAD. Beyond making things more intuitive, version control is decades behind that of software, constructing parametric models in a way that they don't break immediately with minor changes requires significant skill on the part of the user, task automation is essentially nonexistent, and collaboration tools are a joke. The field is ripe for disruption by whatever clever team figures out a good way to address these many pain points.

I've been trying to build a CAD system, where the node's of a model are stored in a content addressable network, a bit like glTF but with CSG or BREP instead of meshes.

Innovators dilemma. I have worked at Autodesk on a project to do exactly this and seen it happen.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact