brlcad

Nice to see other open source CAD development being explored. BRL-CAD has had the pixdiff, bwdiff, and pixcmp tools for a very long time, for very similar purposes:

pixdiff: https://manpage.me/index.cgi?q=pixdiff&sektion=1&apropos=0&m...

bwdiff: https://manpage.me/index.cgi?q=bwdiff&sektion=1&apropos=0&ma...

pixcmp: https://manpage.me/index.cgi?apropos=0&q=pixcmp&sektion=1&ma...

Now this is awesome. Hope iHerb appreciates this as it should will lead to more sales through them. Scraping is always tricky.

Love that you’ve included other nutritional facts. Would be cool to also incorporate review scores and/or taste somehow, however subjective.

Really nice work.

Very cool that it emulates the phosphor "burn" fading away like the original vector graphics hardware. You can see and play the real thing at The Strong National Museum of Play in Rochester, New York.

Boggles my mind when coders don't save everything they've ever written. It's easy to be a digital pack-rat without much consequence.

That said, my first Java 1.02 programs from the 90's still compile and the old jars run surprisingly well too. Color me impressed!

I have the sources to "JHU UNIX" which were a direct fork of one of the earliest BSD's, though I don't recall hearing which. They were recovered off data tapes (and are still in an arcane raw binary format) from the late 70's / very early 80's.

That's fair, but I figured the main page has it big and prominent right now, and does better to explain what GSoC is for anyone out of the loop.

This past week, orgs were announced for the 20th anniversary of the Google Summer of Code. Anyone new to open source (not just students anymore) can submit a proposal to remotely work on an open source project for a few months and get paid. Best advice: communicate early, communicate often.

Cheers!

Disclaimer: GSoC admin and mentor since '07. BRL-CAD, BZFlag, Haiku OS, RTEMS, ... good times.

Plague Inc.

I'd be happy to host the site in perpetuity on one of our dedicated hosts (for free). Have hosted the sites for a number of notable open source communities for decades.

Not quite in the same vein, but the patent for T-splines expires in 2024. Big news for 3D modeling systems.

Really? Fluid solver with no pics?

Tcl's integrated for the long haul, but clock is ticking on Tk. Migration will take a while, but Qt GUI is in the works.

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.

Well said!

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.

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!

[1] https://www.army.mil/article/92288/brl_cad_the_worlds_oldest... [2] https://brlcad.org/BRL-CAD_Bibliography.pdf

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.

The two main graphical applications, MGED and Archer, are both Tcl/Tk so what you're seeing is Tk. Newer GUI work in development is Qt-based.

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.

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!

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.

I've found glTF ( https://www.khronos.org/gltf/ ) to be quite simple. The entire format is encompassed in something like a dozen entity types. Nice visual overview here: https://github.com/KhronosGroup/glTF/blob/main/specification...

Happy Birthday to one of the most awesome but unfortunately named open source projects...

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.

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.

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.

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'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).

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.

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.