A New Era for Mechanical CAD
queue.acm.org
queue.acm.org
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.
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.
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).
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.
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.
Even something as fundamental as line segment intersection doesn't seem to have any good parallel algorithms.
>> 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.
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.
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.
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.
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.
The main alternatives are IGES and STEP files. STEP is an ISO standard CAD interchange format, and the most modern of the bunch.
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.
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.
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.
- 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.
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 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 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.
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 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.
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
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.
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.
Also, good to see you John :-)
Whoa! Whoa! Whoa! No Helix geometry in this office, are you trying to get us all killed?!
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.
EDIT: that is, saving all user inputs used to generate the binary files in a text format.
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.
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.
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...
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.
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.
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.
Oh, and you need to implement this for every file type.
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.
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.
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.)
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.
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.
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.
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.
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.)
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
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).
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 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.
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).
http://www.scorchworks.com/Blog/openscad-modules-for-automat...
It also fails miserably as soon as the geometry you're trying to fillet is complicated.
Unless you plan to do so from the very start and design your entire part accordingly.
- 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.
This brings in for free a ton of very nice things:
- version control
- collaborative editing
- parametric modeling
- object optimization- 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:
https://medium.com/embedded-ventures/mechanical-cad-yesterda...