"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." -- https://en.wikipedia.org/wiki/BRL-CAD
BRL-CAD was the first project I ever contributed to, very nostalgic to see it on HN suddenly after all of these years.
Back in 2012 I was lucky enough get into the Google Summer of Code program and landed on this project. Everything confused me, I'm pretty sure the only contribution I managed that whole summer was switching out a couple system sort calls for a qsort implementation.
The BRL-CAD team was so helpful and friendly though, I remember having such a fun time tinkering all summer (mostly unsuccessfully) and talking with my mentor about the program.
This is all to say that the BRL-CAD team is great, and some 11 years later they're still apart of that program giving back to the community through mentorship.
Your code refactoring project was important! Eliminating those sys calls, you fixed bad code and addressed security violations. You helped reduce maintenance costs which in turn helped with code auditing efforts
You're always welcome to get involved again! Whether doing code cleanup or picking up a custom project, always happy to see folks come back and work on scratching an itch. Take care, K!
> Since 1979, the U.S. Army Research Laboratory (ARL) has been developing and distributing the U.S. Army Ballistic Research Laboratory - Computer-Aided Design (BRL-CAD) constructive solid geometry (CSG) modeling package for a wide range of military and industrial applications. The package includes a large collection of tools and utilities including an interactive geometry editor, raytracing and generic framebuffer libraries, network-distributed image-processing/signal-processing capabilities, and an embedded scripting language.
In case anyone is wondering, BRL saw a gradual decline since at least 2013, losing half its value in CAD terms over 8 years until mid-2021 - when it started to make some gains.
Also came here wondering just what did those two currencies put together was supposed to mean, and shortly considering whether CAD here could mean an unusual and localized autocad file format.
Love the comment on ther GitHub relating to "make benchmark":
"If the build is successful, you will see "CORRECT" numbers and a
performance summary at the end. The "vgr" line effectively shows you
approximately how much faster your machine is to a VAX 11/780."
Oh, the memories. I still remember signing the export license papers to get this software back in the early 90s (being outside the US this wasn't obvious).
> BRL-CAD has an interactive geometry editor called MGED. It's often the starting point for beginners and allows creation and manipulation of models using commands. When mged is run, it creates 2 windows: a text console for commands and an interactive graphics window. Currently, if you close the graphics window, it quits the application.
You implement your design using BRL-CAD's DSL. It worked very well for a quite simple 3D model I implemented. Many (like me) prefer "coding" their designs instead of using an interactive, mouse-driven GUI.
OpenSCAD likewise is a great system for implementing "simple" models.
The issue comes when you want to take something simple and make it more... nuanced. Adding the chamfers, removing cruft from the design... it feels orders of magnitude harder than just using something purely visual.
If someone were to come to the project with an interest in integrating CAM features, they would not be turned away. Closest has been having someone implement a BRL-CAD-to-gcode converter, which was actually incredibly well-suited to solid modeling. Used ray tracing to perfectly sample and slice the layers.
Devs feel the same way. Modernizing the GUI has been years in development to get necessary infrastructure bits in place. Massive disruption with pandemic and migration to git, but GUI work is now back on top of the priority queue. Qt-based with other major library integrations.
Like a lot of open source communities, participation ebbs and flows, and additional hands are needed to make and maintain distribution binaries for different platforms. The project has recently prioritized usability improvements and that's consuming a lion share of available developer time and resources. If someone wants to get involved and start producing Windows binaries, they would not be turned away.
It's an unfortunate coincidence that "brl" is a common abbreviation for Braille (in fact, it's the contraction for Braille in English contracted Braille itself). So I thought this had something to do with making CAD accessible to blind people.
It's old, it looks old, it's ideosyncratic. It became open source 20 years ago. Did it manage to engage a community during that time? In their "News" page, which is just their Facebook feed, you can see some projects during the last two years but (sorry) nothing remarkable. So, honestly, the project seems almost dead to me but for some reason refuses to die.
Like many open source communities, pandemic had a pretty significant impact, but development and releases are quite active.
New release coming out in a few weeks introduces conversion support for 150 new geometry and terrain file formats. This summer, Physically-based Rendering support is coming to open source CAD for the first time ever. All the while, devs are working on GUI infrastructure, mentoring GSoC, doing academic research, interacting with academia, and doing what they can to help foster an open source CAx community.
Fully agreed, solved problems should be considered dead and invalid so it will have to be solved time and time again, keeping human wisdom ephemeral and constantly eroding /s
BRL-CAD has a very rich and ongoing development history that is not immediately obvious. [1,2] Heavily actively used by gov'ts as it has unique features like validated full shotline solid ray tracing -- granted, not a feature most know, understand, or care about but absolutely critical to others. Development is actively funded annually (just not your priorities).
In total, BRL-CAD today has more than 500 full-time staff-years of effort invested, more than pretty much all other open source CAD combined.
There's simply no PR team, and limited bandwidth to provide support to those that don't contribute in kind. CAD modelers coming out of school are only accustomed to multibillion dollar company products that dedicated highly experienced devs to specific user-facing features under dedicated funding lines.
With open source, skillsets vary wildly and coordination, collaboration, and maintenance are a challenge until a project achieves critical mass. It's something the BRL-CAD community is working hard on, but it's not something that will be quick. Contributors are welcome!
Thanks for the info. I didn't want to rain on your parade but it just doesn't seem very active judging from the homepage. Also, if you want more community involvement you should probably provide binaries for platforms like Mac OS and Windows to attract more end users that may eventually lead to more developer engagement.
The topic has come up and been a point of discussion, especially developing something akin to the ACIS or Parasolid kernels, but open source. In many areas, BRL-CAD's capabilities far exceed what OpenCascade provides, particularly w.r.t. CAE features, and in others it is noticeably lacking (e.g. export to polygonal). Couple years of effort have been invested in developing a new C++ API for exactly this purpose (codename "MOOSE").
Current dev focus is on conversion, rendering, and GUI modernization.
I wonder why do you care about rendering? There are many good open source renderers out there, now. For instance can't you just export the geometry and render with Yafaray?
brl-cad is CSG modeler with some BRep support. Opencascade is a BRep modeler that supports boolean operations. The industry gave up on CSG and went BRep decades ago.
Not entirely true. As an explicit edit method, sure, but several of the big-name non-parametric (i.e., solid modeling) commercial CAD systems are fundamentally still CSG representation under the hood. They just hide it well, typically under the guise of feature edit nomenclatures or editing constraints.
Can find indications it's CSG under the hood if it won't let you directly modify a surface without selecting some "convert to editable representation" option. TinkerCAD is an extreme example that's basically a pure CSG modeler (and probably the most popular CAD system to date, but I digress), but you won't find the term union, intersection, or CSG anywhere in its GUI. Solidworks and NX do a really good job hiding it.
I guess we have a disconnect. I am talking about modeling kernel geometric definitions and data structures. Whether NX has or doesn't have the boolean terms (union, intersect ...etc) doesn't change the fact that parasolid is BRep. Just because parasolid supports boolean operations, doesn't mean it is CSG.
IMHO:
Any shape defined by a CSG modeling kernel can be defined in a BRep modeling kernel. The reverse is not true, short of some kind of 'hack'. BOT(bag of triangles)? Hybrid with mesh modeling?
