Looks like this uses the Truck modeling kernel: https://github.com/ricosjp/truck
Interestingly, ttouch created browser-based CAD tool CADmium a few years ago based on Truck. Then, a few months ago, they created another one (CADara) based on OpenCASCADE: https://news.ycombinator.com/item?id=48070083.
Truck seems cool, but creating a b-rep kernel is a phenomenal amount of work. Given that, I'm curious how quickly SolidCraft will mature.
> 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.
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.
Fascinating repo, thank you for making it!
I’m curious, what does this part mean?
“ 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.
FWIW I don't think it makes sense to copy anyone's CAD program, and I am negatively disposed to the ArtCraft thing as a general position. I think it's fully the wrong approach.
But I am here for LLMs, if they really can be used to solve maths, to solve CAD maths, which is, as you say, the really difficult stuff.
I am still not going to use an early-stage CAD package, but this actually would be a meaningful contribution to society. The rest is a bit AI NIH.
They are working on a Rust port for the SMLib geometric kernel subset that NVIDIA open-sourced yesterday as part of their new USD BRep library:
https://github.com/bherbruck/solidcore
If the experiment does work out and the library NVIDIA open-sourced proves to be mathematically robust enough for standalone CAD use, it would leapfrog OpenCASCADE kernel for open-source CAD (solved math that was previously propriety, graceful failures without crashes, multiple CPU threads, running smoothly on web browsers).