BRL-CAD
en.wikipedia.orgAs a Mechanical Engineer, I would absolutely love to see something like this (or Freecad/OpenSCAD/etc) step up to the "Blender level" to functionally compete against Solidworks. Its expensive, its buggy, and it requires a beast of a computer to function in any semi-respectable way.
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?
I speak from two types of experience - both a user of CAE and a developer of CAE.
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.
Your comment is incredibly insightful, more than many people will realize.
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.
Nobody pays for usability. They pay for service contracts. Then it's the vendor's problem to keep that hunk of junk running.
Suppose that there would be an open source CAD software that does all the basic things right (like Blender). I agree with you that probably nobody would pay big money for that. That's one reason why it doesn't exist today. But suppose that it exists. Why then would all those "plugin makers" invest in a specific proprietary software when they could extend the open source software instead? Why would users want a proprietary software when they could use the open source software instead?
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.
Or, to make a directly relevant parallel, the adoption of Blender. It used to be a niche open source tool whereas any self respecting professional used Maya or 3DS Max, and Adobe products. Now it ate the entire visual effects and video game industries.
Blender provides much of the value of its competitors. A purely CAD tool does not. You have to solve the other problems primarily, while also having CAD. Otherwise, it's like having a text editor when no programming languages exist. What is your business going to do with that?
> Otherwise, it's like having a text editor when no programming languages exist.
You mean a bit like an operating system without a kernel...?
I think you’re fighting a straw man? There needs to be an open-source integrated CAD/CAM environment, like Fusion 360 is. That's what the OP in this subthread is asking for.
That wish is already granted
https://wiki.freecadweb.org/Path_Workbench
My thesis is that the bigger challenge is "economic", not technical.
Contributing to open source CAD would be economically stupid. Vendors know exactly how big the market is. Most sales are "conversions", not first-time buyers. Open source would be an exit ramp for their customers.
To add to this: many CAD products share the same underlying "engine" that computes the geometry of intersections, unions, surfaces of revolution, chamfers, bevels, etc...
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...
"drafting is a low-value activity " "low-value workers".
...
...
??
Drafting doesn't pay well. It's an entry-level position.
Is drafting even a separate role anymore. Most engineers seem to just do it themselves?
Cad software often includes simulation stuff which requires an engineers mind.
*Dollar value
CSG and CAD are just really hard to get right from scratch technically, with lots of math and edge cases and a massive number of features and optimizations you need to implement to hit minimum viability. Add to that the UI on top of the underlying geometry engine is inherently complicated and is a considerable software engineering problem in its own right. Plus the big players have so much momentum and offer free/nearly free (in terms of cost) options that are really slick and powerful e.g. Fusion360 or OnShape. Blender and KiCAD are examples of similar semi-niche professional tools that have been successful against similar barriers, but I still am not optimistic. Solvespace is cool though and that's the one I'm praying for, personally.
>> Solvespace is cool though and that's the one I'm praying for, personally.
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!
Licensing notwithstanding, it'd be cool if we could find a way to collaborate. I just learned about solvespace this past year and kudos on your progress.
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.
>> I just learned about solvespace this past year and kudos on your progress.
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.
I'd be keen to be party to this - off the back of the recent Fusion 360 fiasco i've met a few others interested in this.
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.
I'd like to get some kind of OSS CAD group going but I'm not sure how much collaboration we could really do. FreeCAD uses OCCT, Solvespace uses it's own thing, and I think BRL-CAD uses its own thing (several of them). Then there are things like gcad3d https://www.gcad3d.org/ which has its own hand written STEP reader/writer which I'd love to borrow some day.
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.
It's both a social and technical issue.
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).
> 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.
First I have heard of Solvespace so a naive zen-mind question.
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?
This is, in spirit, what Solvespace does--although like the other reply here says with extruded 2D.
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:
>> 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?
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.
Fusion360 keeps getting worse and worse, they revoke features and jack the price every few months. At some point open source becomes the better value, at least there you know features won't be stolen or the price increased without notice
I gave up on Fusion360 when it told me that the STL exporter wouldn't work without a cloud connection. The app itself works well enough offline, so this seems like a bizarre omission. Surprisingly there are places in the world with 3D printers, but poor to no internet access. In the past Autodesk's servers have also crashed and people have been unable to export models that weren't previously online.
Yeah to be fair I never actually liked Fusion 360 personally. I don't find it super intuitive, but it is quite powerful and polished and I know some people who use it professionally and can do magic in it. OnShape really is perfect to my tastes in terms of being super intuitive yet powerful, but the cloud aspect gives me heartburn. Part of me hopes Autodesk locking down what used to be very generous license terms on F360 might spawn more OSS work to replace it. Similar crackdowns on Eagle were what motivated a lot of the improvements to KiCAD in the last several years that really took it over the line to being a tool I think is legitimately competitive.
Have you tried Shapr3D? It is really intuitive to use. The downsides seem to be (1) it's CAD-only and you have to export to another tool to do analysis or manufacturing steps, and (2) price. But there's a free version to play around with.
Yeah Fusion360 is incredibly slow on my M1Max, and does terribly bugging things like spam launchdarkley 2 MILLION TIMES if you dns block it…
Any alternatives you'd recommend?
No, I have been looking extensively trying to find a decent option. Possibly Alibre through a VM? Solid edge is another possibility, still a subscription service though.
The CAD geometry kernel is the problem. It needs to handle a ton of different features and gets very complex very quickly. FreeCAD uses OpenCASCADE which is also used by quite a few other programs. This kernel dates back to the 90s and is supported by a company.
See: https://wiki.freecadweb.org/OpenCASCADE https://en.wikipedia.org/wiki/Open_Cascade_Technology
This completely, OpenCASCADE is just not a good enough foundation to build something as powerful and stable as SolidWorks on, and I'm not convinced it could become one. It would take 10s millions dollars and many years to build a new geometric kernel that would allow an open source CAD package to compete at the same level as the "Pro" packages. That would require a massively collaborative effort in the engineering community lead by a company (or two) with deep pockets and an agenda!
I believe an initiative backed by a group of large university, national lab, DOE, etc would also be sufficient. Particularly if it was written in say Julia where non-C++ experts (aka grad students) could participate then it could grab a lot of attention from various research labs. Then you could have a winning formula without a FAANG type company.
The problem is incentives. The work necessary to bring a code base like this into production level and maintain it: be realistic - this will not be done by grad student labor without significant supervision, regardless of language. This is many times the effort needed to show "it works" once.
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?
We heard similar comments about linux and GNU a few decades ago.
And IBM and RedHat both poured literally billions into it to make it work at the level it does today, which underscores the point. And there have been billions more poured in from a lot of other corporate groups.
Yeah. Sometimes someone brilliant does something hard for the good of humanity though. I'm think specifically of that guy who wrote DXVK back in the mid 2010s. He basically made gaming on Linux possible.
He is certainly brilliant (I remember how quickly it went from showing a single triangle to actually having working games), but was quickly hired by Valve to work on it full-time.
Yeah, it was nuts. Us Linux gamers were all upset at CDProjekt Red for the bait and switch on the Linux support for Witcher 3, and then, blam DVXK suddenly made that irrelevant. And then so much more!
...and at the same time, GNU was making the same comments about CAD software. It's been on the list of desired projects for GNU since about 1990 - a CAD program comparable to AutoCAD.
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.
There was discussion a few years ago about adding CAD to the list of free software priority areas, to direct talent and energy where it's needed. That would likely help. Finding ways to leverage existing efforts too. BRL-CAD has been working bottom-up with a focus on analytic correctness, capability, hybrid representation. FreeCAD has been working top-down with a focus on usability and parametric interactive editing. Both will likely get there eventually tailored to different markets.
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.
I'm not sure if "OpenCASCADE is just not a good enough" in the architectural sense or if they just don't have the manpower. When I looked into some bugs a while ago it sounded like "yeah, we've know this bug for years, we would like to work on it but don't have the manpower right now". Just adding outside contributions to such a project is probably also not possible because the components interact in many ways and you have great potential to introduce a lot of subtle bugs.
I have been really pleased to see Freecad's steady improvement, and I think it's only been a few years since Blender reached the the point that it was competitive with the $$$ modellers / renderers, especially from a UI standpoint. So, I'm hopeful that in a few more years, Freecad will reach "Blender level" where it really competes with SolidWorks. One big step in that direction will be for them to pick one of the assembly constraints plugins and incorporate it as a first-class feature.
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.
Agreed. FreeCAD is coming along at a good pace. One of the devs (RealThunder) maintains a development branch which fixes the topological naming problem, which was probably FreeCAD's main weakness. It's already very usable; once that fix gets merged into the main branch I think they'll be ready for the 1.0 release.
There's a double problem: CAD needs really good UI ergonomics, and the underlying computational geometry kernel needs to have stable predictable results. These are both fundamentally really really hard, and a contribution at a time model makes them even more difficult.
Working with solid geometry and boundary representation structures is immensely more complicated and affects everything from dev velocity to GUI design to usability to acquiring devs. Content modelers (e.g., Blender) deal with considerably simpler geometry representations that are not typically valid or easily verifiable for engineering purposes. That's why it's very non-trivial, decades worth, to turn something like Blender into a CAD tool. Even seemingly simple features like CAD converters can take years of effort. BRL-CAD's primary investment has been on geometric analysis (e.g., solid ray tracing) and it's unparalleled in that regard, but that's a niche audience without better usability.
i spent thousands of hours working on one of those open source CAD projects, and i made about 100 dollars.
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.
Our company wrote C++ and Ruby wrappers around BRL-CAD a number of years ago for scripted CAD, here is the tutorial for the radio example:
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:
That radio tutorial conversion is awesome.
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.
Thanks! That is the right repo. If you want to use it, I hold the copyright and we could relicense it.
"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)
It looks like your e-mail was the victim of my paternity leave... it's still in my inbox. I do recall Dr. Rai commenting on your post, but didn't get a chance to explore it in any detail at the time.
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.
> It looks like your e-mail was the victim of my paternity leave
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!
I used this in 1999 or so when I had just started out using linux. It was a huge pain to get running. It was for US citizens only or something, and I had to have my parents write to the government requesting the decryption key for the installer. It may have required something crazy like a fax.
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.
> 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.
This is what kept me away from it. You won't have many users when you encrypt your files and the user has to request decription keys from .mil mail addresses.
Silly me thought this was something interesting about the Brazilian Real - Canadian Dollar exchange rate!
I thought exactly the same thing!
Came here to say this :-)
I once worked as a developer for Pro/Engineer, and sometime after that, I was on the user side using BRL-CAD. I can't speak to the quality of the product these days, but at the time, BRL-CAD was achingly slow and riddled with bugs. Using it for my day-to-day work made me want to quit my job, and I left as soon as I had something more promising lined up. I am sorry to sound like I'm unfairly judging BRL-CAD. Perhaps we were using it for something it was not intended to do, or not the way it was meant to be used. I knew my way around the Pro/E interface and it was miles ahead of BRL-CAD. But even CADDS-IV was better than BRL-CAD. I can only speculate that being government-funded, the dev team for BRL-CAD had to make brutal decisions regarding when the feature set was "good enough," because they were working with a very limited budget tied to specific program goals. I don't know. I do know that using BRL-CAD was hellish back in the day.
Isn't Pro/E a b-rep cad?
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".
Just a point of clarity, BRL-CAD now also supports BREP and is technically a hybrid modeling system.
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.
Thanks for the very detailed reply. Evaluating NURBS is useful, but you piqued my interested in the reverse operation. For a moment I almost had the impression we could specify CSG operations based on features extracted from the BREP reconstruction (that would be a game-changer!).
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.
Did you have many different problems with BRL-CAD or was it connected to specific features?
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.
Since FreeCad 0.19 I didn't have any crashes, previously I couldn't even finish simple objects without it crashing. I'm now a happy user, previously I didn't even want to touch it.
Yeah, I have the feeling that it's gaining momentum.
> Using it for my day-to-day work made me want to quit my job
Funny that. Working with Creo on a day-to-day basis makes me want to quit my job.
This comment would increase tremendously in value if you said something about which version of BRL-CAD you used.
Unfortunately I have forgotten the version. This was in the early 90s.
> The BRL-CAD source code repository is the oldest known public version-controlled codebase in the world that's still under active development, dating back to 1983-12-16 00:10:31 UTC.
Wow.
Another interesting fact:
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:
Another fun fact, BRL-CAD was started by Mike Muuss, author of the 'ping' networking tool. Brilliant computer scientist. Also, while it's evolved, the codebase predates nearly everything .. ansi c, c++, tcp/ip, opengl, version control, .. actively developed and funded since 1979.
> version control
/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
Haha, yes, that is technically correct, and the best kind. I probably should have qualified with an ambiguous "modern version control" or simply said it predates "RCS" (1982).
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.
BRL-CAD was open-sourced in 2004. MIT Scheme was released as free software in 1986 after being started somewhere near 1979 (which was about the time I started programming in Basic, using the TRS-80 and Apple II). The initial revision of the MIT git repo is dated December 1986--I think it started in RCS. The original license was some variation of the MIT one, which requested that changes be sent back to the team if at all possible, with a request to tell them what the use was. They changed to the GPL around release 7 or 8.
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.
The point of which, looking back at this comment, is that I'm older than BRL-CAD. :)
Was gonna ask why not link the homepage instead but apparently the wiki is linked as About page from the project's homepage.
That's honestly not a bad idea in general. Wikipedia does a better job describing most software than the landing page typically does. That said, BRL-CAD seems to be an exception and describes itself very well in large text above the fold! 10/10