- CADmium zielte auf ein Open-Source-3D-Parametric-CAD ab, das im Browser läuft, wurde inzwischen jedoch eingestellt; das GitHub-Repository bleibt als Archiv erhalten
- Im Zentrum des Entwurfs standen die Neukombination eines 2D-Constraint-Solvers, eines b-rep-Kernels, von History-Tracking, einer 3D-UI und eines Dateiformats bei gleichzeitiger Wahrung einer für bestehende CAD-Nutzer vertrauten Erfahrung
- Für die Lösung von 2D-Constraints war statt des einmaligen Lösens riesiger Matrizen ein iterativ konvergierender Ansatz nach dem Vorbild einer Spring-Mass-Damper-Physiksimulation vorgesehen
- Für den b-rep-Kernel sollte das Rust-basierte Open-Source-Projekt Truck genutzt werden, das dank WebAssembly und JavaScript-Bindings als gut für die Ausführung im Browser geeignet galt
- Beim Dateiformat wurde ein textzentriertes Format auf Basis von JSON und JSON Lines angestrebt, mit Blick auf CLI, git-diff, skriptgesteuerte Änderungen sowie ein Ökosystem für Zusammenarbeit und Hilfstools
Projektstatus und Ziele
- CADmium war ein Projekt zum Bau eines neuen Open-Source-CAD-Programms
- Das Projekt wurde inzwischen eingestellt, und das GitHub-Repository wird archiviert bereitgestellt
- Distributionen werden nicht weiter gepflegt
- PRs werden nicht angenommen
- Discord existiert noch, ist aber nicht aktiv
- Die angestrebte 3D-Parametric-CAD-Architektur bestand aus fünf Komponenten
- 2D-Constraint-Solver
- b-rep-Kernel
- History-Tracker
- 3D-Benutzeroberfläche
- Dateiformat
Ansatz für den 2D-Constraint-Solver
- Der bestehende Ansatz bündelt alle Unbekannten in einem großen Vektor und drückt jede Constraint als lineare Gleichung aus, die dann als riesiges Matrixgleichungssystem gelöst wird
- Dieser Ansatz hat die Einschränkung, dass die Matrix zur Invertierung quadratisch sein muss
- Gibt es zu viele Constraints, kann die Matrix zu lang werden und das Verfahren scheitern
- Redundante Constraints können trotz gegenseitiger Verträglichkeit zu Problemen durch Überbestimmung führen
- Gibt es zu wenige Constraints, werden Annahmen eingefügt, um eine Lösung zu finden; dabei können Sketch-Elemente entgegen den Erwartungen des Modellierers weit wegfliegen
- Mit zunehmender Zahl an Unbekannten werden große Matrixgleichungen langsam, weshalb sich die Praxis etabliert hat, einzelne Sketches klein und einfach zu halten
- Die Alternative von CADmium war, 2D-Constraint-Probleme wie eine Physiksimulation zu behandeln
- Jeder Punkt hat Masse und Geschwindigkeit
- Jede Constraint wirkt wie eine Feder, die auf verbundene Punkte Kräfte ausübt
- Es gibt eine zur Geschwindigkeit proportionale Reibungskraft
- Die Simulation läuft in kleinen Zeitschritten bis zur Konvergenz
- Statt das Gesamtproblem auf einmal zu lösen, werden kleine Änderungen wiederholt angewandt, um die potenzielle Energie der Federn gegen 0 zu treiben
- Die Laufzeit pro Zeitschritt ist linear proportional zur Zahl der Federn und der Unbekannten, wodurch sich potenziell komplexere Sketches verarbeiten lassen
- Der Simulationsansatz eignet sich gut für Parallelisierung und könnte auch auf einem compute shader laufen
- Bei überbestimmten Problemen wird das System normal gelöst, wenn es in sich konsistent ist; wenn nicht, finden die Federn einen Kompromisspunkt
- Bei unterbestimmten Problemen wird statt eines Wegdriftens ins Unendliche die nächstgelegene gültige Konfiguration gefunden
- Dieser Ansatz könnte auch Ungleichungs-Constraints unterstützen
- Eine Länge auf mehr als 1 cm und weniger als 2 cm begrenzen
- Einen Sketch-Winkel auf einen Bereich zwischen 10 und 30 Grad beschränken
- Er ließe sich zudem auf andere Kräfte ausweiten, etwa um eine bestimmte Fläche eines geschlossenen Polygons als Druckkraft zu behandeln
- Das Grundziel war eine Erfahrung, die sich für die meisten CAD-Nutzer vertraut anfühlt, bei der 2D-Constraint-Lösung aber Raum für neue Ideen besteht
b-rep-Kernel und Truck
- Im Mechanical CAD müssen Anwender die Kanten und Flächen eines Bauteils direkt bearbeiten können
- Parametric CAD verwendet dafür die Boundary Representation, also b-rep, bei der die Grenzen eines Teils direkt als Datenstruktur dargestellt werden
- Ein Würfel wird als Solid mit 6 Faces dargestellt
- Jedes Face hat 4 Edges
- Jede Edge hat 2 Points
- Für gekrümmte Flächen werden häufig NURBS-Oberflächen verwendet, die Freiformkontrolle und eine exakte Darstellung von Kegelschnitten ermöglichen
- b-rep ist schon bei der Geometriedarstellung schwierig; bei der Implementierung von Boolean-Operationen wie Union, Intersection und Subtraction steigt der Schwierigkeitsgrad stark
- Die Bibliothek, die solche Daten und booleschen Operationen verarbeitet, ist der b-rep-Kernel
- Die großen proprietären CAD-Unternehmen haben ihre eigenen Kernel über Jahrzehnte entwickelt; proprietäre Kernel gelten als gut, aber teuer
- Im Open-Source-CAD-Bereich gilt OpenCascade als der einzige populäre Open-Source-b-rep-Kernel
- Er ist kostenlos, gilt aber als rau und potenziell instabil
- Es wird angemerkt, dass die offiziellen Build-Anleitungen aussehen wie aus einer alten Windows-Umgebung
- Truck ist ein neu entstehender Open-Source-b-rep-Kernel in Rust
- Das GitHub-Repository ist öffentlich
- Er ist in Rust geschrieben und unterstützt die Kompilierung nach WebAssembly sehr gut
- Er kann auf Betriebssystemen und im Browser laufen
- Er bietet JavaScript-Bindings und Beispiele
- Das soll nicht heißen, dass Rust kategorisch besser als C++ ist, aber für Open-Source-Projekte bringt es viele wichtige Vorteile
- Build-Tools sind leistungsfähig, bequem und gut dokumentiert
- Es gibt ein zentrales Paketmanagement
- Höhere Garantien für Memory Safety machen Parallelisierung einfacher und sicherer
- Compiler-Fehler sind hilfreich, was Refactoring erleichtert
- Truck ist ein etwa vier Jahre altes Projekt und wird bereits als mit grundlegenden Funktionen ausgestattet eingeschätzt
- Lesen und Schreiben von
.step-Dateien
- Oberflächentriangulation mit fester Toleranz
- NURBS-Unterstützung
- Intersection oder Union zweier Solids sowie eine Not-Operation auf einem einzelnen Solid
- Truck ist klein und leichtgewichtig und wird von einem Unternehmen namens Ricos entwickelt
- Es könnte auch die Möglichkeit geben, statt der B-Splines, für die das B in NURBS steht, T-Splines zu unterstützen
- Das Patent auf T-Splines lag bei Autodesk, soll aber vor einigen Wochen ausgelaufen sein
- Theoretisch könnte Unterstützung dafür zu Truck hinzugefügt werden
Ideen zu History-Tracking und Versionsverwaltung
- Parametric CAD speichert die Feature History eines Entwurfs
- Durch das Stapeln von Schritten wie Sketch, Extrude und Revolve entsteht ein Bauteil
- Man kann zu früheren Schritten zurückkehren, Werte ändern und die Features erneut ausführen, um ein anderes Teil zu erhalten
- Werden dem Modell Variablen als Eingaben gegeben und ihre Werte verändert, aktualisiert sich das Teil und das Modell wird parametriert
- Dieser Ansatz war erfolgreich, hat aber Schwächen wie das Topological Naming Problem, und es gibt auch Kritik am Parametric-CAD-Paradigma selbst
- Als Ansatz zur Verringerung der Anfälligkeit entstand die Resilient Modeling Strategy
- Chamfer und Fillet verbrauchen Edges und sollten deshalb am Ende platziert werden
- Detail-Features können auf Core-Features referenzieren, aber nicht wechselseitig
- Wenn ein CAD-Programm solche Muster erzwingt, mag das zunächst wie eine Einschränkung wirken, kann aber das Wiederverwenden und Übertragen von Entwürfen erleichtern
- Es gab auch die Idee, Sketches eine Feature History hinzuzufügen
- In heutigen CAD-Systemen zeichnet man Basis-Features wie Kreise und Rechtecke und dupliziert oder verändert sie mit Mirror, Linear Pattern, Sketch Fillet usw.
- Solche Abhängigkeitsgraphen sind für andere als den Ersteller oft schwer zu verstehen, sodass es manchmal schneller ist, den Sketch zu löschen und neu zu beginnen
- Wenn auch Sketch-Features im Feature Tree gespeichert und angezeigt würden, ließen sich RMS-Ideen auf einzelne Sketches anwenden
- Dazu kam die Idee, alle Benutzerereignisse in einem append-only log aufzuzeichnen
- Wenn dieses Log die einzige Wahrheitsquelle einer Datei ist, lässt sich mit einem Zeitschieberegler jede Feature History rekonstruieren
- Selbst nach dem Schließen und erneuten Öffnen der Datei wären unbegrenztes Undo/Redo möglich
- Man könnte von früheren Versionen in andere Richtungen abzweigen und so einen Baum von Entwurfsversuchen ähnlich einer git-Historie erzeugen
- Ziel war eine CAD-Anwendung, in der sich jeder gültige Dokumentzustand leicht wiederherstellen lässt
- Jeder Versuch und Irrtum
- Jedes „finale“ Ergebnis
- Frühere Zustände, deren Wert man damals noch nicht kannte
- Mit dieser Struktur ließen sich mehrere Varianten eines Teils bewahren und auch der Entwurfszustand festhalten, in dem nachgelagerte Prozesse wie Toolpath Generation oder FEA ausgeführt wurden
- Aus der Idee, git für Mechanical Design zu bauen, ergab sich die Vorstellung, dass man dann auch ein GitHub für Mechanical Design bauen könnte
Browserbasierte 3D-Benutzeroberfläche
- CADmium wollte CAD im Browser ermöglichen
- Onshape hat den Weg bereitet, wird in der Praxis aber als System beschrieben, das auf GPU-aktivierten Cloud-Instanzen bei AWS läuft und die Ergebnisse in den Browser streamt
- Fällt die Internetverbindung aus, kann man nicht einmal mehr das Viewport drehen
- Da Truck nach WebAssembly kompiliert werden kann, hätte CADmium eine Local-First-App sein können, die alles direkt im Browser verarbeitet
- Der verwendete Tech-Stack bestand aus:
- Three.js: 3D-Viewport
- Svelte: State Management und Reaktivität
- Threlte: Verbindung zwischen Svelte und Three.js
- Message Passing zwischen UI und b-rep-Kernel
- Electron: lokale Ausführung
- TypeScript, TailwindCSS, Vite usw.
- Dieser Stack erlaubte es, die gesamte App reaktiv und deklarativ zu schreiben, sodass Datenänderungen bis hin zu Mesh-Updates durchgereicht werden
- 3D-CAD-Apps gehören zu den komplexesten UIs überhaupt; damit ein kleines Team ein gutes Produkt bauen kann, muss das Framework viel Arbeit abnehmen
- Da bereits ein mit diesem Stack funktionierender Proof of Concept gebaut wurde, galt dieser Bereich nicht als der begrenzende Faktor für CADmium
JSON-Dateiformat und CLI-Ökosystem
- CADmium wollte für alles JSON verwenden
- Für das Operation Log war JSON Lines geplant
- Nach dem Entwurf eines Bauteils sollte ein Export in einfachere Austauschformate möglich sein
- Als Beispielformat wird eine JSON-Struktur genannt, in der Operationen wie
sketch und extrude in einem steps-Array liegen
- Es gibt ein Nutzungsbeispiel für die CADmium CLI, die
.cadmium-Dateien nach .step oder .stl konvertiert
$ CADmium export my_part.cadmium --format stl
- Für den Aufbau eines Ökosystems seien zwei Dinge nötig
- Ein leicht verständliches, einfaches Dateiformat
- Eine Open-Source-CLI, die dieses Format verarbeiten kann
- Genannt wird auch der Anwendungsfall, Extrusionstiefe oder Fillet-Radius in einem Texteditor zu ändern
- Ebenso möglich wäre ein Skript, das alle M5-Schrauben durch M6-Schrauben ersetzt, ohne komplexe Spezifikationen wie ISO 10303-21 lesen zu müssen
- Wenn ein GitHub für Mechanical Design gebaut und tatsächlich genutzt würde, ließe sich auch ein GitHub Copilot für Mechanical Design vorstellen
- Die Einschätzung ist, dass große Sprachmodelle mit einfachen, offenen textbasierten Formaten weit besser arbeiten als mit komplexen proprietären Binärformaten
Benötigte Hilfe und aufgeschobene Bereiche
- Welche Ideen erfolgreich wären und welche scheitern würden, sei unklar, aber in diesem Bereich gebe es für kleine Gruppen die Chance, großen Einfluss auf die Fertigungsindustrie zu nehmen
- Benötigte Hilfe umfasst:
- Rust-Programmierung und allgemeine Verbesserungen
- Computational Geometry für Patches an Truck
- Unterstützung bei Three.js
- Neuer Camera Controller
- Bessere Beleuchtung
- Post-Processing
- Das Finden von Fördermöglichkeiten oder wohlhabenden Unterstützern
- Bereiche, die vorerst nicht behandelt werden, aber später erneut betrachtet werden sollen:
- Venture Capital
- Toolpath Generation, also CAM
- Finite Element Analysis, also FEA
- Der Discord-Server von CADmium existiert noch, ist laut Projektstatus aber nicht aktiv
1 Kommentare
Hacker-News-Kommentare
Ich freue mich sehr auf das, woran Matt arbeitet. Die Welt braucht dringend ein parametrisches Open-Source-CAD mit einer UI/UX, die so einfach zu bedienen ist wie SolidWorks.
Der größte Grund, warum das bisher nicht gelungen ist, war das Fehlen eines ausreichend leistungsfähigen parametrischen Kerns, und Truck, das Matt verwendet, wirkt genau wie das Projekt, das man dafür braucht. Bisher kam nur OpenCascade annähernd infrage, aber dort fehlen wichtige Funktionen, und es gibt viele Bugs und Instabilitäten.
Wenn Truck und CADmium stabile Fillets hinbekommen, könnten sie die echte Nachfolge von OpenCascade antreten und die Plattform für die Zukunft von parametrischem Open-Source-CAD werden.
Ich bin vor Kurzem zu Alibre Atom3D gewechselt; es ist zwar nicht Open Source, kostet aber nur einmalig 200 Dollar. Solange sich das Host-OS nicht grundlegend ändert, kann ich meine Entwürfe weiter öffnen, und es läuft auf dem ACIS-Kern.
Wenn ich „browser first“ und im README „Monetarisierung über eine kostenpflichtige Hosting-Version“ lese, klingt das für mich so, als könnte dieses Projekt entweder versanden oder mit dem Wachstum zu einem Open-Core-/Abo-Pflicht-Produkt werden, bei dem Installationsabhängigkeiten und Sicherheitsfunktionen zunehmen und echtes lokales Ausführen immer schwieriger wird.
Ich habe die Weekly-Version mit dem OpenDark-Theme ausprobiert, und das wirkt ziemlich polished. Für Open-Source-CAD scheint das gerade eine wirklich spannende Zeit zu sein.
Je mehr CAD-Plattformen ich benutze, desto stärker habe ich den Eindruck, dass spezialisierte Anwendungen für eng umrissene Problemfelder viel nützlicher sind als allgemeines CAD. SVG-/DXF-/DWG-Ausgabe ist zwar ein Pluspunkt, aber ich halte Zeichensoftware, die gleichzeitig massenproduzierte Maschinenteile, einmalige Architektur, Autobahnen, 50-Meilen-Pipelines, Schaltungen, städtische Verkehrsplanung und Kunst abdecken will, für fehlgeleitet.
Selbst in der branchenüblichen Software für Straßendesign existiert im Objektmodell keine „Straße“. Horizontale, vertikale und Querschnitts-Komponenten können nicht voneinander getrennt werden, und ihre Interaktionsregeln sind klar, werden aber trotzdem jeweils unabhängig definiert. Designer sollten weniger Zeit darauf verwenden, dem Computer zu sagen, wie er etwas darstellen soll, und mehr über das eigentliche Ergebnis nachdenken.
Ich frage mich, warum QCAD auf HN fast nie erwähnt wird, wenn es um CAD-Tools oder Open Source geht.
1 - https://www.qcad.org/
Als einer der Solvespace-Maintainer würde ich noch ein paar Punkte ergänzen: Nur 2D-Constraints reichen nicht aus, 3D-Constraints sind besser. Wenn man in C++ schreibt, würde ich empfehlen, wie Dune3D den Constraint-Solver von Solvespace zu übernehmen; wenn man Rust mag, kann man sich die Arbeit von Michael F Bryan anschauen, die er in Rust umgesetzt und im Blog beschrieben hat.
https://adventures.michaelfbryan.com/posts/constraints-part-...
Beim Geometriekern gibt es im Solvespace-Kern drei Arten von Bugs, die ich gern beheben würde; wenn die weg wären, könnten boolesche Operationen ziemlich stabil laufen, aber dafür hatte ich keine Zeit. Unser Kernel hat weniger als 6.000 Zeilen, also kann man daran viel lernen. Wenn du zu diesem Thema Kontakt aufnehmen willst, schreib einfach an dieselbe ID bei gmail. Truck habe ich seit einer Weile nicht mehr angesehen und hatte den Eindruck, dass es etwas stagniert. Das ist wirklich ein sehr schwieriges Problem, und selbst in der kommerziellen Welt gibt es nur wenige Optionen. Schon die Triangulierung beschnittener NURBS-Schalen ist knifflig.
Der History-/Feature-Tree hängt eng mit dem Problem der topologischen Benennung in FreeCAD zusammen. Solvespace erzeugt jede Entität aus einer Menge bekannter Dinge. Wenn es versucht, sie erneut zu erzeugen, erstellt es keine neue Entität, sondern gibt den Handle der bestehenden Entität zurück. Das heißt, jede Entität „kommt von etwas“ und merkt sich diese Beziehung. Dort, wo wir in Solvespace topologische Benennung behandeln, funktioniert das perfekt, aber nicht alle Teile von Solvespace sind dadurch abgedeckt. Das muss man von Anfang an einbauen; später lässt es sich nicht einfach ergänzen.
Und ich würde gern den Link wissen, unter dem man CADmium ausprobieren kann.
[1] https://github.com/thekakkun/rust_slvs
Github:
https://github.com/MattFerraro/CADmium
Hier ist der Link:
https://mattferraro.github.io/CADmium/
Ich halte das für wirklich beeindruckende Arbeit. Es wäre schön, wenn Open-Source-Physik-CAD einmal das Niveau erreichen würde, auf dem Open-Source-EDA bereits angekommen ist
Es hieß zwar, dass das Lösen solcher Matrixgleichungen mit steigender Zahl an Unbekannten zu langsam werde und deshalb einzelne Skizzen klein und einfach bleiben müssten, aber wenn man etwas tiefer gräbt, ist das in der Praxis offenbar kein großes Problem
Die Performance-Probleme bei den Constraints in FreeCAD kommen hauptsächlich von redundanten und unnötigen GUI-Layout-Algorithmen; schon bei ein paar hundert Constraints bricht es zusammen. Die Sparse-QR-Zerlegung von Eigen braucht bei 2200 Constraints etwa 18 Sekunden, was nicht schlecht ist. Es gibt auch Bibliotheken für Sparse-QR-Zerlegung, die 500.000 bis 1.000.000 Constraints in ungefähr 18 Sekunden verarbeiten. Es ist schwer vorstellbar, dass eine CAD-Skizze jemals mehr als einige tausend Constraints haben sollte
[1]: https://github.com/FreeCAD/FreeCAD/issues/11498#issuecomment...
Es wird für Assembly-Constraints in FreeCAD und Ondsel ES verwendet
Ich habe vor langer Zeit mit Autodesk Inventor CAD gelernt, und die einzige kostenlose Modellierungssoftware, die ich nach ein paar Stunden Benutzung verstehen konnte, war Onshape. In diesem Bereich scheint Usability wirklich ein großes Problem zu sein
Zum Beispiel hatte ich bei FreeCAD das Gefühl, es gäbe Milliarden Wege, dieselbe Sache zu tun, aber am Ende nur einen tatsächlich richtigen. Einige Tutorials hinterließen am Ende ein Modell, das nicht passte
Tolle Arbeit, und es wirkt wie ein schwieriges Problem
Repo: https://github.com/MattFerraro/CADmium
Ich nutze fast nur die Workbenches Part Design, Sketcher und Spreadsheet. Diese drei funktionieren meist gut zusammen. Die Interoperabilität zwischen den Workbenches ist aber so schlecht, dass ich Angst habe, mich in andere Bereiche vorzuwagen. Gelegentlich nutze ich auch die Part-Workbench, aber wenn man deren Ergebnisse in Part Design verwenden will, muss man zweimal durch interne Formatkonvertierungen, was viel zu umständlich ist
Ich hoffe, dass eines der vielen Open-Source-CAD-Projekte FreeCAD irgendwann ersetzt
Praktisch war es nicht, aber das Modell lief sogar auf dem Handy
Fusion360 ist zwar benutzbar, aber verglichen mit den kommerziellen Paketen, die ich verwendet habe, ist die User Experience ziemlich furchtbar
Was ich mir von kostenlosem CAD wünsche, ist, dass jemand die Robustheit und Geschwindigkeit von Creo nimmt und sie mit der Benutzerfreundlichkeit von SolidWorks kombiniert. Anfangs darf der Funktionsumfang ruhig noch ziemlich begrenzt sein
Es lief immer so: Ich folgte einem Tutorial, das mich zu 80 % ans Ziel brachte, bastelte dann irgendwie den Rest zusammen, merkte anschließend, dass genau dieses Basistutorial das Projekt so aufgebaut hatte, dass die verbleibenden 20 % damit nicht sauber fertigzustellen waren, und sobald ich versuchte, frühere Schritte zu ändern, brach das ganze Projekt auseinander. Das wiederholte sich immer wieder
Ist bei CAD die Reihenfolge der Arbeitsschritte normalerweise so wichtig? Ich bin mit dem Gedanken eingestiegen, es sei nur ein einfaches Objekt und FreeCAD könne doch nicht so schwer sein, aber tatsächlich war es sehr schwer
Dass es in diesem Bereich einen neuen Marktteilnehmer gibt und dieser insbesondere versucht, einen neuen Kernel zu entwickeln, ist interessant, aber die Erfolgsaussichten wirken gering. Die führenden Kernel der Branche wurden über Jahrzehnte von CAGD-Doktoren und Programmierern entwickelt, finanziert von Unternehmen aus der Automobil- und Luftfahrtindustrie. Schon das Erreichen eines grundsätzlich konkurrenzfähigen Funktionsumfangs wird lange dauern
Außerdem ist fraglich, welches Nutzerproblem überhaupt gelöst werden soll. Open Source ist für CAD-Nutzer nicht zwingend erforderlich. Es mag Budgetbeschränkungen geben, aber in diesem Bereich ist Open Source möglicherweise keine für Nutzer direkt sichtbare Funktion wie bei Entwicklerwerkzeugen. Plasticity hat gezeigt, dass man auch mit einer Parasolid-Lizenz in einem niedrigen Preissegment Geld verdienen kann
Ich nutze seit über 30 Jahren parametrische CAD-Werkzeuge, und Onshape ist eine ziemlich erstaunliche Lösung für viele Probleme, die es in Creo oder SolidWorks gibt. Eine kollaborative CAD-Umgebung wie Google Docs, in der keine Daten verloren gehen und unbegrenztes Undo vorhanden ist, weil sie von Anfang an datenbankbasiert statt auf einem Dateisystem aufgebaut wurde, verändert das Leben. Die Modellierungsfunktionen holen andere Werkzeuge allerdings noch ein
Ein großer Nachteil von Onshape, Creo und SolidWorks ist, dass sie bei einer 2D-Skizze beginnen und dann zu 3D-Objekten extrudieren, rotieren oder loften. 3D-Werkzeuge sind eher Zusatzfunktionen der Grundstruktur und wirken fast wie nachträglich bedacht. Plasticity, Rhino und Alias sind deutlich stärker 3D-first
FeatureScript von Onshape ist sehr cool und leistungsfähig, aber für CAD-Nutzer, die ihre eigenen Werkzeuge bauen wollen, nicht so gut wie Grasshopper von Rhino
CADmium muss sich darauf konzentrieren, in welchem Markt es ein besseres CAD-Werkzeug sein kann als bezahlte oder kostenlose Alternativen und welches Nutzerproblem es löst. Selbst wenn die Entwicklung noch früh ist, ist es nicht zu früh, Nutzeranforderungen zu verstehen. Open Source ist nicht schon an sich das Ziel
Mit modernen Werkzeugen, den Erkenntnissen aus alten Engines und ohne Eintrittsschulden kann auch ein kleines Team etwas bauen, das mit 30 Jahre alter Software gleichzieht oder besser ist
Ich denke, ein kleines, engagiertes Team kann einen neuen parametrischen Kernel und ein CAD-Paket bauen. Besonders dann, wenn es Open Source ist
CAD-Nutzer können stark von einer guten Open-Source-Alternative profitieren
Dagegen gibt es viele Gründe, proprietäre Software zu meiden, und bei SaaS gilt das noch stärker. Es geht heute immer mehr in Richtung SaaS, und das ist auch hier der Fall. CAD-Software ist ein Bereich, in dem viele Nutzer bereits Hunderte Stunden in das Lernen und Verwenden investiert haben und dann darunter litten, dass proprietäre Systeme ihre Bedingungen geändert haben
Ich weiß, dass ich damit in der Minderheit bin, aber für mich ist Open Source an sich ein absolutes Ziel. Ich nutze seit sehr langer Zeit nur Open-Source-Software
Trotzdem bin ich mir bei dem Punkt nicht sicher, dass Open Source kein Ziel sein könne. Es ist ähnlich wie bei KiCAD und Altium. Wenn man 90 % dessen, was Onshape bietet, als Open Source bereitstellen könnte, würden die Leute es meiner Meinung nach nutzen
Den Kostenaspekt verstehe ich. Eine SolidWorks-Lizenz liegt grob bei 3.000 bis 5.000 Dollar, also werden die meisten Unternehmen für ein bewährtes Werkzeug bezahlen
Zur Einordnung: Onshape wurde in weniger als drei Jahren und mit unter 10 Millionen Dollar bis zum MVP entwickelt. Ich glaube nicht, dass man heute zwingend jahrzehntelange Doktoranden-Arbeitszeit braucht, um ein neues CAD-Programm zu bauen
Das ist eine großartige Zusammenfassung des CAD-Kernel-Ökosystems
Besonders gefällt mir der Satz: „Der einzig populäre Open-Source-B-rep-Kernel ist OpenCascade, und er ist der Pontiac Aztek unter den B-rep-Kernels. Hässlich, nur mit Grundfunktionen und möglicherweise unzuverlässig, aber er fährt und man bekommt ihn gratis“
Das trifft es wirklich perfekt
Wenn es local-first ist, frage ich mich, warum es im Browser laufen muss.
Solvespace hat den Vorteil, dass es nur eine einzelne Datei zum Herunterladen und Ausführen ist.
Außerdem wurde der Constraint-Solver in Projekten wie CADsketcher und Dune 3D verwendet: https://github.com/dune3d/dune3d
Der Autor sagt, er habe den Solver von Solvespace direkt verwendet, weil der Wrapper-Code nicht alle benötigten Funktionen freigegeben habe, und habe den Solver patchen müssen, damit er Gleichungen dort symbolisch löst, wo das möglich ist, um ihn für die erzeugten Gleichungstypen schnell genug zu machen.
Ich frage mich auch, ob es mit https://github.com/jay3sh/cadmium zu tun hat.
Als CAD-Kernel wurde Manifold ebenfalls nicht erwähnt: https://github.com/elalish/manifold/wiki/Manifold-Library Ich verstehe, dass es viele der gleichen Nachteile wie OpenCASCADE hat, aber trotzdem scheint es erwähnenswert.
Dieser Kernel wurde früher auch hier diskutiert: https://news.ycombinator.com/item?id=35071317
Die vollständige Historie und Editierbarkeit wirken besonders interessant und vielversprechend. Wenn diese Historie in einem ein- und ausklappbaren Panel aufgelistet werden könnte und es Ausklappdreiecke gäbe, um abgeschlossene Elemente zu verbergen, damit man sich auf die aktuelle Arbeit konzentrieren kann, wäre das für mich fast ein Traum, vorausgesetzt natürlich, ich könnte die 3D-Seite überhaupt verstehen. Mit BRL-CAD, FreeCAD, Solvespace, Alibre Atom usw. habe ich bisher immer versagt; funktioniert haben für mich nur codebasierte Werkzeuge ähnlich wie OpenSCAD.
Zu Hause ein Teil entwerfen, es bei der Arbeit ändern und es dann im Makerspace mit der verfügbaren Ausrüstung herstellen zu können, ohne etwas installieren zu müssen, ist ein großer Vorteil.
Ich habe schon einmal erwogen, den Triangle-Mesh-Code von Solvespace durch Manifold zu ersetzen, aber das wäre viel Arbeit, und was wirklich nötig ist, ist, die NURBS-Bugs zu beheben, damit man weniger auf den Mesh-Code angewiesen ist.
Der Constraint-Solver von Solvespace wird übrigens auch in der Assembly 3 Workbench von FreeCAD verwendet. In letzter Zeit verbreitet er sich hier und da.
Ich stimme zu, dass 3D-CAD-Apps zu den komplexesten UIs überhaupt gehören.
Allerdings bin ich skeptisch gegenüber der Aussage, dass ein Framework einem kleinen Team den Großteil der Arbeit abnehmen müsse, um ein gutes 3D-CAD zu bauen. Ich bezweifle, dass ein generisches UI-Framework die langfristige Lösung für 3D-CAD sein kann.
Gute UX muss manchmal parametrische 3D-Modelle, Mesh-Approximationen, die Projektion auf Linien und Flächen nach Hidden-Surface-Removal, die Pixel des Framebuffers und UI-Widgets gleichzeitig berücksichtigen. Frameworks gehen zu oft davon aus, dass Informationen sich leicht aufteilen lassen und nur begrenzte Größe haben.
Für Prototyping mag das helfen, aber wenn das Projekt größer wird, wird man beim zentralen 3D-Viewport-Interaction wahrscheinlich das Framework am Ende doch verwerfen und den größten Teil zwischen OpenGL oder etwas Ähnlichem und Maus-/Tastatur-Events mit eigenem Code füllen.
Frameworks für Buttons oder Listen sind in Ordnung, aber selbst solche Elemente sind in 3D-CAD viel dynamischer als in einer durchschnittlichen App.
Ich hoffe wirklich, dass CADmium mir hilft, von OpenSCAD wegzukommen. Bei OpenSCAD muss man am Anfang nicht groß nachdenken und kann mit einer einfachen Sprache einfach Modul auf Modul stapeln.
Das Problem ist, dass OpenSCAD keinen Solver hat. Es gibt Variablen, aber keine Constraints. Wenn man Änderungen vornimmt, muss man plötzlich viel selbst nachdenken, um Constraints manuell aufzulösen, und baut leicht Fehler ein.
Trotzdem ist das Problem nicht gravierend genug, um ganz zu einem anderen Werkzeug zu wechseln, weil OpenSCAD zum Starten eines Modells meiner Meinung nach viel einfacher ist als alles andere, was ich bisher benutzt habe.
https://github.com/Ondsel-Development/OndselSolver
Er wird in FreeCAD und Ondsel ES verwendet.
Ich habe auch mit OpenSCAD angefangen, aber sobald es darum ging, tatsächliche 3D-Objekte zu erstellen, war FreeCAD viel produktiver. Manchmal möchte man mit einem Rechteck anfangen, dann eine Linie löschen und einen Halbkreis hinzufügen, ohne das schon vor dem Start der Skizze zu wissen.
Bei OpenSCAD fühlt es sich an, als müsse man die benötigten Form-Primitiven und die genaue Art der Änderungen im Voraus kennen, und persönlich störte mich auch, dass dort 3D-Primitiven empfohlen werden statt Extrusionen oder Rotationen auf 2D anzuwenden.
align-,attach- undanchor-Operationen sowie viele nützliche Operationen und Bauteile.Es ist schön zu sehen, dass andere Leute Zeit und Talent in Open-Source-CAD investieren. Bei Ondsel glaubt man stark daran, dass Open-Source-CAD sehr wichtig ist, und ich freue mich, in diesem Bereich Innovation zu sehen.