DOSSIER-STANDALONE/docs/research/tech-selection.md

Technologie-Auswahl: Browser-basiertes BIM-Tool (DOSSIER-Port)

Kontext: Standalone, browser-basiertes BIM-Werkzeug (React + TypeScript + Three.js) als Port des DOSSIER Rhino-Plugins. Keine Server-Abhaengigkeit gewuenscht (alles client-side). Recherchestand: Juni 2026.

Leitprinzip: Wo immer moeglich auf einem echten B-Rep-Geometriekernel (OCCT) aufbauen, weil ein BIM-Werkzeug exakte 2D-Ableitungen (Schnitte, verdeckte Kanten, Bemassung) braucht — das ist mit reinen Dreiecksnetzen nicht sauber loesbar. Mesh-Booleans (Manifold) als schnelle Ergaenzung fuer Importgeometrie und Vorschau.

---

1. Geometriekernel im Browser (Solids + Booleans)

Das ist das schwierigste und zugleich wichtigste Problem. Drei ernsthafte Optionen, die alle im Browser (WASM) laufen.

Optionen

A) opencascade.js (OCCT als WASM) Port des vollstaendigen OpenCASCADE-Kernels (OCCT) nach WebAssembly via Emscripten. Voller B-Rep-Kernel: NURBS-Flaechen, exakte boolesche Operationen, Fillets/Chamfers, STEP/IGES-Import/-Export, Meshing. TypeScript-Bindings vorhanden. Die neueren Versionen (V3-Linie) zielen explizit auf moderne Bundler.

• Repo: https://github.com/donalffons/opencascade.js/
• Doku: https://opencascade-js.vercel.app/
• npm: https://www.npmjs.com/package/opencascade.js
• Lizenz: OCCT steht unter LGPL-2.1 mit OCCT-Exception (seit 6.7.0). Kommerzielle Nutzung ohne Lizenzgebuehren/Royalties erlaubt, sofern man (a) sichtbar darauf hinweist, dass die Software OCCT nutzt, und (b) eine Kopie der OCCT-Lizenz mitliefert. Die Exception entschaerft das statische-Linking-Problem fuer Header/Templates. Quellen: https://dev.opencascade.org/resources/licensing, https://spdx.org/licenses/OCCT-exception-1.0.html
• Trade-offs: Sehr grosse WASM-Binaries (zweistelliger MB-Bereich je nach Custom-Build), steile Lern- und API-Kurve (rohe OCCT-C++-API durchgereicht), Build-Pflege aufwendig.

B) replicad (Abstraktion ueber opencascade.js) — empfohlene Basis replicad ist eine schlanke, idiomatische TypeScript-Schicht ueber opencascade.js. Es liefert genau die High-Level-Bausteine, die ein BIM-Tool braucht: Sketches/Blueprints, Extrude/Revolve/Loft, Booleans, Fillet/Chamfer — und entscheidend: HLR-Projektionen (drawProjection) und 2D-Drawings mit SVG-Export. Laeuft per Design im Web Worker und gibt Dreiecksnetze an den Main-Thread fuer Three.js zurueck.

• Doku/Library-Guide: https://replicad.xyz/docs/use-as-a-library/
• API: https://replicad.xyz/docs/api/
• Lizenz: MIT (eigene Schicht) — der OCCT/LGPL-Hinweis gilt weiterhin fuer das eingebettete WASM. Repo: https://github.com/sgenoud/replicad
• Trade-offs: Erbt OCCT-WASM-Groesse und -Robustheitsgrenzen; kleineres Team/Bus-Faktor als OCCT selbst. Man kann jederzeit „unter die Haube" auf rohes opencascade.js durchgreifen, wenn die Abstraktion nicht ausreicht.

C) Manifold (manifold-3d, WASM) — empfohlen als schnelle Mesh-Ergaenzung Geometrie-Bibliothek fuer topologisch robuste Dreiecksnetze. Bietet den (laut Autor) ersten garantiert mannigfaltigen Mesh-Boolean-Algorithmus — extrem schnell und robust gegen Randfaelle. Stark parallelisiert.

• Repo: https://github.com/elalish/manifold
• npm: https://www.npmjs.com/package/manifold-3d (aktuell v3.5.x, Juni 2026)
• Lizenz: Apache-2.0 (sehr permissiv, ideal). Bestaetigt: https://github.com/elalish/manifold
• Trade-offs: Nur Meshes, kein B-Rep — keine exakten NURBS-Flaechen, keine echten Fillets auf Krümmungen, kein STEP. Fuer ein BIM-Tool, das exakte Plaene/Schnitte ableiten will, alleine nicht ausreichend, aber unschlagbar fuer schnelle Booleans auf importierter Mesh-Geometrie und Live-Vorschau. Wichtig: unterstuetzt slice(z) und project() (siehe Abschnitt 3).

D) three-bvh-csg (nur erwähnt, nicht empfohlen als Kernel) Sehr schnelle CSG direkt auf Three.js-BufferGeometry (auf three-mesh-bvh). >100x schneller als BSP-basierte Three.js-CSG-Libs. Aber: erklaert selbst, dass Resultate „aufgrund numerischer Praezision nicht garantiert 2-mannigfaltig" sind und verweist fuer CAD-Robustheit ausdruecklich auf Manifold.

• Repo: https://github.com/gkjohnson/three-bvh-csg
• Forum: https://discourse.threejs.org/t/three-bvh-csg-a-library-for-performing-fast-csg-operations/42713
• Trade-offs: Gut fuer Live-Vorschau/visuelles Schneiden, ungeeignet als verlaesslicher Modellierkernel.

Empfehlung (Kernel)

replicad (= opencascade.js) als primaerer B-Rep-Kernel im Web Worker; Manifold als schneller Mesh-Boolean-Pfad fuer Import-/Vorschaugeometrie. Diese Zweiteilung deckt sowohl „exakte BIM-Geometrie + 2D-Ableitung" (OCCT) als auch „schnell + robust auf beliebigen Meshes" (Manifold) ab. three-bvh-csg nur, falls man interaktives Echtzeit-Schneiden visuell braucht.

---

2. 2D-Ableitung aus 3D: verdeckte Kanten (HLR) + Schnittgenerierung

Kernfrage des DOSSIER-Ports: aus 3D-Solids saubere 2D-Zeichnungen (sichtbare/verdeckte Kanten, Schnitte) erzeugen — im Browser.

Optionen

A) OCC HLRBRep via replicad drawProjection — empfohlen OCCT enthaelt zwei HLR-Algorithmen: HLRBRep_Algo (exakt, auf der echten B-Rep) und HLRBRep_PolyAlgo (auf polyederisierter Naeherung, schneller, aber polygonal). Quellen: https://dev.opencascade.org/doc/refman/html/class_h_l_r_b_rep.html, https://dev.opencascade.org/doc/occt-7.7.0/refman/html/class_h_l_r_b_rep___poly_algo.html

replicad macht genau das im Browser nutzbar: drawProjection(shape, camera) liefert ein Objekt mit { visible, hidden } — getrennte sichtbare und verdeckte Kantenzuege, die man unterschiedlich stylen kann (z.B. verdeckt = gestrichelt). Konkretes Beispiel aus der Doku:

const { drawProjection, ProjectionCamera } = replicad;
const camera = new ProjectionCamera(corner).lookAt(center);
const { visible, hidden } = drawProjection(shape, camera);
// visible/hidden sind Drawings -> .toSVG()

• Beispiel: https://replicad.xyz/docs/examples/projections/
• Verwandte API: makeProjectedEdges, ProjectionCamera, Drawing.toSVG() / toSVGPaths() (https://replicad.xyz/docs/api/classes/Drawing/)
• Das ist der entscheidende Grund, replicad/OCCT zu nehmen: exakte verdeckte-Kanten-Berechnung auf echtem B-Rep ist mit Mesh-Tools nicht serioes machbar.
• Trade-offs: HLR ist rechenintensiv (deshalb Worker + Caching pro Ansicht/Kamera); HLRBRep_Algo exakt aber langsam, PolyAlgo schneller aber genaehert.

B) Schnitte (Sections) via OCCT Echte Schnitte ueber Schnitt mit einer Ebene/Halbraum (BRepAlgoAPI_Section bzw. Boolean mit Schnittkoerper) ergeben exakte Schnittkanten als B-Rep-Edges, die wiederum nach SVG/DXF gehen. In replicad ueber Booleans + Projektion abbildbar.

C) Manifold slice() / project() — schnelle Mesh-Variante Manifold.slice(z) gibt den Querschnitt parallel zur X-Y-Ebene auf Hoehe z als CrossSection (2D-Polygone, intern Clipper2); Manifold.project() die projizierte Aussenkontur. Quellen: https://manifoldcad.org/docs/jsapi/, https://manifoldcad.org/docs/html/classmanifold_1_1_cross_section.html

• Trade-offs: liefert keine verdeckte/sichtbare-Kanten-Trennung und keine Innenkanten-Semantik wie HLR — nur die geometrische Schnitt-/Projektionskontur des Meshes. Gut fuer Plan-Schnittkonturen (siehe Abschnitt 3), ungenuegend fuer vollwertige Ansichts-Zeichnungen mit verdeckten Kanten.

Empfehlung (2D-Ableitung)

HLR und Ansichts-Zeichnungen ueber replicad drawProjection (OCC HLRBRep) im Worker, mit Caching pro Kamera/Ansicht. Echte Schnitte ueber OCCT-Section-Boolean. Manifold slice() als schneller Pfad nur fuer reine Schnittkonturen (z.B. Plan-Cut auf Mesh-Importen).

---

3. Plan-Ansicht: Clipping bei cutHeight

Verhalten: horizontaler Schnitt auf einstellbarer Hoehe (Grundriss), darüber Abschneiden, Schnittflaechen markieren.

Optionen

A) Three.js Clipping Planes (clippingPlanes / localClippingEnabled) Three.js bietet globale (renderer.clippingPlanes) und material-lokale (material.clippingPlanes) Schnittebenen; renderer.localClippingEnabled ist standardmaessig aus (Null-Kosten, bis aktiviert). Quellen: https://threejs.org/docs/#api/en/materials/Material.clippingPlanes, https://threejs.org/examples/webgl_clipping.html

• Pro: GPU-seitig, dynamisch (Slider auf cutHeight = plane.constant aendern, kein Geometrie-Rebuild), sehr fluessig.
• Contra: Clipping schneidet nur visuell — es entstehen offene Querschnitte (keine Deckflaeche). Fuer „Schnittflaeche fuellen/markieren" braucht man entweder einen Stencil-Cap-Trick oder eine echte Schnittkontur (Abschnitt 2). clipIntersection = true kann Material-Reinitialisierung pro Frame und FPS-Einbrueche verursachen — moeglichst vermeiden. Quelle: https://github.com/mrdoob/three.js/issues/18675

B) Object Culling / Sichtbarkeit nach Hoehe Elemente oberhalb cutHeight per Bounding-Box/Etagen-Metadaten ausblenden (object.visible = false).

• Pro: trivial, keine Shader-Kosten, nutzt BIM-Etagensemantik.
• Contra: grobkoernig (ganze Objekte, kein praeziser Schnitt mitten durch ein Bauteil).

C) Echte Schnittgeometrie pro Etage (OCCT/Manifold) fuer den 2D-Plan Fuer die exportierbare 2D-Grundriss-Zeichnung den echten Schnitt auf cutHeight rechnen (OCCT-Section bzw. Manifold.slice(z)), Schnittflaechen schraffieren (Abschnitt 6).

Empfehlung (Plan-Clipping)

Hybrid: Im 3D-Viewport Three.js Clipping Planes fuer das interaktive Abschneiden (Slider direkt auf plane.constant), kombiniert mit Object-Culling ueber Etagen-Metadaten fuer Grob-Performance. Schnittflaechen-Caps via Stencil-Technik. Fuer die exportierbare 2D-Grundriss-Zeichnung die echte Schnittkontur ueber OCCT/Manifold berechnen statt nur GPU-Clipping. clipIntersection meiden.

---

4. Import: DWG/DXF, IFC, STL, OBJ, XYZ-Punktwolken

DXF / DWG

• DXF lesen: dxf-parser (gdsestimating) — robust, weit verbreitet, parst DXF-Strings zu JS-Objekten. Repo: https://github.com/gdsestimating/dxf-parser. Zum reinen 2D-Anzeigen: dxf-viewer (vagran). https://github.com/vagran/dxf-viewer
• DWG lesen (binaer!): @mlightcad/libredwg-web — LibreDWG nach WASM, parst DWG (und DXF) direkt im Browser/Node ohne Backend. Aktuell v3.x. Repo: https://github.com/mlightcad/libredwg-web, npm: https://www.npmjs.com/package/@mlightcad/libredwg-web
  • Achtung Qualitaet/Limits: DWG-Parsing ist speicherintensiv (kann >2 GB RAM ziehen); libredwg-web erzwingt WASM-Heap-Limits, sehr grosse DWGs koennen scheitern. Im Default-Build sind DXF-Parsing und DWG-Schreiben deaktiviert, um die WASM-Groesse zu senken — DXF also lieber mit dxf-parser lesen. Quelle: https://medium.com/@mlightcad/parsing-autocad-dwg-files-in-the-browser-without-relying-on-the-backend-9067c5d9abf0
  • Lizenz: LibreDWG ist GPL-3.0 — das ist fuer ein proprietaeres Produkt heikel. Wenn das Produkt nicht GPL sein soll, DWG-Import entweder ueber einen separaten Out-of-Process-Konverter kapseln oder Nutzer bitten, vorab nach DXF zu exportieren. DWG-Lizenzfrage vor Integration klaeren.
• Referenz-Implementierung: cad-viewer (mlightcad) zeigt vollstaendigen browser-only DXF/DWG-Viewer/Editor. https://github.com/mlightcad/cad-viewer

IFC (BIM-Kern)

• web-ifc (ThatOpen/engine_web-ifc): IFC lesen/schreiben in JS „at native speeds" via WASM. De-facto-Standard fuer Open-BIM im Browser. Repo: https://github.com/ThatOpen/engine_web-ifc, Doku: https://thatopen.github.io/engine_web-ifc/docs/. Lizenz: MPL-2.0 (datei-basiertes Copyleft, fuer proprietaere Apps i.d.R. unkritisch). Quelle: https://spdx.org/licenses/MPL-2.0.html
• ThatOpen Components + Fragments: Hoehere Ebene — components (Tools für BIM-Apps), fragments (kompaktes Binaerformat auf Google FlatBuffers). Typisch: ~100 MB IFC -> ~10 MB Fragments, >10x schnelleres Laden; Konvertierung lauft worker-basiert. Doku: https://docs.thatopen.com/Tutorials/Fragments/Fragments/IfcImporter/, Repo: https://github.com/ThatOpen/engine_fragment. IfcImporter setzt web-ifc (>=0.0.72) voraus.
  • Empfehlung: IFC einmal mit web-ifc parsen, in Fragments cachen, danach aus Fragments laden.

STL / OBJ / XYZ-Punktwolken

• Standard-Three.js-Loader decken alles ab: STLLoader (ASCII+Binaer), OBJLoader, XYZLoader (XYZ/XYZRGB -> BufferGeometry), PCDLoader. Quellen: https://threejs.org/docs/#examples/en/loaders/PCDLoader, https://deepwiki.com/mrdoob/three.js/4.2-model-format-loaders. Three.js ist MIT.
• Punktwolken-Performance: Naive Darstellung skaliert nicht — ~17 Mio. Punkte ruckeln deutlich. Strategien: Downsampling, LOD/Culling, Hintergrund-/Streaming-Laden. Fuer sehr grosse Wolken Out-of-Core-Octree-Renderer (z.B. Potree-Ansatz) erwaegen statt eines einzelnen Points-Objekts. Quellen: https://discourse.threejs.org/t/render-large-point-cloud-data-in-threejs/57331, https://discourse.threejs.org/t/performance-issues-rendering-large-ply-point-cloud-in-three-js-downsampling-and-background-loading/69135

Empfehlung (Import)

IFC: web-ifc + Fragments (ThatOpen). DXF: dxf-parser. DWG: libredwg-web — aber GPL-Lizenz vorab klaeren / kapseln. STL/OBJ/XYZ/PCD: native Three.js-Loader, mit LOD/Downsampling fuer grosse Punktwolken (Potree-Pattern bei Bedarf).

---

5. Vektor-Export: SVG -> PDF (Print) und DXF

SVG -> PDF

• svg2pdf.js (yWorks) + jsPDF — empfohlen. Reine JS-Loesung, laeuft im Browser, erhaelt echte Vektoren (kein Rasterisieren via html2canvas!), was fuer druckfaehige Plaene entscheidend ist. Integriert sich ueber doc.svg(element, ...). Kompatibel mit jsPDF v2/v3/v4. Repo: https://github.com/yWorks/svg2pdf.js/. Lizenz: svg2pdf.js MIT, jsPDF MIT.
  • Trade-off: SVG-Feature-Abdeckung ist sehr gut, aber nicht 100% — exotische Filter/Pattern koennen abweichen; Schraffuren als explizite Linien (statt CSS-Filter) exportieren erhoeht Treffsicherheit.
• Alternative/ergaenzend: pdf-lib (MIT) fuer Seitenmontage, Mehrseitigkeit, Metadaten, Zusammenfuehren — kann mit jsPDF-Output kombiniert werden. (html2canvas+jsPDF bewusst vermeiden, da Raster statt Vektor.)

DXF-Export

• @tarikjabiri/dxf (dxfjs/writer) — empfohlen. Moderner, in TypeScript geschriebener DXF-Generator fuer Node + Browser. Unterstuetzt u.a. Blocks, Hatches, Insert, Image — d.h. Schraffuren lassen sich als echte DXF-Hatches exportieren (wichtig fuer CAD-Weiterverarbeitung). npm: https://www.npmjs.com/package/@tarikjabiri/dxf, Doku: https://dxf.vercel.app/, Repo: https://github.com/tarikjabiri/js-dxf. Lizenz: MIT.
  • Einfachere Alternative: dxf-writer (Vorlaeufer, weniger Features).

Empfehlung (Export)

SVG -> PDF: svg2pdf.js + jsPDF (Vektor, nicht Raster), optional pdf-lib fuer Seitenmontage. DXF-Export: @tarikjabiri/dxf mit echten Hatch-Entities. Interner Zwischenschritt: 2D-Geometrie als SVG-Paths halten (replicad Drawing.toSVGPaths()), daraus sowohl PDF als auch DXF erzeugen.

---

6. Schraffuren / Muster in SVG/Canvas bei Massstab

Optionen & Erkenntnisse

• SVG <pattern> mit patternUnits="userSpaceOnUse" ist der richtige Weg fuer massstaebliche Schraffuren: das Muster skaliert NICHT mit der Form (im Gegensatz zu objectBoundingBox), sondern bleibt im Weltkoordinaten-Raster — exakt, was man fuer „mm pro Linie im Plan" braucht. Dichte/Winkel ueber patternTransform. Quellen: https://www.w3.org/TR/2015/WD-SVG2-20150915/pservers.html, https://www.codegenes.net/blog/simple-fill-pattern-in-svg-diagonal-hatching/
• Performance: Pattern-Layer werden bei jedem Layout-/Zoom-Schritt neu gerechnet; userSpaceOnUse vermeidet teures Rescaling und ist hier zugleich der schnellere und der korrekte Weg. Quelle: https://oreillymedia.github.io/Using_SVG/extras/ch19-performance.html
• SVG vs. Canvas: Fuer technische Zeichnungen ist SVG qualitativ klar ueberlegen (Vektor, exporttauglich nach PDF/DXF). Canvas wird erst bei sehr vielen einfachen Elementen schneller. Quellen: https://felt.com/blog/from-svg-to-canvas-part-1-making-felt-faster, https://www.yworks.com/blog/svg-canvas-webgl
• Skalierungs-Strategie: Bei sehr dichten Schraffuren ueber grosse Flaechen kann die Linienzahl explodieren -> entweder als Pattern-Kachel rendern (eine Definition, vielfach referenziert, statt tausende Einzellinien) oder beim Export Schraffuren in echte Linien/Hatch-Entities aufloesen (DXF-Hatch, Abschnitt 5).

Empfehlung (Schraffuren)

SVG <pattern> mit patternUnits="userSpaceOnUse" als primaerer Renderpfad (massstabskorrekt, exportierbar, performant durch Kachel-Referenzierung). Bei extrem grossen/dichten Flaechen Canvas-Overlay nur fuer die reine Bildschirm-Vorschau erwaegen; fuer Export immer SVG -> svg2pdf.js bzw. echte DXF-Hatches.

---

7. WebGPU vs. WebGL + Worker-Offloading der WASM-Geometrie

Rendering: WebGPU vs. WebGL

• Reifegrad: Seit Three.js r171 (Sept. 2025) ist der WebGPURenderer produktionsreif mit import * as THREE from 'three/webgpu' und automatischem WebGL2-Fallback — kein eigener Fallback-Code noetig. Quelle: https://www.utsubo.com/blog/webgpu-threejs-migration-guide
• Browser-Abdeckung: Chrome/Edge 113 (Mai 2023), Safari 26.0 (Sept. 2025), Firefox 141 (Juli 2025). ~95% der Nutzer WebGPU-faehig, restliche ~5% bekommen WebGL2-Fallback. Quelle: https://vr.org/articles/webgpu-baseline-2026-three-js-webxr-default
• Performance (nuanciert): Bei draw-call-lastigen Szenen (viele Bauteile/Etagen) gewinnt WebGPU deutlich (bei ~10'000 Draw-Calls ~50 FPS WebGPU vs. ~30 FPS WebGL); bei wenigen grossen Meshes kann WebGL noch gleichauf oder schneller sein. Compute-Shader (Punktwolken, Culling) sind ein WebGPU-Alleinstellungsmerkmal. Quellen: https://medium.com/@sudenurcevik/upgrading-performance-moving-from-webgl-to-webgpu-in-three-js-4356e84e4702, https://altersquare.io/three-js-vs-webgpu-2026-large-scale-construction-viewers/
  • Vorsicht: Es gibt weiterhin Szenarien, in denen WebGPU langsamer ist als WebGL — daher messen, nicht blind migrieren. Quelle: https://github.com/mrdoob/three.js/issues/31055

Worker-Offloading der WASM-Geometrie

• Pflicht, nicht optional: OCCT/replicad-Berechnungen (Booleans, HLR, Section) gehoeren in einen Web Worker, sonst blockiert die UI. replicad ist genau dafuer gebaut (WASM im Worker, Mesh zurueck an den Main-Thread). Quelle: https://replicad.xyz/docs/use-as-a-library/
• Muster: Worker laedt das (grosse) WASM einmal; Kommunikation via Comlink o.ae.; Geometrie als Transferable (ArrayBuffer) zuruecksenden, um Kopierkosten zu sparen. Manifold (WASM) ebenso im Worker betreiben; Manifold ist intern stark parallelisiert.

Empfehlung (Performance)

Three.js three/webgpu-Renderer mit automatischem WebGL2-Fallback (gratis Abwaertskompatibilitaet, Vorteil bei vielen Draw-Calls/Etagen). Alle WASM-Geometrie (OCCT/replicad + Manifold) konsequent in Web Worker(n), Ergebnis als Transferables. WebGPU-Compute fuer Punktwolken-/Culling-Beschleunigung als spaeteres Optimierungs-Upside. Vor groesserer WebGPU-Optimierung mit der echten Szene benchmarken.

---

Empfehlung (Zusammenfassung)

Thema	Wahl	Warum
Geometriekernel (Solids/Booleans)	replicad (= opencascade.js/OCCT) im Worker; Manifold als Mesh-Boolean-Ergaenzung	Echter B-Rep-Kernel noetig fuer exakte BIM-Geometrie + 2D-Ableitung; Manifold (Apache-2.0) schnell+robust fuer Mesh-Importe/Vorschau
2D-Ableitung (HLR/Schnitt)	replicad drawProjection (OCC HLRBRep, liefert {visible, hidden}); OCCT-Section fuer Schnitte	Einziger seriöser Weg fuer verdeckte/sichtbare Kanten auf echtem B-Rep im Browser; Manifold slice() nur fuer reine Konturen
Plan-Clipping (cutHeight)	Three.js Clipping Planes + Object-Culling (Etagen); echte Schnittkontur (OCCT/Manifold slice) fuer Export	GPU-Clipping fluessig & dynamisch fuer Viewport; Culling fuer Grob-Performance; exakte Kontur nur fuer druckbaren Plan
Import IFC	web-ifc + Fragments (ThatOpen)	De-facto Open-BIM-Standard, native Speed, ~10x kleineres/schnelleres Fragments-Caching; MPL-2.0
Import DXF / DWG	dxf-parser (DXF) / libredwg-web (DWG)	Bewaehrt & browser-only; DWG = GPL-3.0 -> Lizenz vorab klaeren/kapseln, RAM-Limits bei grossen Dateien
Import STL/OBJ/XYZ/PCD	Native Three.js-Loader + LOD/Downsampling	Out of the box (MIT); grosse Punktwolken brauchen Octree/Potree-Pattern
SVG -> PDF (Print)	svg2pdf.js + jsPDF (+ pdf-lib optional)	Echte Vektoren statt Raster -> druckfaehig; MIT-Lizenzen
DXF-Export	@tarikjabiri/dxf	TS, Browser-faehig, echte Hatch-/Block-Entities fuer CAD-Weiterverarbeitung; MIT
Schraffuren/Muster	SVG <pattern> mit userSpaceOnUse	Massstabskorrekt (skaliert nicht mit Form), exportierbar, performant via Kachel-Referenz
Rendering	Three.js three/webgpu mit WebGL2-Fallback	Produktionsreif seit r171, ~95% Abdeckung, Vorteil bei vielen Draw-Calls; gratis Fallback
WASM-Offloading	Web Worker fuer OCCT/replicad + Manifold, Transferables	UI bleibt reaktiv; replicad ist dafuer gebaut; spart Kopierkosten

---

Wichtigste Risiken / offene Punkte

1. DWG-Lizenz (LibreDWG = GPL-3.0): Vor Integration klaeren — sonst proprietaeres Produkt gefaehrdet. Option: separater Konvertierungs-Service oder DXF-Pflicht beim Import.
2. OCCT-WASM-Groesse & Build-Pflege: zweistellige MB; Custom-Build/Tree-Shaking und Lazy-Loading im Worker einplanen.
3. HLR-Kosten: drawProjection pro Ansicht cachen; ggf. PolyAlgo fuer schnelle Vorschau, HLRBRep_Algo fuer den finalen Plan.
4. WebGPU nicht blind: mit echter Szene benchmarken — es gibt Faelle, in denen WebGL noch fuehrt.