> This is the main difference... and the reason why there is so little crossover

It's definitely _a_ reason, but not the only reason, and I personally wouldn't consider it the main reason. I used to be a mechanical engineer and now I work in software. Every day that I fire up solidworks for personal projects, I wish for exactly the kind of tool you described in GP. But the thing is, I wouldn't say that the choice of modeling kernel technology is the crucial point here. Frankly I think that the most fundamental problem is a complete lack of understanding between the two worlds.

In the MechE world, once you start talking about fabrication, manufacturing drawings and tolerances are really your bread and butter. This is such a profoundly basic thing for mechanical engineering, and yet completely absent from the kinds of modeling tools you see in video games and VFX. This is just a tiny example, but the real point, again, is a lack of shared understanding between the two domains. I mean... how would you go about capturing _design intent_ in one of these script-based tools? Even for something as trivial as drilling a hole in a rectangle, how am I going to know which corner to use for locating the hole?

As a MechE, your "source code" isn't the geometry you design, it's the history tree that lead to that design. It's the constraints and relations that you used to build the whole of the part. And I don't think that most people that work on software projects in this space have an appreciation for what that really means.

Don't get me wrong, CAD kernels are a hot mess. At every step, it's like you're basing the next function's source code on the compiled binary of everything you've written up to that point. It makes absolutely no sense. But it is, as of today, the closest analogue to how most MechE's I've talked to actually think about building parts. But I think that starts to get at the fundamental disconnect: people with a software background look at that and think, "surely something like CSG would be better; it makes things so much easier to compose". Whereas people with a MechE background look at these kinds of tools and think "ain't nobody got time for that." They're both right and they're both wrong.

It's said that breps vs. meshes in 3D is like vector vs. raster in 2D.

> Meshes are not CAD data...

Meshes clearly are CAD data just they may be less useful in certain fields. CAD is broader than whatever form of engineering you practice

Does Grasshopper in Rhino count?

Grasshopper can indeed drive NURBS surfaces in Rhino if I remember correctly, yes. But it suffers from the same problem I describe initially- you have to start with design from Grasshopper- it is a one-way-flow. There is no way to parametrically model something in Rhino and have it automatically generate a model graph that can then be reused.

This is the main difference between tools like Rhino and the aforementioned parametric modelers (Autodesk Fusion360 is another fully parametric solid modeler that supports a 'tree' build with parameters that can then be changed at will at any time, and the model will rebuild).

What is the end result you want? If you're modeling by hand, why do you want to "program" the model later? What would that look like? What units would you operate on? What would the output be? etc.

An example would be similar to how a catalog / design table is used for generating parts procedurally in software like Catia:

Say you have a CAD model of a special bolt you have made completely from scratch and it is fully parameterized- you can edit the diameter, the shank length, the thread length and pitch, the head size and height, etc. all by changing values in the parameters linked in the design tree. Doing this automatically updates the geometry.

Now say you have a catalog of 1000 sizes of this flavor of bolt. M6 thru M14, different threads, all the dimensions change to very specific standards... and you need to generate files for all those so they can be used by your company in assemblies or sent to others, but individually. Professional tools have ways to take, say, a CSV table of all those numbers and link the CSV to the CAD, and then generate and export STEP files and save them to a disk.

I've done just this example many times over the years in Catia V5. Highly parameterized part catalogs are prevalent in automotive and aerospace companies tied very closely to their CAD and PLM solutions (and thus highly non-portable and very much proprietary...) It would be great if there was some FOSS that was lightweight and similarly capable.

Looking more into it, FreeCAD can actually do something similar, but I don't know if the parameters are accessible to rebuild the models via a Python module outside of the GUI.

> Say you have a CAD model of a special bolt you have made completely from scratch and it is fully parameterized

But what does it mean to parameterize something you made from scratch? Either you built it as a parameterized model, or you didn't. If I understand, you'd basically like to design a model manually, and magically get it parameterized? That's probably possible to design a AI model that attempts to do that.

Every modern CAD tool like those commercial ones I have mentioned automatically track the paramaters as you build a model from scratch. They are parametric models by default. At any point you can go back and edit a number in the tree and the model will attempt to update as if you have used that value in the beginning. It's hard to explain this if you are not familiar with how those programs work.

I'm not talking magic here. What I'm saying is, I'd like the ability to read the model file as text outside the CAD package, and edit and compile (update) exportables in a scripting languge. Again, what I am saying is actually already the way many tools, like Catia and NX, etc work... but they lack an external API/callable module in an external language (Catia can be scripted with VB script, blegh.) And nothing that is FOSS.