DOSSIER-STANDALONE/RESEARCH_CAD_APPROACHES.md

RESEARCH — Von BIM-Tool zu „echtem CAD": Ansätze aus fortgeschrittenen Programmen

Stand: 2026-07-05. Direkt am Quellcode studiert (Repos nach /tmp/cad-study geklont, liegen NICHT im Projekt). Ziel: konkrete, verfolgbare Ansätze, um DOSSIER von einem spezialisierten BIM/Architektur-Werkzeug zu einem allgemeineren CAD zu erweitern.

Studierte Programme

Repo	Was	Lizenz	Stack	Für uns
OpenCADStudio	Eigenständige 2D/3D-CAD-App, ~200k LOC Rust	GPL-3.0	Iced (GUI) + wgpu + WASM-Web-Build	App-Architektur-Blaupause (Entity-Modell, Command-System, Snap, Grips). Fast unser Stack.
truck	Reiner Rust-CAD-Kernel (NURBS/B-Rep/Mesh/Boolean/STEP)	Apache-2.0	16 Crates, wgpu-Rendering + truck-js (WASM)	3D-Kernel-Blaupause. OpenCADStudio nutzt ihn als 3D-Backend.
acadrust	Pure-Rust DWG+DXF R13–R2018 read+write, 41 Entity-Typen	MPL-2.0	nom/byteorder/flate2/nalgebra/encoding_rs (alles pure Rust)	DWG/DXF-Rückgrat, MPL-2.0 nutzbar, sehr wahrscheinlich WASM-baubar.

Lizenz-Klarstellung: acadrust ist MPL-2.0 (file-level copyleft — für uns nutzbar, keine GPL-Ansteckung), NICHT GPL. truck ist Apache-2.0 (frei nutzbar). Nur OpenCADStudio selbst ist GPL-3.0 — wir lesen es als Architektur-Referenz, kopieren keinen Code.

---

Die zentrale Lektion: was ein „echtes CAD" architektonisch ausmacht

DOSSIER ist heute domänenzentriert (Wand/Öffnung/Component/Plan-Pipeline, TS-Modell). Ein echtes CAD (Rhino/AutoCAD-artig) hat stattdessen einen generischen Kern. Aus OpenCADStudios src/ destilliert:

1. Generisches Entity-Modell mit Traits (statt Wand-Spezialfall)

src/entities/ = 41 Entity-Typen (line, arc, circle, lwpolyline, spline, ellipse, hatch, text, mtext, dimension, leader, insert/block, table, viewport, mesh, solid3d, …). Jeder Typ implementiert ein Trait-Set statt einer Sonderbehandlung:

• TruckConvertible → 3D-Kernel-Geometrie
• FallbackTess → Display-Geometrie (Punkte/Snap-Vertices)
• Grippable → editierbare Griffe + Hover-Menü (Add Vertex / Convert to Arc / Reverse / Lengthen…)
• PropertyEditable → Eigenschaften-Panel
• Transformable → Move/Rotate/Scale/Mirror
• MassProps → Fläche/Umfang für Abfragen

→ DOSSIER-Lehre: ein generisches Entity-Modell mit Trait-Dispatch neben das BIM-Modell stellen. Wir haben Ansätze (Drawing2D, splitJoin-Editoren, kernel2d), aber keine einheitliche Entity-Taxonomie mit Traits.

2. Modeless Command-System — der eine StepInput-Step-Machine

src/command.rs: EIN Enum StepInput { Point / Text / EntityPick / StructurePick / SelectionComplete }. Jede Eingabequelle (Kommandozeile, Viewport-Klick, Pick, Selektion, Dynamic Input, Plugin-API, Headless-Script) übersetzt in StepInput und läuft durch eine feed_command-Funktion → treibt die aktive CadCommand-Step-Machine, egal woher der Schritt kam.

→ DOSSIER-Lehre: Das ist der größte UX-Unterschied. Echtes CAD = „Befehl tippen → Punkte picken → Optionen". DOSSIER ist heute Tool-Button + Direktmanipulation. Ein StepInput-Funnel + Kommandozeile wäre der Hebel, um beliebige Werkzeuge einheitlich, scriptbar und headless-testbar zu machen.

3. Object-Snap-Engine (eigenständig, groß)

src/snap.rs = 70 KB nur für OSNAP (endpoint/midpoint/center/intersection/tangent/ perpendicular/…). Wir haben Teil-Snapping; ein echtes CAD hat eine dedizierte, vollständige Snap-Schicht.

4. Universelle Grip-Editierung

Jede Entity liefert Griffe + kontextuelle Griff-Menüs mit teils numerischem Follow-up („Lengthen" fragt Wert an der Kommandozeile ab). Einheitlich über das Grippable-Trait.

5. CadDocument als Dokumentmodell = das DWG/DXF-Objektmodell

OpenCADStudio nutzt acadrust::CadDocument DIREKT als sein Datenmodell (Entities + Objects + Tables: Layer/Linetype/Style/Blocks + XData). D. h. das native CAD-Austauschformat IST das interne Modell → verlustfreier Round-Trip „for free".

---

truck — 3D-Kernel-Blaupause (+ harte WASM-Realität)

Saubere Schichtung (Ship-of-Theseus, kleine ersetzbare Crates):

truck-base      Basistraits/Toleranz (cgmath)
truck-geotrait  ParametricCurve / ParametricSurface Traits
truck-geometry  Knot-Vektor, B-Spline, NURBS            ← Kurven/Flächen
truck-topology  vertex/edge/wire/face/shell/solid       ← B-Rep-Topologie
truck-modeling  Geometrie + Topologie integriert         ← Solids bauen
truck-polymesh  Polygon-Datenstruktur + Meshing
truck-meshalgo  Tessellation der Shapes
truck-shapeops  Boolean-Ops auf Solids (v0.4 — früh)
truck-stepio    STEP read/write (v0.3)
truck-platform  wgpu-Grafik-Utility   ┐ Rendering — brauchen wir NICHT
truck-rendimpl  Shape/Mesh-Visualisierung ┘ (wir haben eigenen wgpu-Renderer „Nordstern")
truck-js        WASM-Wrapper (v0.2)

WASM-Realität (zwei Befunde abgeglichen):

• OpenCADStudio pinnt truck-meshalgo 0.4 und schaltet den solid3d-Feature im WASM-Build ab, weil dessen ACIS-/vtkio-Pfad über xz2 → lzma-sys (C-Bibliothek) nicht nach wasm32 kommt → im Web ist OpenCADStudio nur 2D.
• Neuere truck-meshalgo (0.6) gated rayon/vtkio selbst per cfg(not(target_arch="wasm32")) aus → baut zu wasm32, aber single-threaded. Der reine Geometrie-Stack (base → geotrait → geometry → topology → polymesh → meshalgo → modeling → shapeops) hat keine native-only-Deps und ist sauber vom wgpu-Rendering trennbar (truck-platform/-rendimpl weglassen).

Reifegrad (Apache-2.0, aktiv, ~1 Hauptentwickler; ausdrücklich KEIN Produktionskern):

• NURBS/B-Spline + B-Rep-Topologie: stabil (v0.5/0.6).
• Booleans (truck-shapeops): and/or vorhanden, aber instabil bei coincident geometry (Issue #114); difference fehlt (#85); Fillets fehlen komplett. Der Fork monstertruck hat difference + rolling-ball-Fillet. → Für unsere Wandöffnungen (boolean holes) haben wir das ohnehin schon selbst gelöst (spanCutouts).
• truck-stepio: STEP schreiben (aber NICHT für boolean-operierte Shapes) + lesen (v0.6 beta, neues truck_stepio::in).
• truck-js: fertiger wasm-bindgen-Wrapper (kein npm-Paket → selbst per wasm-pack bauen), bündelt modeling/shapeops/meshalgo/stepio; IntoWasm-Muster.

---

acadrust — DWG/DXF-Rückgrat

Pure Rust, MPL-2.0, CadDocument-Objektmodell (entities/objects/tables/xdata/classes), 41 Entity-Typen, DWG „208/208 roundtrip-perfect", serde optional, failsafe-Parsing, ~40 Codepages. Alle Deps pure Rust (nom/byteorder/flate2-miniz/nalgebra/indexmap/ahash/encoding_rs) → sehr wahrscheinlich zu wasm32 baubar (Datei-I/O-API müsste auf Bytes/Reader statt std::fs umgestellt werden — vermutlich schon vorhanden). Heute nutzen wir JS dxf-parser (nur 2D) + libredwg-web.

---

Web-Import-Landkarte (für den GEO-BLOCK / Import-Backlog)

Pro Format die aktive, web-/WASM-taugliche Lib (Stand Mitte 2026):

Format	Empfohlene Lib	Lizenz	Anmerkung
DWG/DXF (browser)	@mlightcad/cad-viewer / libredwg-web (nutzen wir) oder acadrust (Rust)	MIT / GPL-3.0 / MPL-2.0	acadrust = Rust-Weg, MPL-2.0
STEP/IGES/BREP	occt-wasm (OCCT V8, ~4.5 MB) oder unser opencascade.js	LGPL-2.1	occt-wasm = moderne TS-API
IFC (BIM!)	web-ifc (ThatOpen)	MPL-2.0	De-facto-Standard, read+write, sehr aktiv
SHP/GIS	shpjs + proj4	MIT	direkt für GEO-BLOCK (SWISSIMAGE/Terrain)
Punktwolken LAS/LAZ	@loaders.gl/las (+ laz-perf)	MIT/Apache	Rendering: potree-core oder deck.gl
E57	e57-js (Emscripten/libE57Format)	MIT	neu, funktional, sehr obskur
glTF/OBJ/STL	three.js-Loader (haben wir via three)	MIT
3MF	lib3mf (WASM) oder THREE.3MFLoader	BSD-2 / MIT
PDF-Vektor	pdfjs-dist getOperatorList()	Apache-2.0	kein fertiges PDF→DXF; roher Pfad-Stream

---

Priorisierte Ansätze für DOSSIER (die eigentliche Antwort)

Reihenfolge = Nutzen × Machbarkeit, ohne die BIM-Stärke zu opfern.

1. Generisches Entity-Modell + Trait-Dispatch (Fundament). Neben das BIM-Modell eine generische Entity-Schicht (line/arc/circle/polyline/spline/text/dimension/hatch/block) mit Traits à la OpenCADStudio (Display/Grips/Props/Transform). Unser kernel2d liefert schon die Geometrie-Operationen dafür. Größter struktureller Hebel.
2. Modeless Command-System (StepInput-Funnel + Kommandozeile). Ein Eingabe-Enum, eine feed_command-Schleife, CadCommand-Step-Machines. Macht Werkzeuge einheitlich, scriptbar, headless-testbar. Größter UX-Hebel Richtung „echtes CAD".
3. DWG/DXF-Round-Trip über acadrust (Rust/WASM). MPL-2.0, pure Rust → passt in unseren neuen src-tauri-Kern. Ersetzt langfristig die JS-Parser, bringt echten Import/Export. Erst: WASM-Baubarkeit + Bytes-API verifizieren (Spike wie beim Textur-Spike).
4. Vollständige Object-Snap-Schicht als eigenes Modul (endpoint/mid/center/intersection/ tangent/perp/…), aufbauend auf kernel2d.
5. 3D-B-Rep später, selektiv (truck-geometry/-topology/-modeling als reine Crates, OHNE truck-Rendering — wir haben Nordstern). NUR wenn wir echte NURBS/Solids/Booleans brauchen; der Meshing-/Boolean-Pfad ist WASM-problematisch (native C-Deps) und Booleans sind noch früh. Bis dahin: truck als Referenz lesen, nicht einbinden.

Kernaussage: DOSSIERs Rust-nach-WASM-Kurs (den wir mit kernel2d gerade gehen) ist genau richtig — OpenCADStudio bestätigt ihn. Der Weg zu „echtem CAD" führt über (1) generisches Entity-Modell und (2) modeless Command-System; (3) acadrust bringt echten DWG/DXF-Austausch. 3D-B-Rep (truck) ist ein späterer, selektiver Schritt mit klaren WASM-Vorbehalten.