铭记于心 - @JessFraz
PDF铭记于心
机械 CAD 的新纪元
是时候摆脱数十年前的设计了
Jessie Frazelle
CAD（计算机辅助设计）自 20 世纪 50 年代就已出现。第一个图形 CAD 程序 Sketchpad 出自麻省理工学院 [designworldonline.com]。从那时起，CAD 已成为设计和制造硬件产品的必要工具。如今，CAD 有多种类型。本专栏重点介绍用于机械工程的机械 CAD。
深入研究计算机图形学的历史，揭示了最雄心勃勃和臭名昭著的工程师之间的一些有趣联系。伊凡·萨瑟兰（Ivan Sutherland）因 Sketchpad 于 1988 年荣获图灵奖，他的学生是埃德温·卡特穆尔（Edwin Catmull）。卡特穆尔和帕特·汉拉汉（Pat Hanrahan）因其对计算机图形学的贡献于 2019 年荣获图灵奖。这包括他们在皮克斯构建 RenderMan [pixar.com] 的工作，该软件已授权给其他电影制作人。这导致了硬件、软件和 GPU 的创新。没有这些创新者，就不会有机械 CAD，动画电影也不会像今天这样复杂。甚至不会有 GPU。
几何建模随着时间的推移发生了巨大的演变。实体最初被建模为线框，通过其边、线曲线和顶点来表示物体。这演变为使用面、曲面、边和顶点的曲面表示。曲面表示在机器人路径规划中也很有价值。线框和曲面表示仅包含几何数据。如今，建模包括拓扑信息，以描述对象如何被边界和连接，并描述其邻域。（点的邻域由包含该点的点集组成，在该点集中，人们可以在任何方向上移动一定距离而不会离开该集合。）
OpenCascade、Parasolid 和 ACIS 都是边界表示 (B-rep) 内核。B-rep 模型由几何和拓扑信息组成。拓扑信息因所使用的程序而异。B-rep 文件格式包括 STEP（产品模型数据交换标准）、IGES（初始图形交换规范）、NX 的 prt、Solid Edge 的 par 和 asm、Creo 的 prt 和 asm、SolidWorks 的 sldprt 和 sldasm、Inventor 的 ipt 和 iam 以及 AutoCAD 的 dwg。
视觉表示 (vis-rep) 模型的数据大小往往比 B-rep 模型小得多。这是因为它们不包含那么多结构或产品管理信息。Vis-rep 模型是几何形状的近似值，由大量的平面多边形组成。Vis-rep 文件格式包括 obj、STL、3D XML、3D PDF、COLLADA 和 PLY。
CAD 程序倾向于使用 B-rep 模型，而动画、游戏开发、增强现实和虚拟现实倾向于使用 vis-rep 模型。然而，两者经常互换使用。例如，如果您要使用 B-rep 模型进行制造，但想将其加载到 Apple 的 ARKit 中进行一些动画，您首先需要将其转换为 COLLADA，一种 vis-rep 文件格式。从删除所有 CAD 数据开始，文件应该已经小了一些，但如果您想使其更小，您可以调整各个零件网格上的多边形计数。
今天用来构建的工具是在巨人的肩膀上支持的，但可以做很多事情来使它们变得更好。在某些时候，机械 CAD 失去了它的一些创新根基。让我们深入探讨当今存在的 CAD 程序的一些问题，看看如何使它们变得更好。
单线程
由于大多数 CAD 内核都是在 80 年代的核心基础上构建的，因此它们不适用于现代系统。即使是最新的 CPU 或 GPU 也不会对性能有太大帮助，因为这些程序中的大多数都是单线程的，或者具有单线程方面，并且没有 GPU 意识。OpenSCAD 和所有基于 CGAL（计算几何算法库）构建的东西都是单线程的。当然，其中一些内核自 80 年代以来已经更新，但它们的根仍然与它们的前身息息相关。（我相信有很多东西可以从这些代码库中学到，但作为一个见过许多旧代码库的人，我知道这可能会导致危险的道路。）
这并不意味着所有 CAD 内核都完全是单线程的。Parasolid 是多线程的，但这仍然意味着如果您要导入或导出为 Parasolid 以外的文件格式，您可能刚刚切换回单线程进程。另一个多线程内核的例子是 ImplicitCAD [implicitcad.org]，它是用 Haskell 编写的。
使整个 CAD 程序多线程化的问题之一是不同的文件格式。例如，STEP 文件，其格式可以追溯到 80 年代 [iso.org]，几乎强制要求单线程进程。（此外，STEP 文件不能按顺序读取；它必须加载到内存中，然后解析。）大多数参数化 CAD 操作都是单线程的；然而，开源项目 SolveSpace [solvespace.com]，它使用 NURBS（非均匀有理 B 样条），具有一些并行操作。
重复
在软件开发中，指针用于获取内存地址的内容。这允许用户反复引用相同的内容，而无需复制内容本身。
一些使用 CAD 构建的产品可能永远不会复制其模型的一部分——这对他们来说是幸运的！对于 CAD 设计中确实有多个相似零件的人来说，大多数 CAD 程序都在创建这些零件的非常昂贵的副本。
例如，想象一下服务器机架的模型。在 SolidWorks 以及许多其他行业范围的 CAD 程序中，复制零件的默认方法（使用复制和粘贴）是将子模型的全部内容复制到新模型。因此，如果您的服务器机架中有 32 个滑轨，并且在 SolidWorks 中使用默认复制方法，则您将拥有 32 个完全相同的模型的单独副本。这非常昂贵。每个滑轨内部都有更多的模型，然后这些模型也有子模型。这呈指数级增加了内核和程序的工作负载，以便首先加载您的模型，因为程序不知道这些都是相同的东西。
从软件开发中吸取教训，您真正想要的是模型指针的一种形式。在 CAD 世界中，这些被称为实例。然后您可以存储模型的一个副本，所有其他实例实际上只是对原始副本的引用。这还为用户节省了大量时间。想象一下，当滑轨中的零件发生变化时，必须在 32 个不同的位置更新模型零件。一位智者曾经说过：“疯狂的定义是反复做同样的事情，但期望不同的结果。”
SolidWorks 确实提供了另一种更符合指针操作方式的选项，但由于这不是默认选项，因此大多数用户甚至可能没有意识到有更好的方法。默认路径应导致最少的痛苦。产品不应有两种复制方法，而应只有一种。它们应该使默认方法更像指针（或实例）一样工作，直到副本（而非主副本）的几何形状、曲面或拓扑结构发生变化。在这种情况下，应警告用户，这现在将像一个独立于主副本的唯一零件一样工作。或者用户可能错误地打算将这些更改应用于所有副本，在这种情况下，应将更改应用于主副本。
这还有另一个巨大的问题。每个 CAD 程序都有自己实现和引用实例的方式。如果您将设计从一个 CAD 程序导出到另一个 CAD 程序，您很可能仍然有 32 个单独的滑轨，而不是一个滑轨和 31 个对原始滑轨的引用，而只更改了 xyz 坐标。一些程序提供了导入实例的方法，但它们都依赖于导入的文件格式以及它们是否支持该格式。
即使您正在使用实例，您仍然受单线程内核的摆布，并且所有副本都不太可能并行渲染。
版本控制
对于习惯于使用 git 的软件团队来说，能够进行 diff、修复合并冲突以及作为团队并行处理同一文件是非常节省时间的。许多初创公司正在努力将这种能力带入机械 CAD。
今天使用 git 的人希望继续使用 git，而不必在其工作流程中添加另一个工具，而不是为 CAD 重新发明版本控制。今天，无法将 CAD 文件推送到 git 存储库，让几个人修改文件并解决合并冲突。（好吧，也许可以做到，但这将是非常不愉快的。）对于所有致力于解决机械 CAD 版本控制的初创公司来说，这就是他们不得不重新发明轮子的原因。
在内核可以充分利用现代 CPU 和 GPU 的世界中，您难道不能使用人类可读的文件格式，并允许解决合并冲突吗？当您问“什么是人类可读且与 git 配合良好的？”时，首先想到的答案是编程语言。
使用编程语言的另一个巨大优势是：即使您不使用或不想使用 git，也已经有很多不同的人类可读文件版本控制选项。此外，与 GitHub 和其他版本控制工具的集成可以通过 wasm (WebAssembly) 支持进行扩展，以便可以将差异可视化为渲染。
可编程
回想一下服务器机架的例子。如果机架的一部分包含您在 Mathematica 等程序中计算的复杂数学，您将不得不在另一个程序中不断重新评估数学并在模型中更新它。相反，如果您可以在 CAD 产品本身中编程，那么您就可以在一个地方完成所有计算，并且如果方程中的任何内容发生变化，模型将更新。
服务器机架中的每个滑轨都有网络电缆，这些电缆连接到滑轨的背面。使用 GUI，您将很难使这些电缆与滑轨上的连接器完美对齐。有人必须坐在模型前大约一个小时，只是调整每根电缆以使其完美对齐——这非常浪费时间。相反，如果您可以对电缆的对齐进行编程，则可以确保每根电缆都与连接器完美对齐。
如果您想进行网格或拓扑优化，则对编程的需求变得更加迫切。不幸的是，大多数优化是通过 GUI 单击界面实现的，并且考虑到它们定义的复杂性，通常会弊大于利。如今，一些程序允许脚本编写，但它们的 API 是基于 COM（组件对象模型）的，并且正如您所想象的那样，是在 90 年代构建的。不过，他们甚至提供这个功能也很棒。（感谢 AutoCAD，它是我使用过的第一个 CAD 命令行界面。）
对于现代世界来说，最好为每种语言的 CAD 程序生成 SDK 客户端，就像生成 API 客户端的方式一样。这将允许任何人用任何语言进行编程。这将降低入门门槛，因为不需要学习新语言。这将允许在 CAD 程序本身中完成复杂的数学运算，而不是使用 Mathematica、MATLAB 或 Wolfram Alpha。
如今存在一些可编写脚本的 CAD 程序，它们正在为这种转变铺平道路：ImplicitCAD [implicitcad.org]、libfive Studio [libfive.com]、OpenSCAD [openscad.org]、CadQuery [github.com]、FreeCAD [freecadweb.org] 和 ruckus [github.com]。Blender [blender.org] 具有出色的控制台界面。Three.js [threejs.org] 虽然不是面向 CAD 的，但也是 3D 编程语言的另一个很好的例子。Jonathan Blow 的 Jai [oxide.computer] 用于编写系统级代码，是创建一种高度考虑性能的语言的绝佳示例。（这尚未向公众开放，但他对此进行了广泛的讨论。）
机械工程界的大多数人与 GUI 息息相关，因此从 GUI 交互生成代码将是必要的。这与在后端生成代码的 HTML 点击式 GUI 非常相似。这允许想要编写脚本的人编写脚本，而想要点击的人可以点击。两个世界都可以快乐——左侧代码，右侧渲染，就像 markdown 编辑器一样。
如果 CAD 程序和底层内核有 SDK 客户端，您可以想象会出现一个丰富的插件和工具生态系统，就像围绕 VSCode、Vim 和 Emacs 的生态系统一样。用于产品的大多数 CAD 编辑器都是封闭的，不允许这种类型的基于社区的开发和共享。可以为任何用例编写插件：例如，网格/拓扑优化和供应链系统集成。这包括查找零件、创建 BOM（物料清单）和计算模型零件的交货期的功能。今天，这通常在单独的程序甚至电子表格中完成。
支持 command+P 功能的插件将受到欢迎。在大多数程序中，当您想要打印某些内容时，您会点击 command+P。（Creo 可能最接近此功能，但缺乏开放的生态系统。）对于机械 CAD，当您想要打印模型时，底层程序应发现本地网络上（或直接插入到您的机器中）的所有 3D 打印机和机器，并将模型的与每台机器兼容的零件发送到打印。这甚至可以更进一步——在配备机器人的全自动化工厂中，程序应设置并启动模型和所有零件的组装。
说到 3D 打印，让我们看看 STL 文件格式。这种格式是在 1987 年定义的，它的名字来源于立体光刻，第一种增材制造方法。STL 文件以一系列三角形曲面表示几何形状。由于 STL 是一种 vis-rep 格式，因此它不包含有关内部结构、颜色、纹理或 B-rep 格式将包含的任何其他 CAD 数据的任何数据。现代 3D 打印机已经超越了 STL 格式的简单性。例如，要打印全彩模型，用户需要 VRML（虚拟现实建模语言）文件，或与纹理关联的 STL 文件，以便打印机为对象添加颜色和纹理。插件可以确保打印机获得要打印的特定模型的正确数据，而不会造成转换的痛苦，并确保不会丢失任何材料或纹理。
测试
CAD 模型的测试流程通常包括运行模拟。让我们以气流和热量为例。
在软件世界中，在推送代码更新后，通常会在更改上运行 CI（持续集成），让您和您的队友知道您是否破坏了任何内容，或者您的代码是否可以安全合并。CAD 应该以相同的方式工作。如果您对模型进行更改，您的模拟应在 CI 中运行，以让您的队友知道您的代码是否可以安全合并。这些模拟大多数是计算密集型的，因此能够将模拟卸载到云或远程服务器也是理想的。
就像 VSCode 和其他编辑器具有用于将测试卸载到其他计算机的漂亮插件一样，现代 CAD 程序也应该具有相同的插件。
用户体验和设计
在尝试了许多不同的行业 CAD 程序之后，我发现大多数程序都有一个共同的特点：用户界面看起来像来自 90 年代。具有讽刺意味的是，用于机械设计的工具没有考虑其用户界面的设计和体验。大多数 CAD 程序都需要改版，尽管也有一些在界面设计方面做得很好的例外：Shapr3D [shapr3d.com]，一款 iPad 应用程序，具有出色的设计和直观的界面；SketchUp [sketchup.com] 具有直观而美观的设计。
此外，CAD 应用程序需要原生支持 MacOS、Linux 和 Windows。为其特定平台构建的原生应用程序比使用 Electron 等构建的应用程序性能更好。（话虽如此，VSCode 是一款不错的 Electron 应用程序。）特别是对于像 CAD 这样图形密集型的程序，使用底层操作系统图形机制有助于实现最佳性能。如今，CAD 程序只能在特定程序支持的操作系统上使用。此外，大多数程序都使用真正显现其年代的过时 GUI 框架。
Onshape [onshape.com] 通过提供 SaaS（软件即服务）CAD 程序改变了模式。这使得昂贵的计算过程可以轻松地卸载到云端。这是一个真正具有革命性的想法，但它限制了用户离线工作的能力。相比之下，原生应用程序可以离线工作，但也可以在连接到网络时将工作负载卸载到云端。
如果 CAD 程序可以专注于直观的设计，而不会陷入复杂性的陷阱，那么新用户和专业人士都应该能够高效工作。正如我将 Vim 用于副项目和专业工作一样，我希望我的 CAD 工具在构建有趣的玩具和复杂项目时都能同样出色地工作。这种能力很大程度上取决于界面设计和通过插件的可扩展性。
更美好的明天
新 CAD 程序的开发人员需要仔细考虑这些方面中的每一个。没有现有的 CAD 程序解决了所有这些问题。
世界计算机图形学领域的惊人创新在很大程度上归功于伊凡·萨瑟兰、帕特·汉拉汉、埃德·卡特穆尔、约翰·卡马克和许多其他人等杰出人士。我只能希望一些真正革命性的变化将以计算机图形学先驱为渲染、动画和虚拟现实铺平道路的方式，走向计算机辅助设计领域。
硬件行业迫切需要一种现代化的机械设计方法。为现代世界创建的新 CAD 程序将降低构建硬件的门槛，缩短开发时间，并迎来构建的新纪元。
Jessie Frazelle 是 Oxide Computer Company 的联合创始人兼首席产品官。在此之前，她曾在 Linux 的各个部分工作，包括容器以及 Go 编程语言。
版权所有 © 2021，由所有者/作者持有。出版权已授权给 。
最初发表于 Queue vol. 19, no. 2—
在 数字图书馆 中评论本文
更多相关文章
Vinnie Donati - 推动组织可访问性
在本文中，我们将探讨微软如何在整个组织中推动可访问性，并将仔细研究促进包容性文化的基本框架和实践。通过检查诸如意识建设、战略发展、可访问性成熟度建模等各个方面，我们旨在为开始可访问性之旅的组织提供指南。我们的想法是分享我们所学到的知识，希望您可以采纳它，对其进行调整以适应您公司的宗旨，并以一种不仅仅是复选框活动的方式，而是真正融入您的文化的方式来培养可访问性。
Shahtab Wahid - 设计系统是可访问性交付工具
设计系统是为消费者（设计师和开发人员）构建的基础设施，他们致力于应用程序。一个成功的设计系统允许组织中的消费者快速扩展跨应用程序的设计和开发，提高生产力并建立一致性。然而，许多消费者没有准备好为可访问性构建。组织能否使应用程序的可访问性支持构建具有可扩展性、生产力和一致性？本文探讨了设计系统如何成为支持可访问性的重要工具。
Juanami Spencer - 移动应用程序的可访问性考虑因素
在创建移动应用程序时，考虑可访问性至关重要，以确保尽可能广泛的受众可以使用和享受它们。与桌面体验相比，移动可访问性具有独特的考虑因素，但它为那些在日常活动中依赖移动设备的用户提供了巨大的价值。通过牢记这些考虑因素，移动产品开发团队可以更好地支持和改善所有用户的的生活。本文探讨了移动应用程序的一些关键可访问性考虑因素，并重点介绍了 Bloomberg Connects 应用程序在产品和流程中支持可访问性的几种方式。
Chris Fleizach, Jeffrey P. Bigham - 系统级可访问性
本文通过我们使用 VoiceOver 屏幕阅读器实现 iPhone 非视觉使用的工作来说明系统级可访问性。我们重新构想了非视觉使用的触摸屏输入，引入了适用于屏幕阅读器控制的新手势，对于输出，我们添加了对合成语音和可刷新盲文显示器（输出触觉盲文字符的硬件设备）的支持。我们添加了新的可访问性 API，应用程序可以采用这些 API，并使我们的用户界面框架默认包含它们。最后，我们添加了一个可访问性服务，以桥接这些新的输入和输出与应用程序之间的联系。
© 保留所有权利。