YuechenLi

Ok, I think I oversimplified it too much previously, the more accurate way to word the difference is that in OCCT/ACIS/Parasolid, NURBS and analytical surfaces are separate entities altogether, whereas SMLib, due to its heritage, uses NURBS as the underlying representation of everything and only use analytical surfaces as shortcuts, and even their analytical surfaces are built on top of NURBS.

MoL seems to be more of a Rhino alternative than it is a mCAD application, so, yes, the architecture that makes it good for freeform surface modeling is what makes it less good for mechanical engineering applications.

Hmmm. Have you tested the hard case, surface/surface intersections between cylinders yet?

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.

FreeCAD and Dune3D are both OpenCascade based, so they are limited by OpenCascade's architecture (For example, OpenCascade uses per-entity tolerances, which means it is more bad geometry import tolerant, but if every face and edge has its own tolerance value in the kernel representation, then it creates a great amount of hidden tolerance drift.)

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.

From their Github, it looks like OpenCascade with Manifold for mesh boolean that they are calling MEDUSA.

Out of curiosity, may I ask what the big unrelated problem is?

At this point, Python is less of a programming language by itself but more of an interop protocol between various C/C++/Fortran/Rust binaries. But again, it's just part of the cycle, Python was a breath of fresh air 10 years ago when academia is still dominated by Matlab, but now it is mostly a mess of a language that's good for throwaway scripts but not very convenient for large software projects compared to statically typed languages.

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.

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.

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.

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.