PartCAD the first package manager for CAD models
github.com
github.com
Based on what I know so far, it seems that FreeCAD might be finally getting the investment it needs to mature as a real option. There is an organization called Ondsel which is taking on a lot of UI and assembly bench improvements, and I have heard that their preview versions are worth checking out. [2]
Notably, the big question about open source CAD relates to the geometry kernel used. They take decades to produce, and only OpenCASCADE is even remotely mature enough. OpenCASCADE is also somewhat tricky to work with, but it seems to be our only choice. Even if we had millions of dollars of investment in open source CAD it seems unlikely we could do better than OpenCASCADE based on what I have learned.
So my next step when I get some time is to explore how the Ondsel branch of FreeCAD is going and see if I can convince myself this is the path we should all be supporting. I do see no other paths currently, so my hope is that we see FreeCAD mature enough that it becomes usable by professional mechanical engineers.
[1] https://github.com/tlalexander/open-cad-foundation/discussio...
The key point though is that the atomistic modeling is sort-of an add-on to a bog-standard CAD workflow. You still use boolean geometry to produce surface representations, even if those surfaces are discretized crystal structures.
I had intended that once it was up and running I would reach out to some people I know that are interested in a more modern alternative to FreeCAD. Perhaps it would make sense to combine efforts?
But on the topic of CAD/CAM systems, there IS value in having a single workflow tool from design to manufacture. Fusion 360 shows how beneficial it can be to have these different aspects of the workflow be seamlessly integrated.
There’s no justifiable reason to Balkanize all the CAD tools based on function. Users don’t want that.
No one really knows what all of the users want. The commercial tool vendors would tell us that all users want exactly what they sell. My subjective experience suggested a hypothesis that some users might want something different. After two days of PartCAD’s initial revision being out there, it would be fair to say that a lot of users want it. The demand and feedback exceeded all expectations.
As far as storing cad files as you describe, how does that interface with OpenCASCADE file formats? The data storage is related to the CAD kernel I think, so it might be difficult to move to a “store models as code” storage model.
The question of format used to store part info is more relevant to PartCAD. However I do not think PartCAD should prescribe any. PartCAD must be modular and support as many formats as it can. And let the competition decide. Maybe the supported/compatible CAD kernels will contribute to the competition of file formats. Maybe the file format chosen by the community (e.g. for LLM related reasons) will contribute to what CAD tools support. We’ll see in 20 years.
I personally don’t think the community at a whole will gravitate towards anything like OpenCASCADE file formats. I find CadQuery and build123d more promising (no matter what’s under their hood at the moment). I believe it must be human-readable (and, thus, LLM-readable) text. But CadQuery and build123d are not the end of the evolution. I’m sure we will face next technology iterations that are at least more LLM friendly, secure (e.g. to prevent arbitrary I/O from code), and more structured (to help retain the code structure and formatting in the “Load”-“Change”-“Save” cycle).
PartCAD will be there to facilitate modular design and collaboration, and to include as many people and their tools as possible. Not to facilitate any closed formats or tool ecosystems that commercial tool vendors are trying to prescribe to us today, no matter how convincing their arguments sound. Large profits enable generation of very convincing arguments.
No matter how difficult it is going to be to “store models as code”, I personally believe the humanity will succeed at that. However PartCAD will support all common file formats. It currently (2 days after a preview release which somehow went huge) supports CadQuery, build123d and STEP files.
However I would still like to learn how PartCAD (and part-time open source hobbyists behind it, without any funding) can help nonetheless.
I’d really like to learn what are the modelling needs of molecular nanotechnology. Would it need another packaging tool, or just a separate index repository to main another set of parts? Is there any chance you can consider the persistence layer being modular and implemented as code from day one? I would appreciate an opportunity to debate about it with an experienced professional.
Having a standard repository of parts is also critical. We are also considering ways that the interface can be made modular and plugin driven such that importing a part into a workspace also imports widgets for instantiating and interacting with that part.
I want to introduce something like that as an option in PartCAD to see if anyone likes to use it.
Let me know if you want to give PartCAD a try for your model storing/sharing needs. I’ll be happy to customize/extend it for your needs. I always loved chemistry and physics but never had a chance to apply that at work.
They don't have any screenshots on their site.
The website is WIP. You can find screenshots and videos in the blog.
https://ondsel.com/blog/assembly-wb-prerelease/
https://ondsel.com/blog/floating-input-widgets/
https://ondsel.com/blog/ondsel-made-constraining-sketches-fa...
I miss my days working on CAD and this is renewing my excitement for it a bit.
Being able to near simultaneously work on a design in the 2 programs would be lovely.
Unfortunately every successful startup in this space gets bought out by the competition. After buy out, the CAD product gets cut down and real development stops. First they loose their agnostic features (spaceclaim); if they used to be compatible with a whole range of upstream and downstream products, all support for competitors products is dropped. Then they stop the real innovation, to keep the space open for their flagship products (onshape), or give their product a chance to catch up.
There is the concept of CAD "assemblies" which are many individual parts assembled together, which can themselves be members of bigger CAD assemblies until the global product has all subassemblies.
There are then component libraries which have generic CAD files (in the CAD and outside), but they lack the full knowledge of their context - ie you may have a CAD file of a motor, but the CAD file doesn't know it needs a shaft coupling to match its 10mm output shaft diameter, which could in theory be used to pull in dependencies or at least debug your assembly (ie if the coupling attached doesn't have a 10mm ID, error out).
TL;DR: Geometry isn't enough, you need to know the specs and behavior model (like voltage --> torque curve for a motor) to do this, as the total "package" is very dependent on what else is in the model (or should be).
This is actually why we at Volition [2] are building the largest repo of hardware components in the world (26M today) with both CAD and deep spec data, with the goal of eventually powering systems to be able to do stuff like this, and of course as a marketplace we're hoping you'll buy the actual parts from us too :-)
[1] https://www.autodesk.com/solutions/pdm-product-data-manageme...
Another area of current work is in adding UUIDs to a model so that after doing a round trip from STEP into a proprietary CAD system and back to STEP you can work out which bits of the model are new and which not. This could be useful for parts libraries as well.
The one missing thing I've always wanted to see in FreeCAD is something where you draw a circle on a face as an anchor point (the same way that the hole operation works) and put a point on the circle for orientation.
Then you could export the part with it's anchor points embedded in the file, or import a part with it's anchor point fitted on an existing point (With whatever offset, inversion, etc you want).
Would this be suitable for creating this kind of system?
I really like using BOSL2, and so when I publish my scads for friends, right now I just include the copy of BOSL I'm using (I forked it the one time I needed to add a custom patch) as a git submodule [1]
build123d is an open source parametric 2D and 3D CAD tool in Python that succeeds cadquery, and instead of jQuery/pyquery-like method chaining has `with:` context managers. https://build123d.readthedocs.io/en/latest/
bd-warehouse is a parametric parts library: https://bd-warehouse.readthedocs.io/en/latest/ :
> [...] With just a few lines of code, you can create parametric parts that are easily reviewable and version controlled using tools like git and GitHub. Documentation can be automatically generated from the source code of your designs, similar to the documentation you’re currently reading. Additionally, comprehensive test suites can automatically validate parts, ensuring that no flaws are introduced during their lifecycle.
> The benefits of adopting a full software development pipeline are numerous and extend beyond the scope of this text. ; git w/ tests and CI/CD
Ideas for open source (parametric) parts libraries:
- [ ] Dimensional lumber (1x4, 2x4, 2x10) and e.g. HempWood would be a great addition to a parts library.
- [ ] ldraw LEGO unofficial parts catalog: "LDraw.org Parts Update 2023-06" https://library.ldraw.org/updates?latest
- [ ] MicroBit
- [ ] RaspberryPi
- [ ] GlTF: "Google Earth 3D Models Now Available as Open Standard (GlTF)" (2023) ; land, buildings: https://news.ycombinator.com/item?id=35896176
- [ ] GlTF: planes: https://news.ycombinator.com/item?id=38268003 , trains: https://www.google.com/search?q=gltf+trains
- [ ] Humans with splines: https://github.com/killop/anything_about_game#humanstage , https://github.com/daz3d/DazToBlender ; Daz2Blender a few open source meshes
FWIW Conda-forge has signatures and build with clang in CI according to feedstock conda recipes (which have a meta.yml and optionally build.sh and/or build.bat, and a URL to watch for upstream changes).
https://SLSA.dev supports https://sigstore.dev artifact signatures.
Docker containers are ~= OCI containers which are stored in OCI container image repositories; which can host other artifacts with content signatures too.