Idea: __cad_interface__, a general protocol for Python CAD systems

[DavidMStraub]

Hi all,

I had an idea that I'd like your feedback on.

One of the things I do apart from CAD is mapping, using Python GIS tools like GeoPandas or Fiona. I noticed that there is an ecosystem of tools that can exchange geographical data seamlessly since they have agreed on a standardized interface, __geo_interface__, that their data structures expose. Obviously, my thought was: wouldn't it be cool to have such a seamless exchange of CAD models?

Of course, CAD models are much more complicated than geospatial data, but we already have different layers of data exchange like in-memory OCCT shapes, .brep, or .step.

So, I built a prototype of a spec for __cad_interface__, a protocol that libraries like CadQuery could adopt, that would allow seamless exchange of shapes and assemblies between different Python CAD libraries and tools – an ecosystem that is growing fast (this looks interesting for example).

You can find the proposal here: https://github.com/DavidMStraub/cad-interface

The repo contains monkey patches of CadQuery and build123d for illustration, and example notebooks including an example meshing a CadQuery assembly with gmsh, using a different OCCT build.

It's important to me to state what this is not supposed to be:

• Only a conversion between build123d and CadQuery – see "why not .wrapped?"
• A library that CadQuery and others should depend on
• The final location of a spec

I'm really curious what you think about this. Obviously, I would be happy to contribute the code for this eventually, if it's considered useful.

[adam-urbanczyk]

To be super honest, IDK what would be the added value for CQ. I'd rather spent my limited time on implementing new features and not maintaining compatibility with other projects. We have STEP import/export, what would this add?

[DavidMStraub]

Fair question! The convenience is mostly for users, not for maintainers. From a user perspective:

• No messing around with files, zero glue code
• No file IO, everything stays in memory
• Consumers and producers know what the best (fastest and least lossy) common format is, so e.g. build123d would use the OCP objects directly, gmsh would use brep, only codes based on other kernels would use STEP

My train of thought on this was started when I created a small convenience tool to allow students to easily get CAD models (build123d or cq) meshed with gmsh, and it turned out to be very painful (OCCT version mismatches, different .brep formats, and all that).

For CadQuery, in my view it would be perfectly sufficient in an early phase to just be a "producer", which would more or less be this chunk of code; I'd vouch to contribute and maintain it.

Obviously, all of this doesn't make sense unless >1 projects think this is useful. And I haven't asked anyone else yet.

[adam-urbanczyk]

That is not the point of your request, but issues with OCCT version mismatch suggests that you did not used a sane package ecosystem. Did you consider using conda-forge with your favorite package manager (conda, pixi, (micro)mamba)?

If you commit to maintaining, we can consider. IDK if assy interop or interop with other kernels is realistic.

NB: there was once an idea to make mesher-agnostic meshing interface for CQ, but it is parked for now.

Also this might be interesting for you: https://github.com/CadQuery/assembly-mesh-plugin

[DavidMStraub]

Concerning packaging, you're right, this specific problem appears when using pip to install wheels and packages bundle their own OCCT. That has downsides, but also some advantages, say one package moves to OCCT 8 and the other is still on 7 but I want to use the latest version of both.

[DavidMStraub]

Concerning the interface: thanks for considering it, I'll fan out and gather some feedback from other projects and get back here if it gets some traction.

[adam-urbanczyk]

AFAIK using wheels linking to different version to a library won't in general work in the same process unless special precautions are taken. See e.g. CoolProp/CoolProp#2512 (comment). Also, GMSH is packaged on conda-forge and on OCCT8 already and the migrations to newer OCCT versions are usually fast. Anyways, enough off-topic...