Another direction you could take is to define just the API, and use the opencascade kernel (like FreeCAD) until the rest of your code is ready.
> Another direction you could take is to define just the API, and use the opencascade kernel (like FreeCAD) until the rest of your code is ready.
A CAD kernel is the central dependency for any CAD program, and I feel that it would be wrong to just use one and accept its limitations. I need to be able to take ownership, to work on it directly. OpenCASCADE is a huge pile of C++ code, which is the opposite of all that. (Not saying it's wrong to use in general, just that I'm the wrong guy to work on a huge pile of C++ code.)
I've considered using Truck[1], but decided not to do that for now. I really want to see what I can come up with. If that doesn't work out, at least I'll be in a much better decision to decide what other option would be best.
For example, you're not allowed to define a point that happens to lie on a surface. You must instead explicitly define the point in terms of the surface. By extruding from a sketch that lies in the surface, or by saying "extrude until the shape hits the surface", or by specifying some kind of constraint.
I hope that it is practical to design CAD models in a way, such that these relationships are always explicit, and I hope that this will enable the CAD kernel to not have to rely on messy floating point stuff comparisons. But as I said, not no idea if it's going to work out like that.