Spot on the nose about number of people and their endurance tilting at the hard problems. BRL-CAD's been going at it longer than anyone, and the backlog only increases. I do believe open source CAD can get there, but it'll require more coordination.
Thanks!
>> Spot on the nose about number of people and their endurance tilting at the hard problems.
It worries me at times. The creator has moved on but can still be consulted on stuff. The 2nd lead maintainer burned out and nominated me. I see my position as somewhat temporary, but I'm willing to hold it until 1) I get the improvements done that I want to and 2) the right successor comes along - which I worry may never happen ;-)
>> I do believe open source CAD can get there, but it'll require more coordination.
Completely agree. Not sure how to focus all the different efforts though. Talking about it is certainly a start.
Currently researching geometric modelling kernels but collaboration in the community and bringing focus would solve this... even if it's better awareness and marketing so that solvespace folk and brlcad folk (and more!) aren't doubling up.
If there is interest in creating a new geometry kernel I'd be happy to discuss how ours works, what the main challenges are, and what limitations the approach has.
Another topic is licenses. I see FreeCAD uses LibreDWG now but has to jump through some hoops because its GPLv3 (not LGPL) and they are GPL2.x.
For the prior, OpenCAx Association was created specifically to encourage and even sponsor OSS coordination. It's still in formation, but it's purpose has been to help underpin Google Summer of Code collaboration for BRL-CAD, FreeCAD, OpenSCAD, LibreCAD, STEPcode, IfcOpenShell, and most recently KiCAD.
For the latter, creating a shared product or even sharing small subsets of logic is a challenge. BRL-CAD fully invested in and helped establish STEPcode for STEP support, for example, and now it's its own project. Spent more than a million USD developing our STEP support.
BRL-CAD is arguably closest to developing something akin to ACIS or Parasolid as its libraries and converters collectively cover the most features, but not without limitations (e.g., lacking API design, dozen libraries). There's been some talk of integrating OCCT where they have features BRL-CAD lacks, but that's a lot like Creo bundling Parasolid and ACIS with Granite (i.e., lots of representation, conversion, and API considerations). We do have a long-term roadmap but it's all dependent upon what people volunteer and are interested in working on, what we're paid to work on, and what's the best path forward strategically (and from a maintenance perspective).
Right now, we're heavily focused on usability and creating reusable geometry conversion infrastructure (which includes AP242 and a couple dozen other formats) and are making progress getting funding as a multiyear development initiative. Long-term, we're working on the clean API problem developing what we calling the Modular Object-Oriented Solidity Engine (MOOSE).
MOOSE meet Tovero the horse.
I guess everybody's gone from this post, but for posterity, it might be worth looking more closely at the source for Tovero, since we had to work around the lack of a formal C API when wrapping BRL-CAD with C++. In retrospect, I probably wouldn't even have chosen C++, but just done a C API which would be easier to use with the FFI of many languages like Python, Julia, or Common Lisp--and eliminated the need for SWIG. At least think about putting a C API on top of the OO of MOOSE, if you intend it to be accessed by other languages.
For an intelligent way of putting a C API over a C++ OO design see:
This project also demonstrates F-rep, a technique for modeling geometry with implicit functions and SDF, and Tovero 2.0 used it as an external dependency for its geometry kernel.
