Onshape is free in the browser as long as you are not doing commercial work. It’s a professional system from the founders of Solidworks that competes with all the top CAD tools.
Because it's built on Parasolid, the same geometric kernel as everyone else. With ACIS pretty much out the door, almost all the professional CAD packages are just window dressing on the same CG implementation.
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!
uhh what..
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.
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.
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)