10 ms·

Proposal: GUI-first, text-based mechanical CAD inspired by software engineering

29 points by thinkmachyx 1y ago

Most mechanical CAD tools (SolidWorks, Fusion, FreeCAD) still lock all modeling into opaque binary files. That makes it hard to track changes, collaborate with Git, or automate builds. I’ve written a proposal for an alternative paradigm: - GUI-first, like KiCad - visual modeling is the default - Text-based source files (YAML/JSON) — readable, diffable, Git-friendly - Separation of source and result - .step, .stl and previews are built artifacts - Parametric logic is explicit - slot width = tab width + clearance Works with Git, CI, or scripting — no more PDM lock-in The proposal is called SplitCAD, and it's just a concept for now — not a working tool. But I’d love to hear from anyone frustrated by the limitations of current mechanical CAD. GitHub: https://github.com/yuanxun-yx/SplitCAD

ddingus 1y ago
I live seeing efforts like this. But I am just going to put this here so the general thoughts incorporate a fundamental problem before significant labor investments go too far: What is a probable, viable, possible answer to the geometry kernel problem? Parasolid, arguably the leader and generally most capable geometry kernel we have today, is or at least I can't see past... ...is just not something easily duplicated. There are a bazillion man months of time in that body of code. And those are hard hours! For those unfamiliar, the geometry kernel is the piece that resolves geometry cases to make operations possible. Imagine a cylinder and rectangle. Now imagine they have some common volume. They intersect, in other words. Put a fillet on one edge to blend the edge. How many literal edge and corner cases can you come up with? There are way more than you think! Now multiply that tiny problem space with all the geometry used every day. And then multiple that time again by what it takes to make it robust. And the whole thing, as it stand today is not even multi-threaded! Any CAD that we expect to see even moderate general use in a professional sense, needs this piece. How do we, meaning anyone interested in CAD this way, get past this? I wish there were some OSS type license for Parasolid. It could be treated like the Linux kernel. Whatever replaces Parasolid and friends, should be treated like the Linux kernel. The closest we have is Open Cascade. Sorry. I do not want to piss on a good vision. But this has to be said. Peace and good luck! I used voice input on this. Pleqse forgive typos.
- thinkmachyx 1y ago
  Thanks a lot for the thoughtful and respectful reply! I really appreciate that you raising the engine issue without dismissing the whole idea. Although building such engine requires tons of work, but the engine we’re having is indeed a bit of old. Except for the problems I mentioned, you also mentioned they’re still single threaded. That’s why I think it’s still worth building a new one, especially when there’s no good open sourced one currently. I’m a big supporter of open source. If we have something like that in the future, we should of course make it open source like Linux kernel and allow everyone to enjoy the benefit of it.
  - ddingus 1y ago
    Me too, and you are quite welcome! CAD is close to my heart. I jumped in during the 80's as a high schooler running on an Apple 2! Even back then, limited 8 bit CAD could do a lot. And it was one application that helped me see the future! Product design was gonna change as manufacturing already was and the people who knew CAD were gonna be there. Now here we are, and the CAD companies own design and manufacturing. I had a flash of an idea this morning reading your comment: Perhaps we could license Parasolid for a year, or maybe we try what tomfoolery I am about to put here with Open Cascade. Maybe an AI model of some kind can get us a leg up? Going back to the fillet example I put here earlier, I want to share a bit of backstory... I was at SDRC, who had built out a fantastic concurrent engineering and analysis system called I-DEAS. I loved that CAD software and was an applications engineer and trainer on it. Taught many groups of engineers how CAD works, and I got to do that on a system that had collaboration built in from the beginning! Fully revision controlled concurrent engineering and analysis. Fun stuff. But it died. My years of skills gone. Kernel could not keep up. So I moved all that onto what is NX today and many of the best parts of the software I loved ended up being implemented because some mergers resulted in the same smart people being product managers! I am particularly redeemed! And therein lies the lesson of the geometry kernel. You build your true skill on Parasolid systems or risk seeing them lying dormant, cast aside. The kernel upon which I-DEAS was built was written in Fortran 90. Beautiful software too. It offered capabilities well ahead of Parasolid in some ways, but consistently failed on some common geometry cases that come up rather frequently. Things tangent to things, touching a a point was a big one. One thing I taught was overbuild or underbuild. Rather than draw a rectangle tangent to a circle to prepare for an extrude, place that end of the rectangle inside the circle and let a boolean operator sort out the two resulting solids. So yeah, build it kind of wrong so the kernel can build solids. Messy. :) I was in a room talking to the people who do fillers. Edge blend to some of us. We talked about my fillet gauntlet. It was a collection of geometry cases that fillet operations failed to complete. Parasolid could always resolve more of them, and it did that with fairly sloppy tolerances. The SDRC kernel was catching up each rev, but the trend line looked like a decade of analysis of the successful resolutions, and coding for those, wash, rinse repeat a lot. I wonder if it might be possible to generate geometry cases using parameters such that whole problem spaces could or can be created. Have good kernels solve and train an AI on all that to see what it may then solve differently? Maybe man years boils down to compute/watt hours?
jqpabc123 1y ago
https://en.wikipedia.org/wiki/Open_Design_Alliance https://en.wikipedia.org/wiki/Open_Design_Alliance
loloquwowndueo 1y ago
Sounds like a gui editor for openscad would be just the thing for this, right?
- aDyslecticCrow 1y ago
  A gui with tools for openscad that map to real functions would do the trick.
- bluGill 1y ago
  Unlikely - a GUI editor is likely to restructure a file on what looks like a trivial change and thus the result cannot be merged.
  - WillAdams 1y ago
    Why not a GUI editor which instantiates dimensions/coordinates, allowing the user to name/identify them (and then change their values either by changing the associated value or dragging the associated graphical element)?
    - bluGill 1y ago
      Where does it put each dimension/coordinate? So long as there is anything that could go in more than one place the GUI can rearrange a file. If the place is specified exactly then a minor change will change the sorting.
      - WillAdams 1y ago
        I suggested a list/pane at one corner for the actual list --- agree the UI is difficult and that there needs to be a way to set/adjust the association (see discussion on the PythonSCAD Google Group).
IshKebab 1y ago
I don't think this will ever really work well. CAD is just too visual. You're never going to be able to meaningfully diff/merge anything but the most trivial changes. Code-based CAD is fine for things that are highly regular like fasteners, springs, etc. You're never going to design a motorbike or a chainsaw using OpenSCAD though (at least not if you aren't masochistic).
jpm_sd 1y ago
I don't think this proposal addresses the most important problems in mechanical CAD. Have a look at Dune3D: https://dune3d.org/ https://dune3d.org/ https://docs.dune3d.org/en/latest/why-another-3d-cad.html https://docs.dune3d.org/en/latest/why-another-3d-cad.html
alsko 1y ago
I think Solvespace is pretty close? https://solvespace.com https://solvespace.com
zxspectrum1982 1y ago
Other than git-friendly, this is how I remember AutoCAD 10 from ancient times.
- stergios 1y ago
  Me too. I had a secondary monochrome monitor just for the text commands.
- WillAdams 1y ago
  Wouldn't it have been git-friendly if .dxf was used as the file format?
X-Ryl669 1y ago
FreeCAD files are zip file containing XML documents. There's nothing binary in them, you can modify them by hand if you want. The main issue being that the format itself isn't standardized, so it's continuously evolving, it can't be used as an inter-exchange format. Notice that the last standard revision for STEP files does contains some tools for saving the parametric functions in the file (so the STEP boundary surface description isn't static anymore but can be parametric too). It's not made to save all the possibilities of a huge CAD toolkit, but if such a toolkit wanted to, it could map the functions in the file to its own parametric function and allow skipping a lot of work for recreating the part.
- thinkmachyx 1y ago
  Thanks for mentioning that. I’ve tried to use git with freecad’s format before. The main idea of my proposal is to provide a source/result separation workflow, like code compilation. This gives user clean content to save to the repo.
WillAdams 1y ago
In what way does LibreCAD writing out .dxfs, or Solvespace or BRL-CAD having a human-readable file format option developed not suit your needs? That said, I believe this would be helped immensely by an overview of CAD --- fortunately, one was published a while back, and dragged back from 404-ness by one CAD vendor: https://www.shapr3d.com/history-of-cad/introduction https://www.shapr3d.com/history-of-cad/introduction a reading of that to understand the overall context would probably provide a solid foundation for your efforts. There has been some recent discussion of making OpenSCAD and derivatives thereof more interactive: https://groups.google.com/g/pythonscad/c/a-FVSiRnzhw https://groups.google.com/g/pythonscad/c/a-FVSiRnzhw and various efforts/research: https://www.reddit.com/r/openscad/comments/18wpaoz/investigating_new_interactive_features_in_openscad/ https://www.reddit.com/r/openscad/comments/18wpaoz/investiga... https://old.reddit.com/r/openscad/comments/1eswe2w/i_made_a_visual_editor_for_openscad_with/ https://old.reddit.com/r/openscad/comments/1eswe2w/i_made_a_... Try that latter at: https://scriptcad.com/paulftw/2.0-demo https://scriptcad.com/paulftw/2.0-demo Agree w/ @jpm_sd that Dune 3D is well worth looking at (it's the only interactive 3D CAD where I was actually able to make it through the tutorial).
bluGill 1y ago
That won't help. I've worked with graphical programming languages before. They work well enough, but in every case I've seen the files saved are not merge-able. Even code generation tools a trivial change will sometimes result in saved files that are almost entirely. Even with text based coding, sometimes you have to make major changes to a file and you tell everyone else on the project don't touch that file since their changes will not merge - the difference is because you are working with the text you know this will happen. What you want is something that allows more than one person to work on a project. Programming started with file locks - you can divide a large project into pieces (parts, sub assemblies...) and then lock those pieces. I think that is done by the better CADs already, if not it is easy and you should apply that. Eventually we figured out how to create merge tools - break the program up into lines, and if a line is changed by only one person apply the change, otherwise make sometime redo that line manually. Until you figure out how to merge graphical drawings you are stuck. Making the file next based isn't going to fix anything because the tools will sometimes need to restructure the file based on what seems like a trivial change.
- rjsw 1y ago
  There is current work in STEP AP242 to annotate parts of a design with UUIDs to make it easier to work out if elements of a saved file are new or modifications of a pre-existing one.
  - bluGill 1y ago
    UUIDs don't tell you that because when does changing a part make it a new part and thus a new UUID? Unless the users is naming all parts - but that isn't what UUIDs normally are and opens a different set of problems. The problem is hard. I wish those working on it luck, but I don't have high confidence that it is solvable.
    - rjsw 1y ago
      There will be an algorithm defined for CAD systems to follow on when to keep or replace a UUID.
- 1y ago
trumpeta 1y ago
Have a look at https://github.com/hannobraun/fornjot https://github.com/hannobraun/fornjot
severak_cz 1y ago
I am already working on something similar yet much smaller - simple, easy to use 2D CAD for hobbyists, maps and geometric art. I have working prototype implemented in lua (Love2D) [0] and barebones text based file format[1]. Curently I am experimenting with drawing things in DeltaCAD (another easy to use CAD - unfortunately abandonware now), converting it to my format (via DXF export) and displaying it with javascript. I want to reimplement second version in javascript to be able to run it in browser and use better GUI components than those which I tried to implement myself. [0] - https://github.com/severak/graph-paper https://github.com/severak/graph-paper [1] - https://github.com/severak/graph-paper/blob/main/doc/file-format.md https://github.com/severak/graph-paper/blob/main/doc/file-fo...
- WillAdams 1y ago
  An existing project in this space is perhaps: https://www.godsvg.com/ https://www.godsvg.com/
  - severak_cz 1y ago
    It looks interesting and I see use cases for this but my tool is (and will be something little different) - it's more visual drawing tool (with exact dimensions) and human readable file format is more byproduct than not.
willrshansen 1y ago
I got into FreeCAD's python interface, and then Cadquery for 3d printing a few years back, and I think you've got about 70% of the solution. Things you've got right: - Human-readable text file is source of truth - GUI editing is first-class, because it's easier to work on (most of the time) Features your proposed solution is missing that I want: - Full power of an established programming language. Yaml or json won't cut it. - Code and GUI on equal footing. Edit in GUI -> see generated code. Edit in code -> see result on model. The main problem with Cadquery is that it's entirely code-first, and you lose out on the intuitiveness of GUI editing One of the less obvious things I really like about dealing with code cad is that feature selection can be based on intent. Like "upper-rightmost feature" rather than "feature closest to this coordinate I just clicked". There's got to be a good way to incorporate this aspect into the "edit in GUI -> code is generated" step (without just requiring manual code editing), but I'm not good enough at UX immediately see it.
therouwboat 1y ago
Code review seem unnecessary, since nobody cares how you made something as long as it is correct. (Measure model, measure finished part) I sometimes modify models in mastercam when designer is away. Technical drawing comes with list of changes and more important projects have approval processes.

29 points by thinkmachyx 1y ago

ddingus 1y ago

I live seeing efforts like this. But I am just going to put this here so the general thoughts incorporate a fundamental problem before significant labor investments go too far: What is a probable, viable, possible answer to the geometry kernel problem? Parasolid, arguably the leader and generally most capable geometry kernel we have today, is or at least I can't see past... ...is just not something easily duplicated. There are a bazillion man months of time in that body of code. And those are hard hours! For those unfamiliar, the geometry kernel is the piece that resolves geometry cases to make operations possible. Imagine a cylinder and rectangle. Now imagine they have some common volume. They intersect, in other words. Put a fillet on one edge to blend the edge. How many literal edge and corner cases can you come up with? There are way more than you think! Now multiply that tiny problem space with all the geometry used every day. And then multiple that time again by what it takes to make it robust. And the whole thing, as it stand today is not even multi-threaded! Any CAD that we expect to see even moderate general use in a professional sense, needs this piece. How do we, meaning anyone interested in CAD this way, get past this? I wish there were some OSS type license for Parasolid. It could be treated like the Linux kernel. Whatever replaces Parasolid and friends, should be treated like the Linux kernel. The closest we have is Open Cascade. Sorry. I do not want to piss on a good vision. But this has to be said. Peace and good luck! I used voice input on this. Pleqse forgive typos.

thinkmachyx 1y ago
Thanks a lot for the thoughtful and respectful reply! I really appreciate that you raising the engine issue without dismissing the whole idea. Although building such engine requires tons of work, but the engine we’re having is indeed a bit of old. Except for the problems I mentioned, you also mentioned they’re still single threaded. That’s why I think it’s still worth building a new one, especially when there’s no good open sourced one currently. I’m a big supporter of open source. If we have something like that in the future, we should of course make it open source like Linux kernel and allow everyone to enjoy the benefit of it.
- ddingus 1y ago
  Me too, and you are quite welcome! CAD is close to my heart. I jumped in during the 80's as a high schooler running on an Apple 2! Even back then, limited 8 bit CAD could do a lot. And it was one application that helped me see the future! Product design was gonna change as manufacturing already was and the people who knew CAD were gonna be there. Now here we are, and the CAD companies own design and manufacturing. I had a flash of an idea this morning reading your comment: Perhaps we could license Parasolid for a year, or maybe we try what tomfoolery I am about to put here with Open Cascade. Maybe an AI model of some kind can get us a leg up? Going back to the fillet example I put here earlier, I want to share a bit of backstory... I was at SDRC, who had built out a fantastic concurrent engineering and analysis system called I-DEAS. I loved that CAD software and was an applications engineer and trainer on it. Taught many groups of engineers how CAD works, and I got to do that on a system that had collaboration built in from the beginning! Fully revision controlled concurrent engineering and analysis. Fun stuff. But it died. My years of skills gone. Kernel could not keep up. So I moved all that onto what is NX today and many of the best parts of the software I loved ended up being implemented because some mergers resulted in the same smart people being product managers! I am particularly redeemed! And therein lies the lesson of the geometry kernel. You build your true skill on Parasolid systems or risk seeing them lying dormant, cast aside. The kernel upon which I-DEAS was built was written in Fortran 90. Beautiful software too. It offered capabilities well ahead of Parasolid in some ways, but consistently failed on some common geometry cases that come up rather frequently. Things tangent to things, touching a a point was a big one. One thing I taught was overbuild or underbuild. Rather than draw a rectangle tangent to a circle to prepare for an extrude, place that end of the rectangle inside the circle and let a boolean operator sort out the two resulting solids. So yeah, build it kind of wrong so the kernel can build solids. Messy. :) I was in a room talking to the people who do fillers. Edge blend to some of us. We talked about my fillet gauntlet. It was a collection of geometry cases that fillet operations failed to complete. Parasolid could always resolve more of them, and it did that with fairly sloppy tolerances. The SDRC kernel was catching up each rev, but the trend line looked like a decade of analysis of the successful resolutions, and coding for those, wash, rinse repeat a lot. I wonder if it might be possible to generate geometry cases using parameters such that whole problem spaces could or can be created. Have good kernels solve and train an AI on all that to see what it may then solve differently? Maybe man years boils down to compute/watt hours?

jqpabc123 1y ago

https://en.wikipedia.org/wiki/Open_Design_Alliance https://en.wikipedia.org/wiki/Open_Design_Alliance

loloquwowndueo 1y ago

Sounds like a gui editor for openscad would be just the thing for this, right?

aDyslecticCrow 1y ago
A gui with tools for openscad that map to real functions would do the trick.
bluGill 1y ago
Unlikely - a GUI editor is likely to restructure a file on what looks like a trivial change and thus the result cannot be merged.
- WillAdams 1y ago
  Why not a GUI editor which instantiates dimensions/coordinates, allowing the user to name/identify them (and then change their values either by changing the associated value or dragging the associated graphical element)?
  - bluGill 1y ago
    Where does it put each dimension/coordinate? So long as there is anything that could go in more than one place the GUI can rearrange a file. If the place is specified exactly then a minor change will change the sorting.
    - WillAdams 1y ago
      I suggested a list/pane at one corner for the actual list --- agree the UI is difficult and that there needs to be a way to set/adjust the association (see discussion on the PythonSCAD Google Group).

IshKebab 1y ago

I don't think this will ever really work well. CAD is just too visual. You're never going to be able to meaningfully diff/merge anything but the most trivial changes. Code-based CAD is fine for things that are highly regular like fasteners, springs, etc. You're never going to design a motorbike or a chainsaw using OpenSCAD though (at least not if you aren't masochistic).

jpm_sd 1y ago

I don't think this proposal addresses the most important problems in mechanical CAD. Have a look at Dune3D: https://dune3d.org/ https://dune3d.org/ https://docs.dune3d.org/en/latest/why-another-3d-cad.html https://docs.dune3d.org/en/latest/why-another-3d-cad.html

alsko 1y ago

I think Solvespace is pretty close? https://solvespace.com https://solvespace.com

zxspectrum1982 1y ago

Other than git-friendly, this is how I remember AutoCAD 10 from ancient times.

stergios 1y ago
Me too. I had a secondary monochrome monitor just for the text commands.
WillAdams 1y ago
Wouldn't it have been git-friendly if .dxf was used as the file format?

X-Ryl669 1y ago

FreeCAD files are zip file containing XML documents. There's nothing binary in them, you can modify them by hand if you want. The main issue being that the format itself isn't standardized, so it's continuously evolving, it can't be used as an inter-exchange format. Notice that the last standard revision for STEP files does contains some tools for saving the parametric functions in the file (so the STEP boundary surface description isn't static anymore but can be parametric too). It's not made to save all the possibilities of a huge CAD toolkit, but if such a toolkit wanted to, it could map the functions in the file to its own parametric function and allow skipping a lot of work for recreating the part.

thinkmachyx 1y ago
Thanks for mentioning that. I’ve tried to use git with freecad’s format before. The main idea of my proposal is to provide a source/result separation workflow, like code compilation. This gives user clean content to save to the repo.

WillAdams 1y ago

In what way does LibreCAD writing out .dxfs, or Solvespace or BRL-CAD having a human-readable file format option developed not suit your needs? That said, I believe this would be helped immensely by an overview of CAD --- fortunately, one was published a while back, and dragged back from 404-ness by one CAD vendor: https://www.shapr3d.com/history-of-cad/introduction https://www.shapr3d.com/history-of-cad/introduction a reading of that to understand the overall context would probably provide a solid foundation for your efforts. There has been some recent discussion of making OpenSCAD and derivatives thereof more interactive: https://groups.google.com/g/pythonscad/c/a-FVSiRnzhw https://groups.google.com/g/pythonscad/c/a-FVSiRnzhw and various efforts/research: https://www.reddit.com/r/openscad/comments/18wpaoz/investigating_new_interactive_features_in_openscad/ https://www.reddit.com/r/openscad/comments/18wpaoz/investiga... https://old.reddit.com/r/openscad/comments/1eswe2w/i_made_a_visual_editor_for_openscad_with/ https://old.reddit.com/r/openscad/comments/1eswe2w/i_made_a_... Try that latter at: https://scriptcad.com/paulftw/2.0-demo https://scriptcad.com/paulftw/2.0-demo Agree w/ @jpm_sd that Dune 3D is well worth looking at (it's the only interactive 3D CAD where I was actually able to make it through the tutorial).

bluGill 1y ago

That won't help. I've worked with graphical programming languages before. They work well enough, but in every case I've seen the files saved are not merge-able. Even code generation tools a trivial change will sometimes result in saved files that are almost entirely. Even with text based coding, sometimes you have to make major changes to a file and you tell everyone else on the project don't touch that file since their changes will not merge - the difference is because you are working with the text you know this will happen. What you want is something that allows more than one person to work on a project. Programming started with file locks - you can divide a large project into pieces (parts, sub assemblies...) and then lock those pieces. I think that is done by the better CADs already, if not it is easy and you should apply that. Eventually we figured out how to create merge tools - break the program up into lines, and if a line is changed by only one person apply the change, otherwise make sometime redo that line manually. Until you figure out how to merge graphical drawings you are stuck. Making the file next based isn't going to fix anything because the tools will sometimes need to restructure the file based on what seems like a trivial change.

rjsw 1y ago
There is current work in STEP AP242 to annotate parts of a design with UUIDs to make it easier to work out if elements of a saved file are new or modifications of a pre-existing one.
- bluGill 1y ago
  UUIDs don't tell you that because when does changing a part make it a new part and thus a new UUID? Unless the users is naming all parts - but that isn't what UUIDs normally are and opens a different set of problems. The problem is hard. I wish those working on it luck, but I don't have high confidence that it is solvable.
  - rjsw 1y ago
    There will be an algorithm defined for CAD systems to follow on when to keep or replace a UUID.
1y ago

trumpeta 1y ago

Have a look at https://github.com/hannobraun/fornjot https://github.com/hannobraun/fornjot

severak_cz 1y ago

I am already working on something similar yet much smaller - simple, easy to use 2D CAD for hobbyists, maps and geometric art. I have working prototype implemented in lua (Love2D) [0] and barebones text based file format[1]. Curently I am experimenting with drawing things in DeltaCAD (another easy to use CAD - unfortunately abandonware now), converting it to my format (via DXF export) and displaying it with javascript. I want to reimplement second version in javascript to be able to run it in browser and use better GUI components than those which I tried to implement myself. [0] - https://github.com/severak/graph-paper https://github.com/severak/graph-paper [1] - https://github.com/severak/graph-paper/blob/main/doc/file-format.md https://github.com/severak/graph-paper/blob/main/doc/file-fo...

WillAdams 1y ago
An existing project in this space is perhaps: https://www.godsvg.com/ https://www.godsvg.com/
- severak_cz 1y ago
  It looks interesting and I see use cases for this but my tool is (and will be something little different) - it's more visual drawing tool (with exact dimensions) and human readable file format is more byproduct than not.

willrshansen 1y ago

I got into FreeCAD's python interface, and then Cadquery for 3d printing a few years back, and I think you've got about 70% of the solution. Things you've got right: - Human-readable text file is source of truth - GUI editing is first-class, because it's easier to work on (most of the time) Features your proposed solution is missing that I want: - Full power of an established programming language. Yaml or json won't cut it. - Code and GUI on equal footing. Edit in GUI -> see generated code. Edit in code -> see result on model. The main problem with Cadquery is that it's entirely code-first, and you lose out on the intuitiveness of GUI editing One of the less obvious things I really like about dealing with code cad is that feature selection can be based on intent. Like "upper-rightmost feature" rather than "feature closest to this coordinate I just clicked". There's got to be a good way to incorporate this aspect into the "edit in GUI -> code is generated" step (without just requiring manual code editing), but I'm not good enough at UX immediately see it.

therouwboat 1y ago

Code review seem unnecessary, since nobody cares how you made something as long as it is correct. (Measure model, measure finished part) I sometimes modify models in mastercam when designer is away. Technical drawing comes with list of changes and more important projects have approval processes.