This post resonates a lot with me. I've been experimenting with Claude Code to write code that interacts with the SolidWorks SDK. It is both extremely complex (method calls with 15+ bools, doubles, strings; abbreviated parameters; etc) and obscure. It has been like pulling teeth. Claude would hallucinate methods, parameters etc.
I tried using Context7 MCP with the SolidWorks docs but the results were not satisfactory. I ended up crawling SW's documentation in HTML, painstakingly translating it to markdown and organizing it to optimize greppability [1]. I then created a Claude skill to instruct CC to consult the docs before writing code [2]. It is still stubborn and sometimes does not obey my instructions but it did improve the quality of the code. Claude would need 5 to 10 rounds of debugging before getting code to compile. Now it gets it in 1 to 2 rounds.
I've been using zoo and its KCL language with some success for boundary-representation CAD writing. If I understood correctly, µcad serves the same purpose. Comparing code samples between both of them, I personally enjoy KCL's pipelined approach more.
My main beef with zoo is the fact that they are promoting vendor lock-in by forcing users to use their cloud-hosted geometry kernel with absolutely no local alternative. It's not clear to me how µcad solves this problem.
Hm, at least build123d (which I had never heard of, thanks!) can export STEP, which I believe is becoming a necessity if one wants to assemble real-world models with FreeCAD (and nicely also slicers are picking up support to it). I'm on the edge though if I'd really like a proper DSL instead of building it on top of Python, although I can see that too has its benefits (e.g. library access).
Does anyone have idea about the STEP export support status for KCL/µcad? To me it looks like KCL cannot, and I cannot find information on it about µcad. The one tool I'm familiar within this space is OpenSCAD and it cannot. While FreeCAD is able to (sometimes?) convert from STL to STEP, it seems actually working with such models in FreeCAD is quite compute-inefficient.
Converting from STL to STEP is essentially always a case-by-case thing.
If you import, sew, check geometry, refine, etc., you can eliminate unnecessary triangles in planar faces. But you can't magically make a 120-sided-polygon that should be a circle a circle; you're going to have to do that yourself.
And FreeCAD is not the best tool for correcting broken meshes, which are commonplace. MeshLab and the vaguely-on-life-support AutoCAD MeshMixer are better at it.
STEP/IGES is as you say more or less essential if you want to work with code-CAD output in any other serious context. STL is not enough: it is like converting to JPEG in the middle of a photo editing flow, not at the end. It destroys information — in this case geometry.
Yeah I hate messing with STLs for that reason. It's an output format. Similar to when you make an image in Photoshop with a load of layers and then export to jpeg where it's flattened and all the layer info is lost.
Obj is a bit better but for real design modification you kinda need the original file and the program it was designed in. At least in my experience.
I've never come across STEP though, is that a real design parameter preserving file format?
STEP doesn't preserve all of your design intent (sketches etc.) but it does preserve the geometry (edges, vertexes, faces). So it is a lot easier to work with it because it is lossless and precise. Curves are curves, not quantised/faceted.
So in our image processing analogy, it is still in a sense a "flattened" representation of the layers, but it's a vector format. The best way to think of it is broadly like a 3D SVG, I guess.
3D printer slicers (except maybe Cura without a paid add-on) can usually load STEP now, but they are still internally meshing before slicing. I think Orca/Bambu/PrusaSlicer all give you some control over that meshing (they all use OpenCascade to do it, in fact).
In FreeCAD you can do things like defeaturing, so if you have a hole in a rounded plate, you can delete the hole, you can delete corner-rounding. You can also break STEP files down to faces and use the surface/curves tool to work on them, or use them as a BaseFeature for a Part Design Body, etc.
This is a pretty useful video for showing the differences:
If you're talking about CAD in general I can see your point.
For FreeCAD specifically, there looks to be an OpenSCAD import process directly. I don't have experience with how it works, but that may be better than going through STL
I know the process is there, but I really, really doubt it does anything else than just uses OpenSCAD code to render the mesh, as FreeCAD can also deal with meshes. I think it would be pretty unlikely that the FreeCAD devs would have implemented such a rendering system based on OpenSCAD.
From my quick tests, it seems to rebuild the OpenSCAD objects using FreeCAD part workbench primitives.
But I also quite quickly found examples that don't work. I don't know if that's the import not being very good, me finding weird examples, needing to install more libraries, or PEBKAC.
This is nothing new, Microsoft signed an agreement with the French government to build a sovereign cloud called Bleu [1] operated by Orange and Capgemini using Azure and Microsoft 365 technology. The German government did something similar and launched Delos Cloud, operated by SAP and Arvato Systems.
The reasoning is that, with sufficient security, on premise (more or less) cloud technology is not much different in terms of sovereinty from sourcing your hardware from China.
That was such a low blow, given we have stellar companies like OVH that have demonstrated their skills and willingness to bring great hosting, and are fully local.
This was mine, too, until I started regularly using a (university) network where the local resolver resolved example.com to 127.0.0.1. I complained, and was told that RFC2606 gave them license to override it to anything they wanted, and that this behavior would not be changed. Doesn't square with my reading of the RFC, but complaining further wasn't going to achieve anything.
RFC 2606 is a "best current practices" document, which is less stringent than a standard. I'd say it gives them flexibility.
Even updated by RFC 6761, the practices surrounding example.com only go so far as SHOULD and SHOULD NOT.
That said, I think it's a horrible idea to treat example.com differently, but that's just because I can't think of a single reason why you would want to do so. :)
Yikes. We use example.com all the time in my intro to network programming class. HTTPS would get in the way of learning the basics, so I'm glad there are some HTTP options out there still.
(Yeah, they could just run a local one-liner web server, but that's not as fun.)
I don’t miss the seemingly arbitrary restrictions from university IT admins.
A university I attended blocked all BitTorrent traffic at the protocol level. They theoretically allowed exceptions per their policy but when I applied for some bioinformatics images to be allowed they said they would only allow specific files for a 24 hour window. I applied for a file and got no response. I applied for 1000 files and got no response. Then I gave up.
I guess any site that doesn't auto-upgrade would work, but I have a habit of typing out http:// for this site in particular because it doesn't work over https.
example.com hasn’t been HTTP-only for quite some years now. It may still serve the page over HTTP rather than issuing a redirect to HTTPS, but that ain’t HTTP-only. Nor is there any guarantee of them retaining this deviation from accepted best practice.
Oh cool. I worked on the networking layer of the first Kindle iOS (née iPhoneOS) app and that captive portal stuff was a pain in the ass. I would just walk across the street to Tully’s and use their wifi to get that pop up.
I've also had situations where _only_ neverssl.com wouldn't load but other http sites would switch to https with an invalid cert error. It's really weird.
Glad to see another fan. For others, here's the relevant discussion http://n-gate.com/software/2017/07/12/0/ (needs some refreshes, I think the author made the website somewhat inaccessible on purpose)
"We had several million lines of code still to port, so we couldn’t afford to spend days studying the code trying to figure out what obscure floating point rounding error was causing collision detection to fail."
I'd say Ray is right, not lacking the skill, but lacking the time
Raymond's comment about not being able to find the collision code is a bit absurd. I can't recall if Danny or I named the top-level collision detection function, but it was just named 'pb_collide'.
To be fair it's a huge undertaking to port any code of that size to 64 bits, be it fully commented or not. He probably remembers it vaguely and it might be a different function they had problems finding the exact location in the source code.
I'm curious, didn't they just call you or Danny (I believe that's Danny Thorpe, who is currently working for Microsoft) for assistance?
Ray wasn't about only to find the collision, but porting or not the game, meaning going through entire uncommented code of the game. And he said they made the executive decision not to port it.
I tried using Context7 MCP with the SolidWorks docs but the results were not satisfactory. I ended up crawling SW's documentation in HTML, painstakingly translating it to markdown and organizing it to optimize greppability [1]. I then created a Claude skill to instruct CC to consult the docs before writing code [2]. It is still stubborn and sometimes does not obey my instructions but it did improve the quality of the code. Claude would need 5 to 10 rounds of debugging before getting code to compile. Now it gets it in 1 to 2 rounds.
[1] https://github.com/pedropaulovc/offline-solidworks-api-docs
[2] https://github.com/pedropaulovc/harmonic-analyzer/blob/main/...