oss

坦克在成为图像之前,先是一个问题

8 条来源 4 条一手来源 已翻译 2026年9月8号

正文
约 1980 年,Mike Muuss 操作 Vector General 显示器,屏幕上是 XM1 坦克的数字模型;Earl Weaver 在 PDP-11/70 计算机机柜旁查看一幅大型打印图。

约 1980 年,在弹道研究实验室,左侧的 Mike Muuss 操作 Vector General 显示器,屏幕上是 XM1 坦克模型,Earl Weaver 则在一旁查看打印图。屏幕上的模型用于回答有关车辆实体的问题,生成视图只是它的一项用途。美国陆军档案照片。[8]

照片中的机器正在绘制一辆坦克,真正重要的工作还在图像之外:这辆坦克如今可以被提问。向模型发射一条数学射线:射线进入了什么,在何处离开,两点之间是什么材料,这种材料沿这条射线的厚度是多少?

介绍 BRL-CAD,最短而有效的方式就是从这个问题开始。它是一套开源实体建模系统,工作重心落在制图、照片级真实感和交互式编辑之外。它的核心承诺,是让三维模型精确到足以接受另一程序的查询。一幅图像是一种回答;射线穿过各个具名区域时形成的一系列交点也是一种回答——从历史次序看,后者先出现。

这一区别使 BRL-CAD 至今仍独树一帜。项目现已涵盖 400 多种工具、实用程序和应用,支持构造实体几何(CSG)、NURBS、非流形几何和面片网格,并通过程序库与编辑器开放几何能力。[1] 这篇文章创建当天,它的公共代码仓库仍在接收变更;从 Mike Muuss 于 1979 年着手设计这套架构算起,时间已过去四十多年。[2] 要理解如此古老的系统为何仍能保持内在一致,可以从它所取代的纸面网格说起。

实体模型出现之前,每换一个视角就要再画一张网格

到 20 世纪 50 年代末,美国陆军的易损性与杀伤力分析程序已经可以估算装甲车辆受到的损伤,但输入程序的几何数据仍高度依赖手工作业。面对每一个攻击方向,分析人员都要在工程图上铺设一张四英寸网格,逐格记录假想路径将穿过哪些组件、视线厚度、入射角与出射角,以及材料类型。方向一变,就需要另一张合适的图纸,再沿网格逐格记录一遍。[4]

这种方法有两个彼此牵连的弱点。依靠人工估算,射击线(shotline)文件制作缓慢,也容易出错。更根本的问题在于,图纸的描述止于一个视角,无法容纳一个可推导任意视图的完整物体。分析代码只能读取预先备好的答案,无法回过头来提出新的几何问题。

1967 年,委托数学应用小组(Mathematical Applications Group)开展的研究引入了两项改变这套流程的思路:用实体的布尔组合表示目标,再让数学射线与这一表示求交。计算由此转入软件,但目标描述仍按面向批处理的流程准备。1979 年,弹道研究实验室开始开发交互式工具,因为当时已有的 CAD 软件包都无法在同一套系统中显示、编辑并查询所需模型。[3][4]

Muuss 最初的工作在 1983 年汇成统一的软件包,1984 年公开发布。2004 年 12 月 21 日,BRL-CAD 转为开源项目。[1] 这些里程碑自有分量,更深处的连续性则来自架构:最初的任务要求项目把几何当作计算的依据,其用途远远超出屏幕上的装饰。

组件是关于空间占用的布尔命题

BRL-CAD 的原生语法从基本体开始,包括长方体、圆柱体、圆锥体、椭球体和圆环体等由解析式定义的实体。变换负责调整尺寸、确定朝向并放置它们。布尔并集合并被占据的体积,交集只保留重叠部分,差集则从一个体积中扣除另一个体积。例如,中空外壳可以写成外部实体减去内部实体,省去手工拼接一组表面多边形的过程。[1][3]

这些运算会组成树。叶节点是基本体或较低层的组合,分支说明各体积之间的关系,更高层的组合再把零件装配成系统。几何到了区域(region)这一层,才对应一个可供分析的物理组件:互不重叠的体积可以带有自身标识和材料信息。早期的目标描述流程以不同数据分别定义基本体参数、布尔区域,以及附属于这些区域的组件名称。[4]

因此,这里的“实体”有着严格含义。轮廓能显示物体从一个方向看去在哪里终止;封闭实体可以判断任意一点位于内部还是外部,命名区域则说明该点由什么占据。Muuss 与 Lee Butler 认为,正是这种完整性,让同一个中心模型能够回答体积、重量、截面、热行为或易损性等问题,省去为每项分析重新绘制物体的工作。[5]

CSG 对不同形状的适用程度各异。当工程物体可以拆分成重复体积或参数化体积时,这种表示尤其合适。扫描得到的有机表面、强调造型的车身,或依赖建模历史的现代机械装配体,有时更适合其他表示法。BRL-CAD 随后也扩展到纯隐式 CSG 之外,支持 B 样条、NURBS、非流形和网格几何。[1] SIAM 在 2025 年发布的项目介绍把表示法与转换之间的缺口列为一项持续的工程问题,仍需不断处理。[7]

采用者需要留意这条界线。多种表示并存时,转换仍会损失信息。有些多边形网格保留了可见边界,却丢失了区域所携带的材料含义;有些导入的装配体则缺少当初生成它的约束。只有模型保留了当前问题所需的语义,BRL-CAD 的优势才能显现。

librt 把模型变成程序接口

系统的核心是射线追踪与几何程序库 librt。它的 API 格外清楚地显露出项目的优先事项:应用程序打开一个 .g 几何数据库,选取所需的物体树,为追踪做好准备,以起点和方向定义射线,注册命中与未命中的回调函数,随后调用 rt_shootray()。[5][6]

射线命中后,应用程序会收到沿射线排序的穿越区段(partition)。每个区段都有进入点和离开点,用离开点到射线起点的距离减去进入点到起点的距离,即可得到射线穿过该区域的视线长度。结果还会关联区域标识和表面信息。渲染软件可以把一次命中解释为光照、明暗、反射或透明效果;工程程序可以把同一个几何事件解释为厚度、材料次序、间隙,或其他领域特定事实。程序库负责确定交点,调用它的应用程序负责解释这些交点的含义。[5]

这种分工至关重要。假如射线遍历与某一个渲染器绑定,每新增一种分析,都得重新实现几何引擎。BRL-CAD 把射线与模型求交的能力开放为通用程序库服务,几何数据库由此成为共享的计算工具。历史上的射击线生成器可以从选定方向向车辆扫过一组平行射线,再从交互审查所用的同一模型中取得组件次序、坐标、法向量与厚度。[4]

照片恰好呈现了这条分界。Muuss 坐在显示器前,屏幕上是 XM1 模型;Earl Weaver 站在纸质打印图旁;PDP-11/70 机柜占据背景。[8] 这是一幕早期计算机图形学现场,同时,显示器也是系统面向人的表层,系统还要把精确的空间事件交给其他程序。屏幕上可见的坦克用于检查模型,模型的最终用途还在显示之外。

这套软件包更像工具作坊,区别于单体式 CAD 程序

BRL-CAD 采用了 Unix 式的组合模式。几何编辑器、转换器、射线追踪器、帧缓冲区工具、图像处理程序、数值程序库和分析实用程序各自承担范围明确的工作,又能组合成更大的流程。[3][6] MGED 用于交互式几何编辑,librt 负责模型加载与射线求交,其他程序则负责渲染、检查、转换、基准测试或处理所得数据。

如果人们所理解的“CAD”是一款集特征树、约束求解器、工程图工作台、云账户和厂商管理的文件格式于一身的图形应用,这种形态颇为陌生。BRL-CAD 确有交互界面,但系统的核心是一套可复用的几何技术栈。对于编写专用分析工具的开发者,几何数据由此摆脱了鼠标操作的限制。对于只想按常规参数化方式创作零件和装配体的设计团队,系统的功能范围常会超出实际所需,团队还要适应一套差异很大的工作语言。

同一段历史也解释了项目为何采取保守的工程立场。HACKING BRL-CAD 介绍了一套回归测试:将运行时行为与已知结果比较,尤其关注射线追踪;数值一旦变化,便按失败处理,直到旧结果被证明有误。[6] 这样做源于下游程序对数值结果的依赖:射线是否在某一特定距离进入区域,会直接影响分析。在这种条件下,几何内核的细微变动就是接口变动,即使渲染图看起来完全相同。

近年的开发仍遵循这一要求。SIAM 2025 年的文章把 librt 描述为负责加载几何、划分空间以及计算射线与目标交点的引擎,并提到空间数据结构、缓存行为、CPU 性能和分布式计算方面仍有工作在推进。[7] 底层代码可以持续更新,因为概念上的分界始终稳定:准备模型,让查询穿过模型,再把几何事实返回应用程序。

BRL-CAD 的适用范围与局限

当团队需要可供工程分析的实体几何,并计划以程序直接调用时,BRL-CAD 的价值最为突出:例如开展定制射线计算的研究团队、长期维护 CSG 数据库的团队,或必须在不同平台间保留材料区域和可重复求交行为的工程师。在这些工作中,开源让模型使用者能够一并检查算法、文件处理方式、数值假设和回归测试套件。

若小型产品团队的实际需求集中在主流机械制图、供应商互操作性和熟悉的参数化装配流程,主流机械 CAD 会更贴近需求。几何答案与经验证的物理结论之间也仍隔着模型质量与物理验证。即使射线与体积精确求交,也无法据此排除体积标记错误、数据过时、与另一区域重叠、缺少间隙或材料分配错误等情况。早期陆军手册用大量篇幅讲解目标描述的制作与标准,原因正在于,查询能力提升之后,瓶颈会移向模型保真度,并继续存在。[4]

因此,严肃的评估应从一个有代表性的物体和一个真实问题开始,功能导览可以放在其后。团队能否在保留含义的前提下编码所需实体与区域标识?应用程序能否取得预期的穿越区段、相应的进入点和离开点,以及厚度?转换测试、容差测试、重叠检查和单元测试能否发现真正要紧的错误?已知答案能否固定为回归测试用例?若流程止于一幅赏心悦目的渲染图,这次评估就错过了 BRL-CAD 存在的缘由。

这个缘由经受住了时间。许多图形系统都能让坦克看起来像坦克,BRL-CAD 的诞生则源于分析人员对另一种能力的需求:让模型说明一条路径在内部穿过了什么。因此,这篇项目介绍回到开头处收束,落点越过显示器上的图像,来到送入实体的下一个问题。

来源

  1. BRL-CAD 项目,“About BRL-CAD”——官方概述,介绍支持的表示法、布尔运算、工具数量、用途、可移植性,以及 1979 至 2004 年的项目时间线。
  2. BRL-CAD,brlcad 源代码仓库——公开代码现状、提交历史、构建系统、测试和项目活动。
  3. Lee A. Butler 与 Eric W. Edwards,BRL-CAD Tutorial Series, Volume I: Overview and Installation,美国陆军研究实验室报告 ARL-SR-113,2002 年——项目起源、采用 CSG 的理由、程序库和 Unix 式工具组合。
  4. Paul H. Deitz 与 Keith Applin,Practices and Standards in the Construction of BRL-CAD Target Descriptions,美国陆军研究实验室报告 ARL-MR-103——手工绘制的四英寸射击线网格、CSG 目标描述、射线追踪求交,以及向交互式系统的转变。
  5. Michael J. Muuss 与 Lee A. Butler,“Combinatorial Solid Geometry, Boundary Representations, and Non-Manifold Geometry”——实体模型语义、以分析为中心的设计,以及 librt 的准备、回调和穿越区段接口。
  6. BRL-CAD 维护者,HACKING BRL-CAD——系统架构、.g.asc 文件、librt、源代码布局、射线发射示例和回归测试要求。
  7. Aaron Hagström,“BRL-CAD: An Open Source Solid Modeling System From the U.S. Army”,SIAM News,2025 年 9 月——独立项目介绍,涵盖当前应用背景、表示法难题和射线追踪器现代化。
  8. Wikimedia Commons,“An M1 Abrams tank, being viewed using 1980 CAD software, run on a PDP-11/70”——美国陆军档案照片,画面中有 Mike Muuss、Earl Weaver 和约 1980 年的 XM1 模型。
Previous F Prime 为飞行软件配上类型化线束,时钟仍由任务方掌握 Next SQLite 把代码交给所有人,提交权依然稀缺

Recommended In oss

Matched by subject and format