Agreed. I’m not OP but for six months I’ve been using Claude to build a from-scratch CAD kernel based on Rust and WASM, MIT licensed.
The actual UI still needs a lot of work, but I’ve been focused on the kernel. Fable has helped a lot though Opus was already making great headway.
I’m an OnShape power user going back about ten years, Solidworks before that. I need a CAD system that absolutely works. There is a lot of work to do still, and it still seems impossible to succeed, but I’ve been very happy with where things have been going with it lately.
It’s serverless, local, and browser based. You can load the latest binary from GitHub pages here:
https://sequoia-hope.github.io/waffle-iron/
Click the Assay menu to see the kernel test cases we’ve been using so far. Rapidly closing on 100% support!
Heh, me too. I'm on my third rewrite after a bunch of promising false starts.
Unfortunately geometric kernels are one of those things where unknown unknowns will bite you in the ass really hard because none of the content is really in the training data for LLMs and pathological/degenerate cases aren't just common but expected. IME it's not something that can be vibe coded with current models, if ever, without intimately understanding the algorithms.
I can't do a thorough review of waffle iron right now but just off the top of my head: it doesn't look like you have a tolerance context? The tolerances look like hard coded constants (TAU_MODEL/TAU_WORK/MATCH_TOLERANCE/etc) but that's fundamentally unworkable. Each operation and vertex/edge/etc needs to track accumulating errors and apply them to downstream point classification. Interfaces like Kernel::boolean_union(a, b) are the wrong abstraction because it's missing tons of information/functionality like accumulating FP errors, evidence/proofs, rollback, etc.
Keep working at it! It's worth the challenge.
Thanks! I had a lot of false starts too. I asked fable in my repo about your question and it said there are two schools of thought on tolerance tracking. My kernel uses exact predicates which fable says eliminates the need to track tolerances the way ACIS does. I tried to paste the full reply but my comment seemed to have been auto flagged.
I think Fable gave you a load of nonsense. Like I said, this stuff isn’t really in the training data and academic research is disconnected from commercial CG (and I’m pretty sure its wrong about ACIS - iiuc ACIS used global tolerances and its one of the reasons it lost to PS).
Robust/(adaptive) exact predicates and tolerance tracking solve two different things and a geometric kernel needs both, especially if you plan on letting models use meshes, lattice, or freeform surfaces (which is where the industry is headed for simulation driven design). The constructions you feed the exact predicates need to already account for tolerances to be correct (i.e. pcurves, vertices, etc) and the second you do any math on them - before feeding it to the predicate - you need tracking. Predicates don’t eliminate the floating point math.
(Grain of salt and all that, I don’t really know what I’m talking about)
[deleted]
What is your issue with OnShape that prompted you to undertake this project? Is it because it's not open source?
Basically. Moreover though it’s cloud based so you can’t run it with a poor connection or no connection. They could change their mind at any time about free accounts and lock users out. Free accounts can’t make private files. And I don’t know if OnShape is accessible to everyone in every country.
Very cool. You mentioned it is mit licensed - is it shared publicly somewhere?
How long have you been building this?
Six months. Basically when Claude code started to hit that inflection point I chose a project that seemed potentially impossible but was also something I care deeply about. (I have a lot of history with open source and CAD and I even made an open source CAD forum on GitHub a few years ago to discuss options.)
I set up remote tmux access to my phone right at the beginning so I have been advancing it rather continuously during my waking hours. Especially the last few months which have been a very focused push on a new kernel architecture.
Aww thank you so much! It has felt really good to work on as I have started to see something real come together.
> It’s serverless, local, and browser based.
uhh what..
The app consists of a wasm (web assembly) binary and JavaScript. The wasm runs locally on your machine in your browser and communicates with the JavaScript frontend. There is no backend server to handle any part of the program. The URL just loads the binary in to your local browser. I don’t know exactly how one would set this up but this would work for example fully offline. The browser basically just becomes a universal compute and rendering engine for it.