karim
b37c9f467b
RESEARCH_CAD_APPROACHES.md: konkrete, priorisierte Ansaetze fuer 'von BIM-Tool zu echtem CAD' — direkt an geklonten Repos gelernt. - OpenCADStudio (GPL-3.0, Referenz): generisches Entity-Trait-Modell, modeless StepInput-Command-System, 70KB Snap-Engine, universelle Grips, CadDocument=DWG/DXF-Objektmodell. - truck (Apache-2.0): Rust-B-Rep/NURBS-Kernel, Geometrie-Crates WASM-faehig und vom wgpu-Rendering trennbar; Booleans/Fillets noch instabil. - acadrust (MPL-2.0!): pure-Rust DWG/DXF R13-R2018 read+write, alle Deps pure Rust -> WASM-tauglich; Kandidat fuers DWG/DXF-Rueckgrat. - Web-Import-Landkarte (web-ifc/occt-wasm/shpjs/loaders.gl/...) fuer GEO-BLOCK. PENDENZEN: Strategie-Item im Backlog verlinkt.
163 lines
9.8 KiB
Markdown
163 lines
9.8 KiB
Markdown
# 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](https://github.com/HakanSeven12/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](https://github.com/ricosjp/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](https://github.com/HakanSeven12/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`](https://github.com/virtualritz/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.
|