YuechenLi
https://github.com/yuechen-li-dev/Aetheris
One of my goals when I built the kernel is I want to make building a pro grade CAD software as easy as wrapping a web frontend around the Aetheris libraries. It's still very much an aspirational goal though.
For your application in IFC, the architecture difference between OpenCascade and SMLib doesn't matter as much, but a geometric modeling kernel for mechanical CAD has much stricter requirements in terms of geometric correctness, which is the reason that Rhino, despite being BRep and widely used in architecture, isn't used very much in mechanical CAD at all.
SolveSpace is still fairly limited on what it can do in terms of features such as fillet/chamfers, so it's not really suitable for pro work right now
For projects like SolidCraft, the SMLib kernel they are currently porting to Rust from Nvidia is currently about a decade behind OpenCascade, nevermind Parasolid/ACIS as they are still converting all geometry to NURBS instead of preserving analytical geometry, which means that their initial development is easier but it creates a near infinite amount of edge cases once they start going heavy into booleans and fillet/chamfers.
(I'd like to think my own kernel is little bit ahead of you architecturally though.)
How's the Boolean and fillet/chamfer robustness currently in Popkern?
Also, would you like to collaborate and compare notes? It's a lot of work trying to maintain something like this solo.
https://github.com/yuechen-li-dev/GenerativeCompressionProto...
Already made the geometry kernel. So far, nobody has offered me even like 20 dollars to license it yet, nevermind millions of dollars.
On screw thread, if you mean by "how do you make a screw thread in Aetheris", you can check out the actual code for a threaded bolt I built for a showcase here with the JSON like DSL called Firmament:
https://github.com/yuechen-li-dev/Aetheris/blob/master/fixtu...
So, the high-level surface language of defining a screw thread is basically a struct/record that looks like:
Thread MainThread {
Surface: face(Bolt.Shank)
MajorDiameter: 8mm
Pitch: 1.25mm
Length: 47.5mm
StartOffset: 1.5mm
}
If you mean compile speed wise, not great right now, it wasn't that much of an issue when running on RyuJIT natively since it's still acceptable, but currently WASM cold compile speed for a moderately sized assembly is around 4-5 minutes so there is a lot more work to be done before I'm ready to put it on a cloud server.
However, OpenCascade being C++ instead of Rust is the least of its problems, the main issue is OCCT's boolean/blend engines aren't really as robust as the commercial kernels, and handling arbitrary 3D boolean edge cases one by one correctly is one of the main difficulties of a geometry kernel.
Very interested in SolveSpace's progress on this really.
The current design is meant to be import tolerant but export strict, it imported most STEP file I throw at it fine after a bunch of fixes, but I don't really have a big enough sample corpus know for sure how much real world STEP file it can handle.
Aetheris took a very obvious approach that not many have seemed to tried before: It throws an error when an operation that may create ambiguous intersections and refuses to materialize bad geometry in the first place, which is not really possible to do with traditional NURBS based kernels, whereas Aetheris can because it is analytical first.
Just because you can throw tens of thousands of dollars at frontier LLMs doesn't mean what they write would be good, you still need to have some oversight for their work.
Well, I did it, took 6 months, and I think I'm ahead of Truck on that front since as far as I can tell Truck can still only do single edge fillets with Newton's method as their new fillet algorithm, whereas my kernel can do planar fillet chains fairly reliably.
I wish someone would wrap a frontend around it too considering I'm bad at designing UIs, and the architecture is too weird to put a conventional 3D CAD UI on it that I'm honestly hoping someone would throw their LLM at that task.
https://github.com/yuechen-li-dev/Aetheris/
Also, sorry about the excessive self-promotion, but I think most people would be shouting from the mountaintop if they built a BREP geometry kernel from scratch solo too.
The bigger issue is that OpenCascade is error tolerant to a fault, which allows it to import a lot more legacy geometries, but it also means that it silently exports a lot more bad geometries much more often than commercial kernels
So, there's a reason why commercial solutions don't really use OpenCascade over ACIS/Parasolid for authoring.
Here're are some SIGGRAPH 2026 papers attempting BREP recovery, if you are interested. None of their automated approaches seem to work reliably, and they can only recover generic NURBS instead of analytical geometries like circles/cones/torii, etc.
https://github.com/AutodeskAILab/DualBrep https://github.com/yilinliu77/Brepler https://rilpraa0110.github.io/Img2CADSeq/
I wish there was an easier way, but I've spent weeks during the course of the project working on and failing to solve a similar problem (SDF to BREP) and concluded finally that there just isn't an easier way to do this fully automated without AI.
You can ask your LLM to try it with one of the OCCT wrappers or with my thing, I think Aetheris is slightly better because we added more STEP diagnostic tools like ray query depth detection and SVG sectional view during the course of development.
I'm not going to pretend this is easy: I actually quit multiple times for this project because I ran into the same walls that everyone else ran to: arbitrary 3D boolean operations is HARD,(Surprisingly, I actually didn't have that much trouble with fillets/chamfers because I kept them pretty bounded) and the approach I've finally taken to solve it is pretty insane. Essentially, the final architecture is more like "LLVM for 3D objects" compiler stack than it is traditional BREP kernel. Would love to talk about the technical deep dives if people want to hear it.
Also, feel free to write UI wrappers around it, because I'm pretty bad at UI design myself.
https://github.com/yuechen-li-dev/Aetheris/
Not an OpenCascade wrapper, it's based off my own experimental BREP geometry kernel. So, fillets/chamfers work, booleans works fairly robustly, surfacing, sheet metal, etc all works decently, it exports STEP AP242 by default.
Haven't had time to get the AIs to write a more up to date documentation and polish the language server. Not the easiest thing to use right now, so, using it through Codex/Claude Code or CLI is probably the easiest way to get started.
Still working on the webUI currently, in case someone want to DIY the UI. Note that the WASM compilation path is still unoptimized and way slower than the RyuJIT C# compilation though.
https://github.com/yuechen-li-dev/copeland
Compiles to JS, WASM via Blazor WebAssembly, C# RyuJIT and NativeAOT.
https://github.com/yuechen-li-dev/Aetheris/
It's a code-first CAD kernel/toolkit specifically to help LLMs with CAD stuff, it's currently AI usable but not very human usable yet since I'm working on the editor UI. Get your Claude to clone it and give it a try and see if it's easier than your current workflow.
I built two 3D mechanical demos with it a couple of weeks ago that you can check out as well. https://aetheris-difference-engine-showcase.yuechenli.worker... https://aetheris-editable-v8.yuechenli.workers.dev/
https://github.com/gonum/gonum
For sparse, I think the best is still Intel's sparse libraries for MKL on CPU, it's just not a workload that runs well on GPU compared to dense SGEMM. You can call it via CGo.
For GPU offloading, there should be a decent amount of CUDA bindings available for Go right now, but I'm not as familiar in that front since I'm building my own GPU compute runtime in Vulkan, but it's still very much an experimental work in progress right now.
You also get very easy parallelism in Goroutines, excellent ecosystem, and one of the best performance profilers in any programming language, pprof.
You can kinda see that in the many "compile TypeScript to native via LLVM" projects that showed up a lot recently. From my testing, none of them could beat V8/Node JIT in the majority of cases, and most of them are generally 10x-40x slower.
But, we did have a great number of innovations in language design over the last decades that really closes the gap on how optimized a compiler can be over writing assembly directly: Rust's exhaustive match default null-less error handling and language level MIR, immutable data structures from functional languages to mainstream ones, TypeScript's compile time constraints as core part of the language, and Zig's `comptime` turning compile time metaprogramming to an integrated part of the language instead of C++ template metaprogramming.
Obviously, it's not really possible to beat hand optimized C/C++ or directly authored assembly, but I think a well-designed compiler/language can potentially beat idiomatic C/C++ in performance.
And this is speaking as someone who learned compiler design solely from having every one of his vibe-coded projects turn into either a compiler or a kernel for some reason.
Other people's open-sourced project is different though, so I tend to check/test the code myself much more rigorously when contributing to other people's repos than if it is my own projects.