Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
SolveSpace-Daily-Engineering
Discontinued app4soft's engineering experiments in SolveSpace — FLOSS parametric 2D/3D CAD & CAE (.slvs files repository) Follow ➡ https://twitter.com/search?q=solvespace+from%3Aapp4soft
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
There are two Rust projects working on parametric kernels I'm aware of.
The first one, Truck[1] seems to have a company behind it, Ricos Ltd, that look like they to know what they're doing[2]. The tweet shows their product using functionality from Truck (the frontend is not OSS AFAIK).
Fornjot is an ambitious project IMHO. Their kernel is in a separate crate[3].
As for OSS code that could be a good base to either use (or port to something like Rust) for someone to write their own kernel is Ayam [4], the oldest OSS 3D NURBS modeler that is still being developed.
[1] https://github.com/ricosjp/truck
[2] https://twitter.com/RICOS_ltd/status/1550390552482693120
[3] https://crates.io/crates/fj-kernel
[4] https://ayam.sourceforge.net/
>these the the central core that understands BREP and implements the geometric operations.
I've seen people quote a good modern CAD kernal as a 100 man year project. It's probably not going to happen, maybe there's some avenue for government funding?
Alternatively Signed-Distance-Functions are pretty nice. They're not BREP, but they're a lot easier to implement, and it might be possible to shove them into a BREP-shaped hole.
Here's a signed-distance-function based CAD kernal written in a few thousand lines of python+numpy, that seems to be about as fast as openscad. Maybe faster. https://github.com/fogleman/sdf
I think some interesting developments are made in that sector in the form of https://github.com/hannobraun/Fornjot and https://github.com/ricosjp/truck. Let's see whether one of those will actually get anywhere near a usable level. Fornjot in particular is shaping up really well.
> To clarify, can this method be used as a fully functional replacement to BREP for a mechanical (machine design) CAD system?
I think so, but there are some open problems. Also it depends on the senior people. Inigo Quilez is a world class expert in this domain, and for the most part we're copying his work, get him on board and you'll be golden.
Fundamentally it makes sense, BREP is about representing boundaries and you can definitely use SDFs to represent the area under a boundary (infinite SDFs are possible, although obviously you can't turn them in to a mesh). Enclose a volume with boundaries and you can mesh that out just fine. A bit different from CSG-based SDFs, but entirely plausible.
>what approach would you recommend?
If I was to do this I'd take the constraint solver from solvespace (same one used in this post) and start using it to generate SDFs. At that point you're already 80% of the way to your end goal.
I mean if I was personally to do this I'd start by making a system that implements everything openscad can do, try to get some funding going, and than add in a solvespace based workbench for doing 2D cad that you can import into an openscad-ish language. You can see my efforts here: https://github.com/traverseda/PySdfScad
That's tackling it from a different angle than BREP though. I think that openscad but better is a surprisingly viable thing though, especially if you use it to do things like generate the gears/screws/whatever you import into your BREP based CAD project. Use scriptable CAD as the underpinning for more advances CAD.
> How long would you estimate it would take for three full time senior developers to get a useful system out?
Well define "useful"? Honestly I think you can get 80% done in under a month. I built the first pysdfscad in a week or two and replicated 80% of openscad's features. Fogleman built the library I used for pysdfscad in under a month.
I'd expect something pretty good in under a year at that kind of rate. There would be some outstanding problems, like it would be a challenge to figure out how to apply a fillet/chamfer to an edge, but not an insurmountable challenge. Geometry import is another place where you're going to spend a lot of time/money but is very important.
So let's say two or three years with three very competent seniors working on it to get a pretty good CAD program, with a GUI.
Don't hesitate to ask your questions in the discussion pages of the github repo: https://github.com/sgenoud/replicad/discussions