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

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 · 2 months 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 · 2 months 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.

marcosdumay · 2 months ago

IMO, graphical languages should have graphical merge tools. You can't expect the text to be mergeable, but it's not enough reason to refuse file diffing as a concept.

The problem is that graphical tools are usually large, proprietary software made with the explicit purpose of locking people into an entire ecosystem. Diffing is a small specialized operation that enables portability and interoperability between ecosystems, so tool creators actively avoid those.

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.

X-Ryl669 · 2 months 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 · a month 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.

IshKebab · 2 months 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).

loloquwowndueo · 2 months ago

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

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 · 2 months 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)?

aDyslecticCrow · 2 months ago

A gui with tools for openscad that map to real functions would do the trick.

willrshansen · 2 months 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

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

and various efforts/research:

https://www.reddit.com/r/openscad/comments/18wpaoz/investiga...

https://old.reddit.com/r/openscad/comments/1eswe2w/i_made_a_...

Try that latter at:

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).

severak_cz · 2 months 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

[1] - https://github.com/severak/graph-paper/blob/main/doc/file-fo...

An existing project in this space is perhaps:

https://www.godsvg.com/

severak_cz · a month 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.

zxspectrum1982 · 2 months ago

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

Wouldn't it have been git-friendly if .dxf was used as the file format?

stergios · 2 months ago

Me too. I had a secondary monochrome monitor just for the text commands.