I think I've seen ports of OCCT to Rust as well as Rust wrappers for OCCT floating around Github once or twice already.
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.
>> Very interested in SolveSpace's progress on this really
Its good progress but still too easy to have a failed boolean. Previously you had to know how to work around bugs to cut a fillet off an edge. Now thats pretty easy and robust, but as soon as you do two of them that intersect there may be a problem. Like you said, the list of corner cases never end. I suspect a bit more Claude use might fix that one too.
Yeah, the Photocraft (or whatever that photoshop clone name is, naming everything *craft just blends the names together in my head) program, for example, is way too slow in WASM to be usable, I think it ran on a single thread without using Worker and basic optimization features like that.
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.
expecting it to work well in wasm seems a bit too high of a bar.
It works relatively well in native mode as a standalone app (tho not being an actual photoshop expert, i dont know if the features compete properly, i simply hear that those trying it are impressed).
The excel clone works well enough for me to do taxes on, even tho the look and feel is a bit janky. I would stick with google sheets, but it's a usable replacement if i didnt already have sheets.
> Creating a b-rep kernel is a phenomenal amount of 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.
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.
“ Dangerous operations which may generate degenerate/sliver/zero-dimension geometries are instead blocked from materializing to 3D at a compiler level.”
How is that achieved, or rather what does that mean? What defines a sliver?
A sliver is basically a tiny degenerate geometry in the micro/nanometer scale that's basically the result of ambiguous surface intersections. Basically, if you put two say, cylindrical surfaces against each other in NURBS form, floating point noise would generate these microscopic geometric noises, and a lot of what commercial kernel does is they use what they call "healing" operations to clean up those bad microscopic geometries from the models they generate.
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.
You see slivers in 2D spatial operations as well. Imagine that you have two parcels represented as polygons that don’t perfectly spatially intersect. If you perform a boolean operation to, say, compute the union of these two polygons into a single one, any microscopic difference between the two boundaries below a certain tolerance (like 0.001 square meters) will manifest itself as tiny gaps and slivers. Most GIS engines will merge the two polygons appropriately beyond that tolerance (this is a way simpler problem in 2D space!) but if the data is bad enough you’ll definitely see it.
While this is technically correct behavior, users will interpret that as your software not being able to do something - or as a bug (because it works on one drawing but not another).
Well, this is more similar to a linter/borrow checker than anything else, because if you catch errors at compile time, the bad geometry doesn't persist in the STEP artifact that's being generated, so analogous to the philosophy of Rust vs C++ 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 generates STEP AP242 BREP directly, the tessellated mesh generated is only used for display (although currently, I've switched to a WebGPU based SDF representation so the surfaces can be smooth). One of the key differences in the architecture Aetheris doesn't export rational b-splines outside of debug or STEP passthrough and instead tries to recover and export analytical and non-rational splines instead.
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:
Which is why I said that it's really hard to think of an editor UI for Aetheris that's not just a text editor or a ComfyUI like graph visual programming or something.
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.
I'm not trying to tear this down but if your geometry kernel can't be compiled into a .dll or .so file and then included inside the CAD program I'm not sure people will be interested in running your software.
I'm not critiquing the language choice, it's just that I basically have a thing that is big on dynamic linking and I would rather farm out the geometry kernel to someone else and at this rate I'm kind of forced to port yours over so it works for me and I think that would be a bad outcome for both of us.
Also your .firmament files are good because I'm working on something like that too.
Yes? It's a back and forth discussion, where the model's output (that is much more pluridisciplinary than Terrance will ever be and therefore benefits from the common knowledge of not just an entire field, but thousands of fields over thousands of cultures) actively drives his responses and verifications. Literally, the entire set of messages is "you said X. Does that therefore entail Y in what you said ?". Terrance being an expert knows how to drive the conversation in angles which he explored, but it remains that the bulk of the work is done by Claude.
If I keep asking clarifying questions to Albert Einstein, that doesn't make me the inventor of relativistic physics, no matter how much I know about the subject.
I'm not contradicting OP's expertise on the subject: they seem to at the very least know what they're talking about. But saying "I" did this when all you did is prompt the funny slot machine and approximately none of the code is reviewed (6 commits per day, each being 50+ files on average is not something you have reviewed or understood.) is lying to others and to yourself.
I couldn't build this even with Claude Mythos, I have no freaking clue what this stuff is, and I'm a full time software developer that understands performance optimization and even has used SketchUp a lot.
I'm telling you, I simply couldn't do it. Unless the prompt is "copy every single feature in AutoDesk Fusion 360" and sit back, and even then, I wouldn't even know where to start with testing it, knowing whether it works properly, and whether the various tools are useful, performant, etc.
Let's not assume that the code is the most important part, it's important, but domain knowledge is still very important.
Yes for some reason people are really bad at being honest. For that reason all my AGENT.MD files instruct the AI to write a disclaimer at the end what kind of involvement I had and how much the AI did.
Most of the documents have something like this at the bottom:
"Primarily written by AI based on human design discussions."
And I don't feel ashamed to let the AI do the writing because the output is reasonably good because I let it generate a TOC then I rework the TOC by hand, then for each TOC chapter I just have a discussion giving it the information and then I let it generate the text. I didn't even directly tell it what to write about. Instead there is a loose discussion that contains all the needed information to convey.
So it is really silly to then slap your own name on the final end product and claim you did all of it, even if it took weeks of prompting to finish the document.
What I'm interested in is their performance, since I would assume that they are running in WebAssembly from reconstructed C/C++ code decompiled from binary, what would be the overhead on that compared to running on native? And how does running on WebGPU compared to running with native through DirectX/OpenGL?
A lot of the games being ported/reconstructed were made at a time where consumer hardware was up to or even more than an order of magnitude worse than what most people have access to today.
So that probably helps contribute to why they still run smoothly even in WebAssembly/WebGPU. Even if the overhead was like 5x worse (pretty sure its nowhere near that, closer to maybe 1.5-2x in certain cases), it'd probably still run pretty smooth.
I'm getting 45fps on Skate 3 on my phone (Pixel 9 Pro, with the Pixel line being notoriously underpowered CPU wise) in the non-phone mode. I could try phone mode but touch screen controls aren't worth the loading time for me.
Performance is excellent, most of these games aren't all that hard to run. I expect most recent mid-range computers are able to play all of these in a playable fashion, even the ones running on integrated graphics.
To be fair, arbitrary fillets/blends on edges is a hard problem in general for Parasolid/ACIS because you are trying to mutate arbitrary topology, essentially guessing vertices/edges/faces and trying to stitch the back together.
This is true, but in things like OnShape I can do it with two clicks whereas in OpenSCAD it's always at least 20 minutes of thinking and trying out.
OpenSCAD is super cool and my go-to for simple things, but for anything more involved than a cube or cylinder with some cutouts I tend to revert to "normal" CAD programs.
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.
Not even two years ago writing your own BREP kernel was considered to be out of reach for even the most determined dedicated hardcore engineering teams that weren't extremely well funded. Now, it seems tractable and may finally get us out of the dependence on proprietary kernels that has plagued this industry for decades.
Yeah, I know. I started this project earlier this year because of my own frustration with the software ecosystem and that the major CAD vendors is charging thousands of dollar to add STEP 242 support and because of proprietary lock-in and locking everything behind cloud, and was trying to see if I can accomplish this with AI.
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.
Given modern capabilities how hard would it be to make a really high quality stl to STEP converter that works well on CAD models that have been converted to STL?
It doesn’t need to be perfect on edge cases just translate back “reasonable” models.
Should be something that is fairly easy to eval etc.
Near impossible to do it robustly without AI, since a mesh is a blob of triangles and vertices, it doesn't really know if something is a "face" or an "edge", and mesh STL -> BREP STEP is akin to decompilation from binary than it is a simple translation. So, the most robust approach is to get a human/LLM to reconstruct the STEP file from the STL/OBJ/glTF file with a BREP kernel.
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.
STEP is a weird standard and one of the reasons it's weird is because it allows you to store tessellated mesh in the file with no BREP. Wrapping an STL mesh inside a STEP container is trivial, but reconstructing a BREP from the mesh is daunting.
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.
You can find NURBs fitting in decades old textbooks (such as "The NURBs book"), but you have to be aware that this is an approximation problem as the only exact fitting is the one where the output is the input.
Also prone to robustness and quality issues. You're better off outputing a BREP directly.
OpenCascade is an almost 30 year old C++ codebase that's known for being notoriously difficult to integrate.
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.
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.
Unless you are doing very low level C++ manual memory optimization, I would recommend using Go for both: it's on the same scale of magnitude of speed as C/C++/Fortran but the compile time is crazy fast that prototyping in a high-level scripting language like Python really isn't that necessary.
You also get very easy parallelism in Goroutines, excellent ecosystem, and one of the best performance profilers in any programming language, pprof.
Interesting. Parallelism and profiling are both strong selling points.
I’ve done pretty low-level C++ and Fortran in the past, but these days I’m honestly mostly used Python with either NumPy or CuPy for calculations, so not very low-level at all. My code is pretty performance-sensitive though, so unless the main operations can be framed neatly in terms of NumPy or CuPy primitives, one had to drop down to low level.
Do you know how the Go library support is for typical scientific computing stuff, e.g. matrix diagonalization, sparse matrices, or handing off such calculations to CUDA (or other GPU frameworks)? Is there a strong numerics community in Go these days, or would you have to implement most of what you need yourself?
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.
Thanks for the pointers, appreciate it and will look into it!
Yeah, my understanding is also that working with sparse matrices inherently requires heavy branching, which translates badly to GPU. I usually do everything I can via dense matrices via CUDA, but switch to sparse matrices on CPU if I run out of VRAM…
Compiler isn't really difficult in the way that many think it is, because it really isn't that difficult to write a basic C compiler for example, and writing a parser is pretty mechanical that there are a multitude of parser generators. The difficult part is that writing an optimized compiler is much more difficult than writing a correct compiler, and certain language features, like generics, closure, and async, propagates and touch every part of the language that the complexity grows exponentially, and it's really hard to balance performance, compile speed, and correctness against miscompiles.
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.
Complexity does not grow exponentially and not even polynomially because you lower things. At the backend, generics, closures, async and many other features are completely non-existent (except for debuginfo. Debuginfo is complicated).
That does not mean writing an optimizing compiler is easy, of course. The frontend for many modern languages (especially Rust) if also far from trivial.
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.
reply