The tank was a question before it was a picture

Mike Muuss, left, works at a Vector General display showing an XM1 tank model while Earl Weaver studies a printout at the Ballistic Research Laboratory, circa 1980. The model on the screen was built to answer questions about the solid vehicle, not only to produce a view. U.S. Army archival photograph.[8]

The machine in the photograph is drawing a tank, but that is not the important thing it is doing. The important thing is that the tank can now be asked a question. Send a mathematical ray toward the model: what does it enter, where does it leave, which material occupies the interval between those points, and how thick is that material along this particular line?

That question is the shortest useful introduction to BRL-CAD. It is an open-source solid-modeling system whose center of gravity is not drafting, photorealism, or even interactive editing. Its core promise is that a three-dimensional model should be precise enough for another program to interrogate. A picture is one possible answer. A sequence of intersections through named volumes is another—and historically, the second answer came first.

The distinction still makes BRL-CAD unusual. The project now spans more than 400 tools, utilities, and applications; supports constructive solid geometry (CSG), NURBS, non-manifold geometry, and faceted meshes; and exposes geometry through libraries as well as editors.[1] Its public repository was receiving changes on the day this article was created, more than four decades after Mike Muuss began the architecture in 1979.[2] To understand why such an old system remains coherent, start with the paper grid it replaced.

Before the solid model, every viewpoint needed another grid

By the late 1950s, U.S. Army vulnerability and lethality programs could estimate damage to an armored vehicle, but the geometry entering those programs was painfully manual. For each attack direction, analysts laid a four-inch grid over an engineering drawing. Cell by cell, they recorded the components a hypothetical path would cross, the line-of-sight thickness, entrance and exit angles, and material type. A new direction required another suitable drawing and another pass across the grid.[4]

The method had two coupled weaknesses. Human estimation made the shotline file slow and error-prone. More fundamentally, the drawing only described a view. It did not contain a complete object from which an arbitrary view could be derived. The analysis code could consume the prepared answers, but it could not turn around and pose a new geometric question.

Research contracted to the Mathematical Applications Group in 1967 introduced the two ideas that would unlock the process: represent the target as Boolean combinations of solids, then intersect mathematical rays with that representation. The calculations moved into software, but target descriptions were still prepared in a batch-oriented workflow. In 1979, the Ballistic Research Laboratory began building interactive tools because no available CAD package could display, edit, and interrogate the required models as one system.[3][4]

Muuss's initial work became a unified package in 1983 and a public release in 1984. On December 21, 2004, BRL-CAD became open source.[1] Those milestones matter, but the deeper continuity is architectural: the original job forced the project to treat geometry as evidence for computation rather than decoration for a screen.

A component is a Boolean claim about occupied space

BRL-CAD's native grammar begins with primitives: analytically defined solids such as boxes, cylinders, cones, ellipsoids, and tori. Transformations size, orient, and place them. Boolean union joins occupied volumes; intersection keeps only their overlap; difference removes one volume from another. A hollow housing, for example, can be expressed as an outer solid minus an inner one instead of as a manually stitched collection of surface polygons.[1][3]

Those operations form trees. Leaves are primitives or lower-level combinations; branches state how their volumes relate; higher combinations assemble parts into systems. A region is where that geometry becomes a physical component for analysis: a non-overlapping volume can carry an identity and material context. In the early target-description workflow, separate data defined primitive parameters, Boolean regions, and the component names attached to those regions.[4]

This is why the word solid is doing real work. A silhouette can show where an object appears to end from one direction. A closed solid answers whether any arbitrary point is inside or outside, and a named region says what occupies that point. Muuss and Lee Butler argued that this completeness is what lets the same central model support questions about volume, weight, cross-section, thermal behavior, or vulnerability without redrawing the object for each analysis.[5]

CSG is not automatically the best authoring language for every shape. It is especially natural when engineered objects can be decomposed into repeated or parameterized volumes. A scanned organic surface, styling-heavy bodywork, or a modern history-based mechanical assembly may fit another representation better. BRL-CAD consequently grew beyond pure implicit CSG to support B-spline, NURBS, non-manifold, and mesh geometry.[1] The project's 2025 SIAM profile frames representation and conversion gaps as a continuing engineering problem, not a solved checkbox.[7]

That boundary is important for adopters. Supporting many representations does not make translations lossless. A polygon mesh may preserve a visible boundary while losing a region's material meaning; an imported assembly may arrive without the constraints that produced it. BRL-CAD's strength appears only when the model retains the semantics required by the question being asked.

`librt` turns the model into an interface

At the center of the system is librt, the ray-tracing and geometry library. Its API reveals the project's priorities with unusual clarity. An application opens a .g geometry database, selects the object trees it needs, prepares them for tracing, defines a ray by an origin and direction, registers hit and miss callbacks, and invokes rt_shootray().[5][6]

On a hit, the application receives ordered partitions along the ray. Each partition has an entrance and an exit; subtracting their distances gives the line-of-sight length through that region. The result also links back to region identity and surface information. Rendering software can interpret a hit as light, shade, reflection, or transparency. An engineering program can interpret the same geometric event as thickness, material sequence, clearance, or some other domain-specific fact. The library determines intersections; the calling application decides what those intersections mean.[5]

That separation was decisive. If ray traversal had been welded to a single renderer, every new analysis would have needed to reproduce the geometry engine. By exposing ray–model intersection as a general library service, BRL-CAD made the geometry database a shared instrument. The historic shotline generator could sweep parallel rays across a vehicle from a chosen direction and recover component sequences, coordinates, normals, and thicknesses from the same model used for interactive review.[4]

The photograph captures this boundary perfectly. Muuss sits at the display with an XM1 model; Earl Weaver stands beside a paper printout; the PDP-11/70 rack fills the background.[8] It looks like an early computer-graphics scene, and it is one. Yet the display is also the human-facing surface of a system meant to hand exact spatial events to other programs. The visible tank is a way to inspect the model. It is not the model's final purpose.

The package is a workshop, not one monolithic CAD executable

BRL-CAD followed a Unix-shaped composition model. Geometry editors, converters, ray tracers, framebuffer tools, image processors, numerical libraries, and analysis utilities do bounded jobs and can be assembled into larger workflows.[3][6] MGED supplies interactive geometry editing; librt supplies model loading and ray intersection; other programs render, check, convert, benchmark, or process the resulting data.

This can feel alien if “CAD” means a single graphical application with a feature tree, constraint solver, drawing workbench, cloud account, and vendor-managed file format. BRL-CAD does have interactive interfaces, but its deeper product is a reusable geometry stack. For a developer building a specialized analysis tool, that is liberating: geometry is not trapped behind mouse gestures. For a design team that only wants conventional parametric part and assembly authoring, it may be needless surface area and a steep change in working language.

The same history explains the project's conservative engineering posture. HACKING BRL-CAD describes regression tests that compare runtime behavior with known results, especially around ray tracing, and treat numerical changes as failures until the previous result is shown to be wrong.[6] That is not mere resistance to change. When downstream programs depend on whether a ray entered a region at a particular distance, a subtle geometry-kernel change is an interface change even if the rendered picture looks identical.

Recent work has not erased that contract. The 2025 SIAM account describes librt as the engine for geometry loading, spatial partitioning, and ray–target intersections, and reports ongoing work on spatial data structures, cache behavior, CPU performance, and distributed computation.[7] The implementation can modernize because the conceptual boundary remains stable: prepare a model, fire a query through it, return geometry facts to the application.

Where BRL-CAD fits—and where it does not

BRL-CAD is most compelling when a team needs analysis-grade solid geometry and intends to program against it: research groups with custom ray-based calculations, maintainers of long-lived CSG databases, or engineers who must preserve material regions and repeatable intersection behavior across platforms. Its open source matters in those settings because the algorithms, file handling, numerical assumptions, and regression suite can all be inspected with the model.

It is a weaker default for a small product team whose real need is mainstream mechanical drafting, supplier interoperability, and a familiar parametric assembly workflow. It also does not turn a geometric answer into a validated physical conclusion. A ray can intersect the volume exactly while the volume is mislabeled, outdated, overlapping another region, missing a gap, or assigned the wrong material. The original Army manuals devote so much attention to target-description construction and standards because better interrogation moves the bottleneck toward model fidelity; it does not abolish the bottleneck.[4]

A serious evaluation should therefore begin with one representative object and one real question, not a feature tour. Can the team encode the required solids and region identities without throwing away meaning? Can an application recover the expected in/out partitions and thicknesses? Do conversion, tolerance, overlap, and unit tests catch the mistakes that matter? Can known answers be frozen as regression cases? If the workflow ends at a pleasing render, the evaluation has missed BRL-CAD's reason for existing.

That reason is remarkably durable. Many graphics systems can make a tank look like a tank. BRL-CAD was built because analysts needed a model that could say what a path crossed inside it. The project introduction therefore ends where it began: not with the picture on the display, but with the next question sent into the solid.

cronfeed.work

The tank was a question before it was a picture

Before the solid model, every viewpoint needed another grid

A component is a Boolean claim about occupied space

`librt` turns the model into an interface

The package is a workshop, not one monolithic CAD executable

Where BRL-CAD fits—and where it does not

Sources

Recommended In oss

The tank was a question before it was a picture

Before the solid model, every viewpoint needed another grid

A component is a Boolean claim about occupied space

librt turns the model into an interface

The package is a workshop, not one monolithic CAD executable

Where BRL-CAD fits—and where it does not

Sources

Recommended In oss

`librt` turns the model into an interface