BRL-CAD(en.wikipedia.org) |
Does anyone have any experience in the software side of the industry to help explain why nothing open source is able to step up in a meaningful way?
There's no money in CAD by itself, meaning just the drawing part. Drafting is a low-value activity often performed by low-value workers who don't write software. Even if they wanted to, they couldn't make software tools for themselves. It's not like when web developers make web development tools, or when machinists make machinist tools.
CAD is sort of a piazza where the value a company gets from it comes from everything that's attached to it - reporting, CAE, CAM, etc. And they do invest in those things, often quite heavily.
It's big business to create these tools. The investment and expertise that go into them is enormous. That's why many of them cost as much as hiring another employee. They do at least as much work as one. They keep up with all the latest and greatest regulations, technologies, manufacturing processes, etc. And they give you access to a lot of valuable proprietary information.
Even if a company threw twice as much money at open source CAD, they'd still get basically none of that. They would just have an expensive drawing tool. It would be basically worthless and worth almost nobody's time.
For customers with low requirements, the less expensive tools do the job at just the right price point where it doesn't make sense to invest in advancing something like freecad.
Also, many companies in many countries are pretty much "allowed" to pirate the really expensive software. Once they get big enough, the software company will ask them to start paying some reduced amount. So there's an unofficial free tier that's way better than any open source toy.
Case in point, BRL-CAD has had more than 450 years of full-time effort invested, tens of millions with development spanning over four decades. However, that investment is heavily centered around features, integrations, and capabilities that are not as typically useful to the general public.
Usability's slowly expanded, but primary paid focus is military vulnerability and lethality analyses where BRL-CAD is absolutely unparalleled. Even against the likes of CATIA, Creo, NX, Solidworks, etc., development is heavily and strategically optimized and invested for solid geometric analysis, validity, verification, and performance. BRL-CAD so overwhelmingly outperforms the commercial tools in the analysis space and is so well-integrated that it would likely cost tens of millions to stop using it.
Still, general usability is not funded and is left to the auspices of the open source community. That's a long road. Adding usability and developing infrastructure for a system that complex takes time and a level of expertise that isn't common. Until it gets minimum viable general usability, it's hard to scratch one's own itch without personal investment or extrinsic incentives.
To me it sounds like professional CAD is really hard and nobody can "just make it" in a few years of work. That's the reason why open source CAD doesn't really exist today in the professional space. But once it exists, it will eat the world. The transition phase will still take dozens of years because of all the work invested in existing platforms. We will probably see something similar to the adoption of Linux in the commercial space where it simply makes sense to use Linux instead of developing your own OS or licensing some other OS.
The value as linkdink said above is the add-ons, integrations, extensions, and the like.
It's a bit like Unreal Engine 5 having integrated the Quixel model library. You don't just get some C++ code, you also get ready-made art assets. And then you get compatibility with four game console platforms, mobile platforms, etc...
...
...
??
Current Solvespace maintainer here. IMHO there is a lot that can readily be added to solvespace. Then there could be a big effort to do hierarchical sketches. And it is reasonably possible to rewrite some of the geometry internals if needed. All of these things are a LOT of work. The problem is the number of people with the background, software skills, and interest in contributing is very very small.
Having said that, we will just keep chugging along. I've been very busy with personal stuff this year, but soon should have free time to address my backlog of stuff I personally want to do.
Open Source has the advantage of time as long as people stay at it ;-) OTOH Blender and FreeCAD have used the constraint solver. If they borrow some of UI ideas then we all win too!
See: https://wiki.freecadweb.org/OpenCASCADE https://en.wikipedia.org/wiki/Open_Cascade_Technology
A pattern I've often seen is a tortise vs the hare sort of thing between FLOSS and $$$ software. The free stuff improves slowly but steadily. The $$$ stuff changes quickly but those changes are often driven by perverse incentives (people looking for promotions, shareholder value, etc.), and development tends to go off the rails and piss off users.
eventually i had to get a "real job", a job where i can't really be doing domain specific open source stuff without a potential conflict of interest.
on the plus side, i just bought a couch without having to worry about whether i can eat dinner.
https://mirrors.sarata.com/non-gnu/tovero/Tovero_tutorial.pd...
We used it for a few small projects. BRL-CAD also has Tcl scripting.
We've currently switched to pure Common Lisp and F-rep modeling for scripted CAD. This is the old CL one (again wrapped C++) we are porting:
Looks like the code is at http://svn.savannah.gnu.org/viewvc/tovero/trunk/ ? That's some impressive work, particularly some of the advanced geometry entity mapping going on in there.
"My kingdom for a voice" [1] or maybe "My kingdom for a horse" [2] we did post an item about it on the BRL-CAD mailing list. The Common Lisp community didn't really notice Tovero 2.0 for Common Lisp either.
I was actually thinking about trying a Common Lisp wrapper of BRL-CAD, or maybe doing a native CL port.
[1] REM, Document, "King of Birds", 1987 (Anybody know a good marketer?)
[2] Shakespeare, Richard III, Act 5 Scene 4 (a Tovero is a type of horse)
After I got it running I had some trouble getting it to do things and wrote to the email address asking for example files. Mike Muuss himself wrote back with a bunch of demo files attached.
That's kind of awesome. I built it from source a few years after that and didn't have to deal with any headaches at all.
Wow.
The BRL of BRL-CAD is the Ballistic Research Laboratory:
https://en.wikipedia.org/wiki/Ballistic_Research_Laboratory
which developed, along with the Penn, the first general-purpose digital computer ENIAC:
BRL-CAD is one of the few "full-fledged" CAD systems that I know of which is explicitly CSG, while most (all?) commercial CAD programs are B-REP in nature.
CSG and B-REP are two worlds apart. I'm not sure why in the comments we're suggesting alternatives in the two categories interchangeably. They're not [*].
An alternative to BRL-CAD would be OpenSCAD or libfive studio + other tools (since BRL-CAD does a ton more) and more recently CadQuery. Maaaaybe Tinkercad could be classified as CSG?
CSG makes some operations easy at the expense of other things that become incredibly hard. The same is true for B-REP. Doing gears, highly procedural or FEM-directed models via CSG? Easy-peasy. But try to add a filled between two edges. Step it up 50 notches to fillet one edge and do the equivalent of "tangent propagation". Now the same, but also try projecting a structure on that round face.
CSG's speed is also wildly overblown. While B-REP is not exactly lightweight, computation complexity scales with the complexity of the model but can be sped up by caching intermediate representations.
In CSG this is not always true, since caching the intermediate representation can destroy the accuracy of the final mesh in ways which are very difficult to compute. So even for apparently easy models, times spend walking the space to remesh your model can grow _very_ quickly, hampering the ability to iterate quickly and experiment.
Not to mention, "measuring things" in CSG is hard. This is never mentioned, but none of the tools I've worked with so far offers convenient ways to examine and measure the objects you're working on. For a parametric model this is vital!
[*] Not saying there's no overlap. I'm using both systems. B-REP generally wins on a model which is feature-directed, which is why it's more popular. But I can relate to people that think that BRL-CAD is "hard".
CSG and hierarchical relationships still underpin, but a lot of effort was invested in BREP support over many years. There was already extensive support for polygonal BREP, but NURBS BREP was added to support seamless conversion of commercial CAD. BREP NURBS can be imported, ray traced, and facetized. BRL-CAD still needs direct surface editing, but you can mix implicit geometry with NURBS (e.g., subtract a hole) without issue. CSG entities can also be converted to BREP and work is ongoing to improve Boolean evaluation of BREP-on-BREP entities.
As for performance, implicit geometry with Booleans (i.e., "CSG") is typically an order of magnitude faster to evaluate (and an order of magnitude less memory than BREP/NURBS which is in turn an order of magnitude less memory than BREP/Poly). BREP/NURBS easily offer the most editing flexibility. CSG offers the most compression and programmability. BREP/Poly offers the most interop at the expense of representation fidelity, memory, and (sometimes) validity. All three can be "fast enough", but evaluation performance is still an important consideration on real/big models, e.g., fully detailed vehicles.
Note that generating an intermediate representation off CSG is not intrinsically necessary. When you have really fast+good solid ray tracing and analytic routines (and measuring tools) built around it, you don't need an intermediate rep. You just directly evaluate shotlines and get mathematically precise answers. That can be used for real-time geometry display, for measuring things, for identifying interferences, for computing properties, etc. That's BRL-CAD's primary niche specialty.
While I can't speak for BRL-CAD my experience with FreeCad which uses OpenCascade has been mixed. The chamfer/fillet tool there is just broken. If you use that and change some dimension it is likely to randomly crash. So, overall my experience has been ranging from rock solid to total trash depending on which features you use and what kind of models you create with it. The key question is "what do the developers use it for?" which should give you a hint for what kind of problem it is made.
Funny that. Working with Creo on a day-to-day basis makes me want to quit my job.
I was looking up at the current docs for the csg->brep conversion, but I don't really see much. Does brlcad actually allow to fit/reconstruct NURBS over the constructed geometry? The export docs still mention IGES export is just faceted.
I'm mostly using openscad and cgal directly, and my experience with both is that model regeneration takes a nosedive for anything non trivial. openscad for example doesn't offer any tool to shoot/analyze rays. The realtime preview also suffers for coplanar z-fighting issues, often making exact CSG operation really hard to debug. However the ergonomics are pretty decent when iterating and constructing geometry on the fly.
Can I ask your role in brl-cad? All your posts are extremely detailed. Are you a contributor? I wonder if I should reinvest time in brl-cad once again.
Cad software often includes simulation stuff which requires an engineers mind.
Remotely related, I've always thought a really fun lisp project would be to create an Emacs major mode for BRL-CAD. Either something to explore .g data (like tar mode) or an interactive editor like mged with lisp wrapping BRL-CAD's libged editing library.
10 years is generous paternity leave. :) Seriously though, no hard feelings, separating the wheat from the free software chaff takes time--ask me how I know.
> interactive editor like mged with lisp wrapping BRL-CAD's libged editing library
That interests me!
IME, I have found S-expressions to be an elegant, succinct way of expressing geometric models (especially in the F-rep domain):
https://github.com/JMC-design/tovero/blob/master/examples/ro...
I wrote a referencing counting C++ reader/writer for S-expression models like that directly into Open Inventor, in place of the IV (VRML) format, avoiding the use of CL.
Emacs has a C FFI, IIRC, so it should be possible to develop a S-exp formatted BRL-CAD model in elisp, with the right C shims--giving a live-coding, REPL experience for building BRL-CAD models.
Thanks for your work on BRL-CAD!
You mean a bit like an operating system without a kernel...?
/me waves constructively, solidly at `brlcad
Your list looks good until “version control”, for which at least sccs[0] began representing in 1972.
I’m not used to catching `brlcad out at… anything, usually. Thought he might enjoy this “technically correct” (the best kind of correct) note.
Not that the list isn’t impressive enough, and BRL-CAD impressive in its own right. And to think it started as a dare.
[0] https://en.wikipedia.org/wiki/Source_Code_Control_System
There's actually some indications BRL-CAD started in SCCS back around 1980, but any evidence of that is likely on old 10.5" magnetic data reel tapes that can't be read easily. So instead BRL-CAD's documented commit history spans from RCS import to CVS to SVN to Git.
My first language was FORTRAN 66, learned from a book in the library, but on paper only as I had no access to a computer until a couple years later in 1979.
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.
Does any system aspire to be a Prolog for 3D? You sketch a variety of views and a system solves, if possible, for a solid geometry representation?
From https://solvespace.com/tech.pl
> The core of any parametric CAD program is its geometric constraint solver.
and
> In SolveSpace, constraints are represented as equations in a symbolic algebra system. In general, these equations are solved numerically, by a modified Newton's method.
and from https://en.wikipedia.org/wiki/Geometric_constraint_solving#M...
> symbolic methods have been applied to this type of constraint solving (see Reference 20 on the Wikipedia link).
And your Zen "beginner mind" question got me to thinking, maybe I could use Prolog itself in my CAD system to directly make 3D shapes, since Prolog has been written in Lisp. Although Prolog does have a number of limitations:
I'm not aware of any. Maybe slightly related, my plan for a "hole tool" in Solvespace is to add a hole entity to 2D drawings that will automatically create a featured hole when the sketch is extruded. But that's not actually solving anything in a math sense.
https://wiki.freecadweb.org/Path_Workbench
My thesis is that the bigger challenge is "economic", not technical.
There is currently no incentive model that I know of that can make this work at a university, or even national lab. In these contexts currently it's really hard to get funding for a single "real" programmer for a year, let along a proper effort for something like this. If it became a critical infrastructure project for a federal level agency, sure - but why would they support doing it in public?
The problem is that writing one takes a big effort - like Linux kernel sized, and needs people with niche technical knowledge. It's much, much easier to find someone who can write a java app for a web page than it is to find someone who can write CSG code for a CAD system.
It may eventually happen, but it's not inevitable.
For what it's worth, BRL-CAD has over 450 full-time staff years of effort invested with ongoing dev funded by the U.S. Gov't. It was made open source specifically so that investment could be shared with the world, to help commoditize CAD like has been done for browsers and compilers. It's a long road to get there no matter what.
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.