ブラウザ向けローカルファーストCADプログラム CADmium

 (mattferraro.dev)
1 ポイント 投稿者 GN⁺ 2024-05-22 | 1件のコメント | WhatsAppで共有
  • CADmiumはブラウザで動作するオープンソースの3DパラメトリックCADを目指していたが、現在は中止されており、GitHubリポジトリはアーカイブとして残されている
  • 設計の中心は、2D制約ソルバー、b-repカーネル、履歴追跡、3D UI、ファイルフォーマットを新しく組み合わせつつ、既存のCADユーザーにとってなじみのある体験を維持することにある
  • 2D制約解決では、巨大な行列を一度に解く代わりに、ばね-質量-ダンパーの物理シミュレーションのように反復収束させる方式を構想している
  • b-repカーネルにはRustベースのオープンソース Truck を活用しようとしており、WebAssemblyとJavaScriptバインディングのおかげでブラウザ実行に適していると見ていた
  • ファイルフォーマットはJSONとJSON Linesベースのテキスト中心形式を志向し、CLI、git-diff、スクリプト修正、コラボレーション・補助ツールのエコシステムを想定している

プロジェクトの状態と目標

  • CADmiumは新しいオープンソースCADプログラムを作ろうとしていたプロジェクト
  • 現在プロジェクトは中止されており、GitHubリポジトリはアーカイブとして提供されている
    • 配布は維持されていない
    • PRは受け付けていない
    • Discordは残っているがアクティブではない
  • 目標としていた3DパラメトリックCADの構成要素は5つ
    • 2D制約ソルバー
    • b-repカーネル
    • 履歴トラッカー
    • 3Dユーザーインターフェース
    • ファイルフォーマット

2D制約ソルバーへのアプローチ

  • 従来方式では、すべての未知数を大きなベクトルにまとめ、各制約を線形方程式で表現して巨大な行列方程式として解く
  • この方式には、逆行列を求めるには行列が正方行列でなければならないという制約がある
    • 制約が多すぎると行列が縦長になって失敗することがある
    • 重複する制約が互いに両立していても、過剰拘束として問題になることがある
    • 制約が少なすぎると仮定を挿入して解を探すが、モデラーの期待に反してスケッチ要素が遠くへ飛んでしまうことがある
  • 未知数が増えるほど大きな行列方程式は遅くなり、そのため個々のスケッチを小さく単純に保つ慣行が生まれている
  • CADmiumの代替案は、2D制約問題を物理シミュレーションのように扱うこと
    • 各点は質量と速度を持つ
    • 各制約は接続された点に力を加えるばねのように動作する
    • 速度に比例する摩擦力がある
    • 小さな時間刻みでシミュレーションを進めて収束させる
  • 一度に問題全体を解くのではなく、小さな変化を繰り返してばねの位置エネルギーを0へ追い込む
  • 各時間ステップの実行時間はばねの数と未知数の数に線形比例するため、より複雑なスケッチを扱える可能性がある
  • このシミュレーション方式は並列化と相性がよく、compute shaderで実行できる余地もある
  • 過剰拘束の問題では、システムが内部的に整合していれば正常に解け、整合していなければばね同士が妥協点を探す
  • 不足拘束の問題では、無限に飛んでいく代わりに最も近い有効な構成を見つける
  • この方式は不等式制約もサポートできる
    • 長さを1cmより大きく2cmより小さく制限する
    • スケッチ角度を10度から30度の範囲に制限する
  • 閉じた多角形の特定面積を圧力の力として扱うなど、他の力へ拡張することもできる
  • 基本目標は、大半のCADユーザーにとってなじみのある体験を維持することだが、2D制約解決には新しいアイデアを適用する余地があると考えていた

b-repカーネルとTruck

  • 機械CADでは、ユーザーが部品のエッジと面を直接扱う必要がある
  • パラメトリックCADは、部品の境界をデータ構造で直接表現するBoundary Representation、すなわちb-rep方式を使う
    • 立方体は6つのFaceを持つSolidとして表現される
    • 各Faceは4つのEdgeを持つ
    • 各Edgeは2つのPointを持つ
  • 曲面には NURBS サーフェスがよく使われ、自由曲面形状の制御や円錐曲線の正確な表現を可能にする
  • b-repは形状表現だけでも難しく、Union、Intersection、Subtractionのようなboolean operationsを実装する際には難易度が大きく上がる
  • こうしたデータとブーリアン演算を処理するライブラリがb-repカーネル
  • 主な独自CAD企業は自前のカーネルを数十年かけて構築しており、独自カーネルは優れているが高価だと評価されている
  • オープンソースCADではOpenCascadeが事実上唯一人気のあるオープンソースb-repカーネルとして扱われている
    • 無料だが粗く不安定な場合があると評価されている
    • 公式ビルド手順の画面が古いWindows環境のように見える点も指摘されている
  • Truck は新たに開発中のオープンソースRust b-repカーネル
    • GitHubリポジトリが公開されている
    • Rustで書かれており、WebAssemblyへのコンパイルサポートが優れている
    • OS上でもブラウザ上でも動作する
    • JavaScriptバインディングとサンプルを提供している
  • RustがC++より全面的に優れているという意味ではないが、オープンソースプロジェクトにとって重要な利点が多い
    • ビルドツールが強力で使いやすく、文書化も進んでいる
    • 中央集権的なパッケージ管理がある
    • メモリ安全性の保証が多く、並列化をより簡単かつ安全にする
    • コンパイラエラーが親切で、リファクタリングしやすい
  • Truckは約4年続いているプロジェクトで、基本機能はすでに備えていると評価されている
    • .step ファイルの読み書き
    • 固定許容差基準のサーフェストライアングル化
    • NURBSサポート
    • 2つのSolidのIntersectionまたはUnion、単一SolidのNot演算
  • Truckは小さく軽量で、Ricos という会社が開発している
  • NURBSのBが意味するB-Splinesの代わりに、T-Splines をサポートできる可能性もある
    • T-Splinesの特許はAutodeskが保有していたが、数週間前に失効したという
    • 理論上はTruckにサポートを追加できると見ている

履歴追跡とバージョン管理の構想

  • パラメトリックCADは設計のFeature Historyを保存する
    • スケッチ、押し出し、回転などの操作を積み重ねて部品を作る
    • 以前の段階に戻って値を変え、機能を再実行して別の部品を得られる
  • モデルに変数を入力として注入して値を変更すると部品が更新され、モデルがパラメータ化される
  • このアプローチは成功してきたが、Topological naming problem のような弱点があり、パラメトリックCADというパラダイム自体への批判もある
  • 脆弱性を減らすためのアプローチとして Resilient Modeling Strategy がある
    • chamferとfilletはedgeを消費するため最後に配置する
    • Detail featureはCore featureを参照できるが、互いを参照しない
  • CADプログラムがこうしたパターンを強制すれば、最初は制約のように感じられても、設計を再利用・移植しやすくなる可能性がある
  • スケッチにもfeature historyを追加する構想がある
    • 今日のCADでは、円や長方形のような基本フィーチャーを描き、mirror、linear pattern、sketch filletなどで複製・修正する
    • こうした依存グラフは作成者以外には理解しにくく、スケッチを消してやり直した方が早いことも多い
    • スケッチフィーチャーもfeature treeに保存・表示すれば、RMSの考え方を単一スケッチにも適用できる
  • すべてのユーザーイベントをappend-only logとして記録するアイデアも含まれている
    • ログがファイルの単一の真実の源泉なら、タイムスライダーで特定のFeature Historyを再構成できる
    • ファイルを閉じて再度開いた後でも無制限のUndo/Redoが可能になる
    • 過去バージョンから別方向に分岐して、git履歴のような設計試行ツリーを作れる
  • 目標は、あらゆる有効なドキュメント状態を簡単に復元できるCADアプリケーション
    • すべての試行錯誤
    • すべての「最終」成果物
    • 必要性に気づいていなかった過去の状態
  • この構造があれば、部品の複数バリエーションを維持し、toolpath generationやFEAのような下流工程を実行したときの設計状態も記録できる
  • 機械設計のためのgitを作れるなら、機械設計のためのGitHubも作れるのではないか、という構想につながる

ブラウザベースの3Dユーザーインターフェース

  • CADmiumはブラウザでCADを行うことを志向していた
  • Onshapeは道を切り開いたが、実際にはAWSのGPU有効クラウドインスタンス上で動作し、結果をブラウザにストリーミングする方式だと説明されている
    • インターネット接続が切れると、ビューポートを回転させることすらできない
  • TruckはWebAssemblyにコンパイルできるため、CADmiumはブラウザ内ですべてを処理するLocal-Firstアプリになり得る
  • 使用していた技術スタックは次の通り
    • Three.js: 3Dビューポート
    • Svelte: 状態管理とリアクティビティ
    • Threlte: SvelteとThree.jsの接続
    • UIとb-repカーネル間のメッセージ受け渡し
    • Electron: ローカル実行
    • TypeScript、TailwindCSS、Vite など
  • このスタックは、アプリ全体をリアクティブ・宣言的な方法で書けるようにし、データ変更からメッシュ更新までをつなぐ
  • 3D CADアプリは最も複雑なUIの1つなので、小規模チームが良い製品を作るにはフレームワークが多くの作業を肩代わりする必要がある
  • このスタックで動くproof of conceptを作れたため、CADmiumの制約要因はこの部分ではないと見ていた

JSONファイルフォーマットとCLIエコシステム

  • CADmiumはあらゆるものにJSONを使おうとしていた
  • Operation Logには JSON Lines を使う計画だった
  • 部品設計後は、より単純な交換形式へエクスポートできるべきだと考えていた
  • 例示されている形式は、steps 配列に sketch、extrude などの操作を入れるJSON構造
  • CADmium CLIで .cadmium ファイルを .step または .stl に変換する使用例がある
$ CADmium export my_part.cadmium --format stl
  • エコシステムを作るのに必要な2つの要素は次の通り
    • 理解しやすい単純なファイルフォーマット
    • そのフォーマットを扱えるオープンソースCLI
  • テキストエディタで押し出し深さやfillet半径を変更するユースケースがある
  • ISO 10303-21 のような複雑な仕様を読まずに、スクリプトですべてのM5ねじをM6ねじに置き換えるようなユースケースも可能
  • 機械設計向けのGitHubが作られ、実際に使われるようになれば、機械設計向けのGitHub Copilotも想像できる
  • 大規模言語モデルは、複雑な独自バイナリ形式よりも、単純で開かれたテキストベース形式で最もよく機能すると判断している

必要な支援と保留している領域

  • どのアイデアが成功し、失敗するかは分からないが、この分野には小さなグループが製造業に大きな影響を与える機会があると考えていた
  • 必要な支援は次の通り
    • Rustプログラミングと全般的な改善
    • Truckへのパッチのための計算幾何学
    • Three.jsの支援
      • 新しいカメラコントローラー
      • より良いライティング
      • ポストプロセッシング
    • 助成金の機会、または裕福な支援者探し
  • 当面は扱わないが、後で改めて見直したい領域は次の通り
    • ベンチャーキャピタル
    • toolpath generation、つまりCAM
    • Finite Element Analysis、つまりFEA
  • CADmiumのDiscordサーバーは残っているが、プロジェクト状態の案内によればアクティブではない

関連記事

1件のコメント

 
GN⁺ 2024-05-22
Hacker Newsのコメント

  • Mattが作っているものに大いに期待している。世の中にはSolidWorks並みに使いやすいUI/UXを備えたオープンソースのパラメトリックCADが切実に必要だ。
    これまでうまくいかなかった最大の理由は、十分に強力なパラメトリックカーネルがなかったことだと思う。Mattが使っているTruckは、まさに必要とされているプロジェクトに見える。従来はOpenCascadeがほぼ唯一それに近かったが、重要な機能が不足しており、バグや不安定さも大きい。
    TruckとCADmiumが安定したフィレットを手に入れれば、OpenCascadeの正当な後継であり、オープンソースのパラメトリックCADの未来を作るプラットフォームになり得る。

    • 伝道師のように振る舞いたいわけではなく、単に良い非サブスクリプション型のローカルファーストCADが必要なだけだ。
      最近Alibre Atom3Dに移行した。オープンソースではないが、一度だけ200ドルを払えば済む。ホストOSが大きく変わらない限り設計を開き続けられ、ACISカーネル上で動作する。
      「ブラウザファースト」とREADMEの「有料ホスティング版で収益化」という文言を見ると、このプロジェクトが立ち消えになるか、成長するにつれてオープンコアでサブスクリプション必須の製品になり、インストール依存関係やセキュリティ機能が増えて、本当のローカル実行がだんだん難しくなっていくように読める。
    • FreeCADのウィークリービルドは大きく進歩したと思う。最新のメインラインのウィークリービルドにはトポロジカル命名（topological naming）の修正が入ったようだし、Ondselも自分たちのブランチでの良い作業を再び貢献している。
      ウィークリー版とOpenDarkテーマを試してみたが、かなり洗練されて見える。オープンソースCAD界隈は本当に面白い時期に入っているように思う。
    • 「最大の理由は十分に強力なパラメトリックカーネルがなかったこと」だとすると、Parasolidはこれに当てはまらないのだろうか。Plasticityで見た機能は非常に印象的だった。あるいは自由・オープンソースソフトウェアだけの話なのか気になる。
      CADプラットフォームをいろいろ使うほど、汎用CADよりも狭い問題領域に合わせた専用アプリケーションのほうがはるかに有用だという感覚が強まる。SVG/DXF/DWG出力は利点だが、大量生産される機械部品、一度限りの建築、高速道路、50マイルのパイプライン、回路、都市交通計画、アートまで全部処理しようとする図面ソフトウェアは方向を誤っていると思う。
      業界標準の道路設計ソフトウェアを使っているのに、オブジェクトモデルに「道路」が存在しない。水平・垂直・断面の構成要素は互いに分離できず、相互作用のルールも明確なのに、それぞれ独立に定義されている。設計者は、コンピュータにどう表示するかを指示する時間を減らし、成果物そのものについてもっと考えるべきだ。
    • これらのツールに詳しいわけではないが、家の修繕プロジェクトや図式・レイアウト図を描くときにQCADを使ったことがあり、とても満足している。かなり強力そうで、オープンソースでもある。ただしブラウザベースではない。
      CADツールやオープンソースの話題が出るとき、HNでQCADがほとんど言及されない理由が気になる。
      1 - https://www.qcad.org/
    • その通りだ。これはRustに非常によく合うアプリケーションだ。複雑で難しく、必ず正しく動作しなければならない分野だからだ。

  • Solvespaceのメンテナーの一人としていくつか補足すると、2D制約だけでは不十分で、3D制約のほうが良い。C++で書くなら、Dune3DがやったようにSolvespaceの制約ソルバーを持ってくるよう勧めるところだが、Rustが好きならMichael F BryanがRustで書いてブログにまとめた作業を見るとよい。
    https://adventures.michaelfbryan.com/posts/constraints-part-...
    ジオメトリカーネルについては、Solvespaceカーネルに直したいバグが3種類あり、それさえ潰せばブーリアン演算をかなり安定して扱えるはずだったが、時間がなかった。私たちのカーネルは6千行未満なので、学べることは多いはずだ。この件で連絡したければ、同じIDのGmailにメールしてほしい。Truckはしばらく見ておらず、少し停滞していると思っていた。これは本当に難しい問題で、商用の世界でも選択肢は少ない。トリムされたNURBSシェルを三角形分割するだけでも厄介だ。
    履歴/フィーチャーツリーは、FreeCADのトポロジカル命名問題と密接に関わっている。Solvespaceでは、各エンティティを既知のものの集合から生成して扱う。再作成しようとすると、新しいエンティティを作らず、既存のエンティティハンドルを返す。つまり、すべてのエンティティは「何かに由来して」おり、その関係を覚えている。私たちがトポロジカル命名を扱っている部分では完璧に動作するが、Solvespaceのすべての部分がカバーされているわけではない。これは最初から入れておくべきもので、後から簡単に付け足せるものではない。
    それから、CADmiumをどこで試せるのかリンクが気になる。

    • SolveSpaceソルバーを包んだRustラッパーもある。ただし、これをWebAssemblyターゲット向けにコンパイルするのがどれほど難しいかは分からない。
      [1] https://github.com/thekakkun/rust_slvs
    • Solvespaceは本当に素晴らしい。いくつものツールを試してきたが、学習曲線がほどよく、特に機械工学者ではない人にも使いやすく、機能、Linux対応、無料であること、ホスティングサービスのリスク回避まで含めてバランスが良い。
    • 4番は手伝える。
      Github:
      https://github.com/MattFerraro/CADmium
      ここにリンクがある:
      https://mattferraro.github.io/CADmium/
    • 非オープンソースプロジェクトの開発者にGPLコードを持ってきて使えと言ったも同然だ。それは著作権紛争への処方箋に近い。

  • 本当に驚くべき取り組みだと思う。オープンソースEDAが到達したレベルまで、オープンソースの物理CADも行ってほしい。
    こうした行列方程式を解くのは、未知数が増えると遅くなりすぎるので、個々のスケッチは小さく単純でなければならないという通念が生まれる、という話だったが、かなり深掘りしてみると実際には大きな問題ではない。
    FreeCADの制約性能の問題は主に、重複していて不要なGUI配置アルゴリズムに由来し、数百個の制約だけでも崩れてしまう。Eigenの疎QR分解は2200個の制約で18秒程度なので悪くない。50万〜100万個の制約を18秒ほどで処理する疎QR分解ライブラリもある。CADスケッチで数千個を超える制約が必要になる状況は想像しにくい。
    [1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...

    • CADをまったく知らない立場からすると、作者がこうした行列ソルバーを試していないというのは驚き。特に正方行列ではない場合を反復法で解くのは、いろいろな分野で一般的だ。
    • OndselSolverは https://github.com/Ondsel-Development/OndselSolver にあり、疎行列に対する直接ガウス消去法によって、冗長制約の除去と過小制約システムを容易に扱える。
      FreeCADとOndsel ESのアセンブリ制約で使われている。

  • ずいぶん前にAutodesk InventorでCADを学んだが、数時間触って理解できた唯一の無料モデリングソフトウェアはOnshapeだった。この分野ではユーザビリティが本当に大きな問題に見える。
    たとえばFreeCADは、同じことをする方法が何十億通りもあるように見えるのに、結局本当の方法は一つだけ、という感じで、あるチュートリアルでは正しくないモデルが残った。
    素晴らしい取り組みで、難しい問題に見える。
    Repo: https://github.com/MattFerraro/CADmium

    • SolveSpaceは良い。これまで見つけた無料CADの中で、遠隔的にでも使い物になる唯一のツールだった。FreeCADも含めてだ。ただし、ベベルやフィレットのようなかなり大きな機能が欠けている。
    • FreeCADには愛憎半ばしている。
      ほとんどPart Design、Sketcher、Spreadsheetワークベンチしか使っていない。この3つは概ね一緒にうまく動く。ワークベンチ間の相互運用性が悪いので、ほかへ広げるのが怖い。たまにPartワークベンチも使うが、Part Designで使うには内部形式の変換を2回通さなければならず、非常に面倒だ。
      多くのオープンソースCADプロジェクトのどれかが、いつかFreeCADを置き換えてくれることを願っている。
    • Onshapeは性能と使いやすさの面で優れたツールだ。完全な初心者だったのに、3Dプリントした関節付きの実際に動作するロボットアームを設計し、モーターや配置、そのほかの要素を作り、動きまでアニメーションで確認できた。
      実用的ではなかったが、スマートフォン上でもモデルは動作した。
    • SolidWorksの経験が多く、CreoとNXもある程度使った立場からすると、Onshapeはそれらと同等のユーザー体験を提供する唯一の「無料」CADだ。ただしOnshapeの「無料」オプションは今ひとつで、有料オプションは趣味ユーザー向けの価格ではないのが惜しい。
      Fusion360も使えることは使えるが、私が使ったことのある商用パッケージに比べるとユーザー体験はかなりひどい。
      無料CADに望むのは、誰かがCreoの堅牢さと速度を持ち込み、SolidWorksの親切さと組み合わせてくれることだ。最初は機能がかなり限られていても構わない。
    • FreeCADの問題は自分が馬鹿だからだと思っていたが、ほかの人も同じ結論に至っていると知ってうれしい。最近、ほぼ毎晩1〜2時間ずつ3週間、単純だと思っていた出力用の物体を作ろうとしていた。
      流れとしては、80%まで連れて行ってくれるチュートリアルに従い、残りを何とかつなぎ合わせようとし、その基本チュートリアルが残りの20%を終えられない形でプロジェクトを構成していたことに気づき、前の段階を修正しようとしてプロジェクト全体が崩れる、というものだった。これを繰り返した。
      CADでは普通、作業順序がそこまで重要なのだろうか？ 単純な物体だしFreeCADがどれほど難しいはずがある、と思って飛び込んだが、実際には非常に難しかった。

  • この分野に新規参入者が現れ、特に新しいカーネルを作ろうとしている点は興味深いが、成功の可能性は低そうに見える。業界トップクラスのカーネルは、自動車・航空宇宙企業の資金支援を受け、CAGDの博士号保持者とプログラマーたちが何十年もかけて開発してきたものだ。基本的に競争力のある機能セットに到達するだけでも時間がかかるだろう
    それに、どんなユーザー課題を解こうとしているのかも疑問だ。CADユーザーにとってオープンソースが必ず必要なわけではない。予算上の制約はあるだろうが、この分野でのオープンソースは、開発者ツールにおけるそれのようにユーザーに直接見える機能ではないかもしれない。PlasticityはParasolidをライセンスしていても、低価格帯で収益を上げられることを示した
    パラメトリックCADツールを30年以上使ってきたが、OnshapeはCreoやSolidWorksにあるさまざまな問題を解決する、かなり驚くべき解だ。データが飛ばず、ファイルシステムではなく最初からデータベースベースで作られ、無制限のUndoがある、共同作業CAD向けのGoogle Docsのような環境は、人生が変わるほどだ。ただしモデリング機能は、まだ他のツールに追いついている途中だ
    Onshape、Creo、SolidWorksの大きな欠点は、2Dスケッチから始めて3Dオブジェクトへ押し出し・回転・ロフトする構造である点だ。3Dツールは基本構造の追加機能であり、後付けに近い。Plasticity、Rhino、Aliasははるかに3D優先だ
    OnshapeのFeatureScriptは非常にかっこよく強力だが、CADユーザーが自分用のツールを作るには、RhinoのGrasshopperほど良くはない
    CADmiumがどの市場で有料・無料の代替より優れたCADツールになるのか、解決するユーザー課題に集中すべきだ。開発初期だとしても、ユーザーニーズを理解するのに早すぎる時期ではない。オープンソースはそれ自体が目標ではない

    • ブラウザエンジンも、すでに投入された人月が途方もなく多く、新たに始めて追いつくのは不可能だとよく言われていたが、Ladybirdブラウザは実際に大きな進展を見せている
      現代的なツール、古いエンジンから得た学び、そして参入時の負債がないことがあれば、小さなチームでも30年もののソフトウェアと同等、あるいはそれ以上のものを作れる
      小さく献身的なチームなら、新しいパラメトリックカーネルとCADパッケージを作れると思う。特にオープンソースならなおさら可能だ
    • 新しいCADユーザーは、良いオープンソース代替を歓迎するだろう。さらに世界は多様で、誰もが同じ種類や規模のお金を持っているわけではない
      CADユーザーは良いオープンソース代替から大きな利益を得られる
    • オープンソース開発に難しさがあるのは確かだが、オープンソースソフトウェアの利用そのものには欠点がない。その意味を知らない人にも、関心のない人にも、同じようにうまく動く
      一方で、プロプライエタリソフトウェアを避けるべき理由は多く、SaaSならなおさら強い。最近はますますSaaSに向かっていて、このケースもそうだからだ。CADソフトウェアは、多くのユーザーがすでに何百時間もかけて学び使ったあとで、プロプライエタリなシステムが提供条件を変えて痛い目を見る分野だ
      少数派だとは思うが、私にとってオープンソースはそれ自体が絶対的な目標だ。ずっと昔からオープンソースソフトウェアだけを使ってきた
    • Onshape、Creo、SolidWorksは同じカーネルを使っているので、UI/UXが似ているのも驚きではない。Onshapeについては推測だが、会社の来歴を見るとその可能性は高い。RhinoのようなツールはCAD上の3Dグラフィックス寄りなので、自由曲面モデラー優先なのも不思議ではない
      それでも、オープンソースが目標になり得ないという部分はよく分からない。KiCADとAltiumの関係に似ている。Onshapeが提供するものの90%をオープンソースで提供できれば、人々は使えると思う
      コスト面の見方は理解する。SolidWorksのライセンスはおおよそ3,000〜5,000ドル程度なので、ほとんどの企業は実績あるツールにお金を払って使うだろう
      ちなみにOnshapeは、3年以内にMVPを作るまで1,000万ドル未満で作られた。今、新しいCADプログラムを作るのに、数十年分の博士人材が必ず必要だとは思わない
    • 商用CAD業界の大半がParasolidのような単一のプロプライエタリなカーネルと交換ファイル形式に依存しているのは、健全ではないと思う

  • CADカーネルのエコシステムを見事に要約している
    特に「唯一人気のあるオープンソースB-repカーネルはOpenCascadeだが、B-repカーネル界のPontiac Aztekだ。見た目は悪く、基本機能しかなく、壊れることもあるかもしれないが、走りはするし、無料で手に入る」という一文が気に入った
    本当にその通りだ

    • トゥクトゥクのたとえで大笑いした

  • ローカルファーストなら、なぜブラウザでやる必要があるのか気になる
    Solvespaceには単一のダウンロード／実行ファイルであるという利点がある
    また、その制約ソルバーはCADsketcherやDune 3Dのようなプロジェクトで使われている: https://github.com/dune3d/dune3d
    作者は必要な機能をラッパーコードがすべて公開していなかったため、Solvespaceのソルバーを直接使い、生成する方程式の種類に対して十分高速にするため、適用可能な箇所では方程式を記号的に解くようソルバーにパッチを当てる必要があったとのこと
    https://github.com/jay3sh/cadmiumと関係があるのかも気になる
    CADカーネルとしてはManifoldにも触れられていなかった: https://github.com/elalish/manifold/wiki/Manifold-Library OpenCASCADEと同じ欠点が多いと理解しているが、それでも言及する価値はありそう
    このカーネルは以前ここでも議論されていた: https://news.ycombinator.com/item?id=35071317
    完全な履歴と編集可能性が特に興味深く、有望に見える。その履歴を開閉できるパネルに一覧表示し、完了した要素を隠すための展開三角を追加して、現在の作業に集中できるなら、自分にとっては夢がかなうレベル。ただし、3D側を理解できるならという条件付き。これまで試したBRL-CAD、FreeCAD、Solvespace、Alibre Atomなどではすべて失敗し、成功したのはOpenSCADのようなコードベースのツールだけだった

    • ブラウザが必要な理由は、Webブラウザがシステム開発者たちが少なくとも60年間失敗してきたことを成し遂げたから。複数のデバイスでそのまま動くアプリケーションを載せられるプラットフォームを作ったのだ
    • ブラウザ上で動けば、Linux、Mac、Windows、ChromeOS、iPad、スマートフォンのどれを使っていても動作する
      自宅で部品を設計し、職場で修正し、メイカースペースで利用可能な機材で作らなければならないとき、何かをインストールしなくてよいのは大きな利点
    • Manifoldは三角形メッシュライブラリである。CADはNURBSサーフェスを使い、レンダリング時にだけ三角分割すべき
      Solvespaceの三角形メッシュコードをManifoldに置き換えることを検討したことはあるが作業量が多く、本当に必要なのはNURBSのバグを修正してメッシュコードへの依存を減らすこと
      ちなみにSolvespaceの制約ソルバーはFreeCADのAssembly 3ワークベンチでも使われている。最近あちこちに広がっている

  • 3D CADアプリが最も複雑なUIの一つだという点には同意する
    ただし、よい3D CADを小さなチームで作るにはフレームワークが多くの仕事を肩代わりしなければならない、という話には懐疑的。汎用UIフレームワークが3D CADの長期的な解決策になり得るのか疑問
    よいUXでは、パラメトリック3Dモデル、メッシュ近似、隠面消去後の線とパッチへの投影、フレームバッファ内のピクセル、UIウィジェットを同時に考慮しなければならないことがある。フレームワークは情報が簡単に分割でき、サイズも限定的だという仮定を置きすぎている
    プロトタイピングには役立つだろうが、プロジェクトが大きくなると、コアとなる3Dビューポートのインタラクションでは結局フレームワークを捨て、OpenGLまたは類似のものとマウス／キーボードイベントの間をほとんど自前のコードで埋めることになりそう
    ボタンやリストのようなフレームワークは問題ないだろうが、そのような要素でさえ、平均的なアプリより3D CADでははるかに動的

    • 本当の解決策はimguiしかない

  • CADmiumがOpenSCADから抜け出す助けになってくれることを本当に願っている。OpenSCADでは最初は大きく考える必要がなく、単純な言語でモジュールの上にモジュールを積み上げればよい
    問題はOpenSCADにソルバーがないこと。変数はあるが制約はない。変更していると、突然、制約を手で解くためにかなり頭を使わなければならなくなり、ミスを入れやすい
    それでも、別のツールへ移るほど深刻な問題ではない。モデルを始める段階では、OpenSCADはこれまで使ったどのものよりはるかに簡単だと思うから

    • SolvespaceとOpenSCADが合体して、両方の世界の長所を得られたらよいのに
    • OndselはLGPLの3Dアセンブリソルバーを開発した
      https://github.com/Ondsel-Development/OndselSolver
      FreeCADとOndsel ESで使われている
    • FreeCADには組み込みのOpenSCADエンジンがある
      最初はOpenSCADで始めたが、実際の3Dオブジェクトを作るときはFreeCADのほうがはるかに生産的だった。ときには四角形から始めて、線を1本消し、半円を追加したいことがあるが、スケッチを始める前にはそれが分からない場合がある
      OpenSCADでは、必要な形状プリミティブと正確な修正方法をあらかじめ知っていなければならない感じがし、2Dに押し出し・回転を適用するより3Dプリミティブを推奨する点も個人的には気になった
    • Build123Dは見てみたのか気になる
    • もう一つの選択肢はOpenSCAD用のBOSL2ライブラリ。align、attach、anchor演算と、さまざまな便利な演算や部品がある

  • 他の人たちがオープンソースCADに時間と才能を投じているのを見るのはうれしい。OndselではオープンソースCADが非常に重要だと信じており、この領域でのイノベーションを見られてうれしい

    • Ondselについて調べているが、組織と製品を完全には理解できていない。OndselとFreeCADの関係は、CodeWeaversとWineの関係のようなものなのか?