diff --git a/PENDENZEN.md b/PENDENZEN.md index 81a239c..4bd2ee4 100644 --- a/PENDENZEN.md +++ b/PENDENZEN.md @@ -61,6 +61,19 @@ ## ⏭️ Als Nächstes +- [ ] **BIM-Elemente „wirklich 1:1" (Tür/Fenster/Dach/Decke)** — volle Studie + Priorisierung: **[docs/design/bim-elements-depth-study.md](docs/design/bim-elements-depth-study.md)** (623 Zeilen, Referenzmatrix VW/ArchiCAD/Revit/Allplan gegen IST). ✅ **Bereits erledigt 2026-07-10:** Fenster-Schachtelung Blendrahmen→Flügelrahmen→Glas + fest/öffenbar + Einbaulage 2D (`9a38636`); Mansard-Untertypen Giebel/Walm/Zelt + Knick (`bfb80b3`); Dach-Dicke 3D (`e99bb24`) + **Dach-Schichtlogik RoofType/Layer[]** (`3a986ec`); zweiflügelige Türen leafCount 2D+3D (`4319e12`); getrennter Traufe/Ortgang-Überstand (`c9baff5`); Glas/glazingPanes 2D+3D + Rollladenkasten (`2e13ec3`/`d131683`). **Offen (nach Doc-Priorität):** + - [ ] **Decken-Aussparungen** `Ceiling.openings?: Vec2[][]` (Treppenauge/Schacht) — **P0**, grösster Praxiswert. Braucht Loch-Support im `polygon`-Primitiv (`generatePlan.ts:207`, aktuell KEINE Löcher) + SVG-/glPlan-Renderer + 3D-Slab-Loch (Vorlage `wallMeshCut.ts`). Cross-cutting, ~3 PT. + - [ ] **2D-Schnitt-Poché der Dachschichten** — `toSection.ts` behandelt Dächer heute gar nicht; Grundriss-Poché der Dachschichten (`addRoof` in generatePlan analog `addCeilingPoche`). + - [ ] **RoofType-ResourceManager-Tab** (Schicht-Editor wie Wand/Decke) — heute nur über sampleProject-Default wählbar, kein Anlegen/Editieren im UI. + - [ ] **Decken-Randschicht-Override** (`Ceiling.edgeOverride`, Ringzone anderer Aufbau, Tropfkante/Randdämmung) — P1; **Deckentrenn-Werkzeug** für thermisch getrennte Auskragung (Isokorb, UI-only) — P1. + - [ ] **Tür 1:1 Rest:** `glazingRatio` (Teilverglasung), Kassettentür-Geometrie, `frameKind` im 3D (Zarge vs. Blockrahmen), echtes Schwellenprofil; Alt-`Door[]`-Pfad in `Opening` konsolidieren (technische Schuld, zwei Datenwege). + - [ ] **Fenster 1:1 Rest:** asymmetrische Rahmenbreiten, echtes Sprossengitter, Bank/Nische, Laibungsverkleidung, Form (Rund/Spitz/Schräg). + - [ ] **Dach 1:1 Rest:** Kniestock/Drempel, Krüppelwalm, Kehlen bei L-Grundriss (Straight-Skeleton), Gauben/Dachfenster, Aufschieblinge; Dach im Vertikalschnitt (`toSection.ts`). + - [ ] **Geneigte Decke** (Rampe/Gefälle), Deckenspiegel (zweite abgehängte Fläche) — P2/P3. + - **Nicht bauen** (Doc §6): VW-Massketten-Apparat, volle Sichtbarkeitsmatrix, Eck-Fenster/-Dach generisch, Beschlags-Produktbibliothek, IFC-Void-Semantik nachrüsten. + +- [ ] **`make2D`-Befehl (Sicht → 2D-Zeichnung mit Füllungen)** (Nutzer-Wunsch 2026-07-10). Aus der AKTUELLEN Sicht — egal ob Grundriss, Schnitt oder 3D — eine flache 2D-Zeichnung aus reinen 2D-Geometrien erzeugen (Linien + Füllungen/Schraffuren, „mit allem"). Zwei Ausgaben: (a) als neue `Drawing2D`-Elemente ins Modell einfügen (auf einer Ziel-Ebene), ODER (b) in die Zwischenablage kopieren (SVG/DXF-Fragment) zum Einfügen anderswo. Vorbild: Vectorworks „2D-Darstellung erzeugen" / Rhino `Make2D`. **Bausteine vorhanden:** Grundriss/Schnitt laufen bereits über `generatePlan()`/`generateSectionPlan()` → RScene → SVG (`sceneToPrintSvg`); für 3D braucht es eine Projektion (HLR/Silhouette) der `projectToModel3d`-Meshes auf die Bildebene (neuer Teil). MVP: Grundriss/Schnitt → Drawing2D + Clipboard; 3D-Projektion als zweite Phase. Scope/Format (SVG vs. DXF vs. native Drawing2D) mit Nutzer schärfen. + - [x] ~~**Dächer: Auswahl + Attribut-Editieren + Löschen**~~ — **erledigt (`80121a3` + Folge-Commits `7cfdf59`/`eaf57e2`/`64f6179`/`826685c`):** Klick-Auswahl (Traufe-Pick-Polygon + pickRoof), `selectedRoofIds`/`updateRoof`/`RoofInfo`/`roofSelection`; RoofSection-Panel voll editierbar (Form, Firstrichtung X/Y, Neigung(en), **Breite/Tiefe**, Überstand, Dicke, **Traufhöhe**) + Firsthöhe/Fläche read-only; **Auswahl-Hervorhebung im 2D UND 3D** (Draht-Umriss); Löschen; Abwählen an ALLEN Reset-Stellen. **Optional Folge:** ~~3D-Griffe zum Ziehen (Traufe/First)~~ ✅ **erledigt `4ef40a0`** (Eckpunkt-Resize + Verschieben + First-Griff für Neigung). **Noch offen:** Dachfenster, Kehlen bei nicht-rechteckigem Grundriss (Straight-Skeleton). - [ ] **Ribbon-UI + modulare Bars** (Nutzer-Vision 2026-07-05, bestätigt: Tab-Schema **2D·3D·BIM·Ansichten**). Voller Plan + datengetriebene Architektur: **[docs/design/ribbon-ui-plan.md](docs/design/ribbon-ui-plan.md)**. Ribbon-Oberleiste mit Tabs ersetzt die Werkzeug-Sidebar; datengetriebene Registry (RibbonItem = tool|command|action) ermöglicht auch eine **modulare Custom-Bar** (gleiche Items, vom Nutzer gewählt). Attribute bekommen volle Höhe, Objektinfo darunter gemergt; XYZ-Box oben rechts bleibt. **Phasen:** ~~(1) Gerüst + 2D/BIM-Tab~~ ✅ (`9d6e86d`), ~~(2) TopBar → Ansichten-Tab mergen~~ ✅ (`85011cb`), ~~(2b) Tabs in die TopBar-Zeile~~ ✅ (`456ebc8`), ~~(2c) OCS-Chrome (kleine Wortmarke + Quick-Access-Icons statt Burger, Zeile 26px)~~ ✅ (`4e3b074`), ~~(2d) Text + Ansichten auf eine Leiste, „Ansichten" als Standard-Tab zuerst~~ ✅ (`fe22cbf`), (3) **teilweise** ✅: Werkzeug-Sidebar aus Default-Layout raus + Attribute volle linke Höhe + Wandtyp-/Deckentyp-Picker ins Attribute-Panel verschoben (Nutzer-Entscheid), `LAYOUT_VERSION`→8; ~~**offen:** Objektinfo unter Attribute mergen~~ ✅ (`3a2cef3`): element-spezifische Abschnitte (Wand/Decke/Öffnung/Treppe/Raum) + Wand-Referenzlinie ins Attribute-Panel verschoben; ObjectInfo trägt nur noch Bezugspunkt + Masse (Nutzer-Wunsch). ~~(4) modulare Custom-Bar~~ ✅ (Tab „Eigene" + ＋-Picker, localStorage-persistiert). **Offen:** 3D-Tab füllen (aktuell leer; ggf. 3D-spezifisch statt Doppelung mit Ansichten), Band-Höhe/Abstände + 26px-Zeile visuell im Tauri abnehmen, Dauer-Zoom-Anzeige (Statusleiste?) klären. ✅ Vorarbeit: Eigenschaften-Grid im OCS-Stil (`00733d8`), Kreis+Bogen-Werkzeuge (`e454eab`/`bd2b12b`). **Nächster Schritt: im Tauri visuell prüfen (Band-Höhe, Icons, Aktiv-Highlight), dann Phase 2/3.** diff --git a/docs/design/bim-elements-depth-study.md b/docs/design/bim-elements-depth-study.md new file mode 100644 index 0000000..41be847 --- /dev/null +++ b/docs/design/bim-elements-depth-study.md @@ -0,0 +1,623 @@ +# BIM-Elementtiefe — Tür, Fenster, Dach, Decke ("wirklich 1:1") + +## 0. Zweck und Abgrenzung + +DOSSIER modelliert Bauteile heute semantisch (kein reines Zeichenprogramm) und +hat für Wand/Decke bereits eine mehrschichtige Aufbaulogik (`Component[]` via +`WallType`/`CeilingType`). Türen und Fenster haben seit +`docs/design/window-editor-vectorworks-study.md` einen dedizierten, +phasierten Ausbauplan (Flügeltabelle, Verglasung, Sonnenschutz). Was fehlt, +ist die gleiche Tiefe für **Dach** (keine Schichtlogik, keine Mansard- +Untertypen, kein Kehl-/Gaubenmodell) und für die **Decken-Randterminierung** +(Deckenrand als reines Polygon ohne Kantendetail). + +Dieses Dokument nimmt die vier Bauteile Tür, Fenster, Dach, Decke und hält +sie gegen die reale Tiefe vollständiger BIM-Programme (Vectorworks Architektur, +ArchiCAD, Revit, Allplan). Ziel ist NICHT, jedes Feature dieser Programme zu +kopieren, sondern zu benennen, welche Lücken einen echten "1:1-Zuwachs" für +ein Einfamilienhaus-/Wohnbau-Tool wie DOSSIER bringen — und welche reiner +Ballast wären (Abschnitt 6). + +Für Fenster/Tür dupliziert dieses Dokument NICHT die Mapping-Tabelle aus +`window-editor-vectorworks-study.md` — es referenziert sie und ergänzt, was +dort fehlt (v. a. Tür-Tiefe, die die Studie nur am Rand behandelt, und die +architektonischen Grenzen des heutigen Öffnungsmodells). Für Wand-Schichtlogik +siehe `docs/design/parametric-walls.md` (Raster/Modul-Regeln, nicht +Gegenstand hier) und `docs/design/elements.md` (ältere Gesamtplanung, Stand +vor der aktuellen `Component`/`Layer`-Implementierung — dort abweichende +Typnamen wie `Slab`/`ProfileDef`, hier durchgängig der IST-Code zitiert). + +Alle IST-Aussagen sind mit Datei:Zeile belegt (verifiziert per Lesen des +Codes, Stand dieses Commits). Status-Legende der Lücken-Tabellen: **✓** +vorhanden und gerendert · **~** Feld existiert, Renderer liest es nicht oder +nur grob · **✗** fehlt vollständig. Priorität P0 (grösster 1:1-Zuwachs, bald) +… P3 (Ballast, nur auf Nachfrage). Aufwand grob in Personentagen (PT). + +--- + +## 1. Gemeinsames Fundament: das Schicht-Muster + +Der zentrale Baustein, den DOSSIER bereits hat und der sich wiederverwenden +lässt, ist `Component`/`Layer`: + +- `Component` (`src/model/types.ts:196`) — ein Bauteil-Material: Poché-Farbe + (`color`/`foreground`/`background`), Schnitt-Schraffur (`hatchId`) UND + Ansichts-Schraffur (`viewHatchId`, für unaufgeschnittene Aufsicht), + optionales PBR-Material (`material`), Kürzel (`abbrev`) und ein + Verschneidungs-Rang (`joinPriority`, `types.ts:241`) für die Boolean- + Dominanz am Stoss. +- `Layer` (`types.ts:245`) — eine Schicht: `componentId` + `thickness` + + optionaler Fugen-Linienstil (`jointLineStyleId`). +- `WallType` (`types.ts:260`) und `CeilingType` (`types.ts:273`) sind BEIDE + nur `{ id, name, layers: Layer[] }` — bewusst derselbe Typ, "das + horizontale Gegenstück zum WallType" (Kommentar `types.ts:266-271`). + +Das Muster ist also bereits zweimal (Wand, Decke) verifiziert: +`ceilingThickness()` (`types.ts:2104`) summiert die Layer-Dicken, +`emitSlabs()` (`src/plan/toWalls3d.ts:1352-1419`) stapelt sie im 3D als +einzelne `RSlab`-Scheiben proportional in `[zBottom, zTop]`, `addCeilingPoche` +(`src/plan/generatePlan.ts:2453`) zeichnet die Aufsicht mit der +Ansichts-Schraffur der ERSTEN Schicht, und `toSection.ts:633` +(`splitSlabLayers`) zerlegt die Decke im ECHTEN Schnitt in +Einzel-Bänder je Schicht (mit `resolveCeilingSectionStyle`, +`generatePlan.ts:591`, als Schraffur-/Farbquelle). + +**Der Dach-Vorschlag in Abschnitt 4 ist im Kern: dasselbe Muster ein drittes +Mal anwenden.** Das ist der günstigste Weg zu echter Dach-1:1-Tiefe, weil +Layer-Resolver, Schraffur-Ketten (`resolveHatch`/`resolveForeground` etc., +`generatePlan.ts:409-536`) und die 3D-Stapel-Logik bereits bestehen und nur +auf einen neuen Aufbau-Typ angewendet werden müssen statt neu erfunden. + +Architektonische Randbemerkung: `Project` führt bereits `wallTypes`, +`ceilingTypes?`, `doorTypes?`, `windowTypes?`, `stairTypes?` +(`types.ts:1936-1958`) als eigene Bibliotheken — aber **kein `roofTypes?`**. +`Roof` (`types.ts:1022`) trägt nur ein einzelnes `thickness: number` +(`types.ts:1044`), keinen Aufbau-Verweis. Das ist die strukturelle Lücke, +die Abschnitt 4 schliesst. + +--- + +## 2. Tür (Door) + +### 2.1 Was ein vollständiges BIM-Tool bietet + +| Bereich | Typische Parameter (VW/ArchiCAD/Revit/Allplan) | +|---|---| +| Bauart | Dreh-, Schiebe- (auf/vor Wand), Falt-, Pendel-, Karusselltür, reiner Durchbruch | +| Blattzahl/-teilung | 1-/2-flügelig, Gangflügel + Standflügel (unterschiedliche Breite), Seitenteile links/rechts | +| Blattausführung | glatt, kassettiert, Glasfüllung (Anteil/Sprossenbild), Brandschutz-/Schallschutz-Kennwert | +| Rahmen/Zarge | Zarge vs. Blockrahmen, Rahmenbreite je Kante, Zargentiefe, Bekleidung/Abdeckleiste, Falz | +| Schwelle | ohne, Alu-Flachschwelle, Anschlagdichtung, Bodenanschluss/Gefälle bei Aussentüren | +| Sturz/Oberlicht | festverglastes Oberlicht mit eigenem Rahmen, Kämpfer, Sprossenbild | +| Seitenteile | fest verglaste Seitenteile links/rechts, eigene Breite | +| Form | rechteckig, Rundbogen, Segmentbogen, Stichbogen — bei Aussen-/Haustüren verbreitet | +| Beschlag | Drücker/Knauf-Typ, Schild, Schliesszylinder, Bänder sichtbar/verdeckt | +| 2D-Darstellung | Blatt + Schwenkbogen (Grundriss), eigene Ansichtssymbolik in Schnitt/Elevation, Sturzlinien | +| Material/Schichten | Blatt-Kernaufbau (bei Brand-/Schallschutztüren mehrschichtig, analog Wand) | +| IFC-Rolle | `IfcDoor` mit `IfcDoorType` (PredefinedType), `OverallWidth/Height`, `IfcDoorPanelProperties`, Void in der Wirtswand | + +### 2.2 IST in DOSSIER + +`Opening` mit `kind: "door"` (`src/model/types.ts:1068`) referenziert +optional einen `DoorType` (`types.ts:296`). Vorhanden am Typ: `kind` +("dreh"/"schiebe"/"wandoeffnung", :303), `leafCount` (1|2, :305), `leafStyle` +("glatt"/"kassette"/"glas", :307), `glazingRatio` (:309), `frameThickness`/ +`frameDepth`/`frameKind`("zarge"/"blockrahmen")/`frameWidth` +(:311-328), `insetFromFace`/`insetFace` (:335-337), `transomHeight` (:343), +`threshold` (:349). Am Element selbst: `swing`/`hinge`/`swingAngle`/ +`openingDir` (:1104-1108), `lintelLines` (Sturzlinien, :1119) und +`doorType: "normal"|"wandoeffnung"` (:1100) — ein zweites, mit `DoorType.kind` +teilweise redundantes Feld. + +Renderer-Konsum, real geprüft: + +- **2D-Blatt ist IMMER einflügelig.** `addOpeningSymbol` (Tür-Zweig, + `src/plan/generatePlan.ts:2091-2213`) zeichnet genau EINE Blattlinie + (`sym.hinge → sym.openEnd`) und EINEN Schwenkbogen — `DoorType.leafCount` + wird an keiner Stelle in `generatePlan.ts` gelesen (kein Treffer für + `leafCount` im ganzen Plan-Renderer). Eine zweiflügelige Tür sieht im Plan + aus wie eine einflügelige. +- **3D genauso**: `resolveOpeningFrame` (`src/plan/toWalls3d.ts:1861-1886`) + setzt für Türen hart `wingCount: 1`, unabhängig von `leafCount`. +- `leafStyle` wirkt NUR binär: `"glas"` schaltet eine volle Verglasung frei + (`glazed: dt.leafStyle === "glas"`, `toWalls3d.ts:1883`) — `glazingRatio` + (Teilverglasung, z. B. 60 % Glasanteil im oberen Blattbereich) wird an + keiner Stelle gelesen. "kassette" (Kassettentür) hat keine eigene Geometrie, + fällt auf dieselbe Quader-Darstellung wie "glatt" zurück. + `frameKind: "blockrahmen"` wirkt NUR im 2D-Rahmenband + (`generatePlan.ts:1996`, `isBlock`), im 3D gibt es keinen Unterschied zur + Zarge (`frameMeshesForOpening`, `toWalls3d.ts:1936`, kennt kein + `frameKind`). +- `threshold` steuert `hasSill` im 3D-Rahmen (`toWalls3d.ts:1880`), was einen + einfachen Schwellen-Riegel zeichnet — kein eigenes Schwellenprofil, + keine Gefälle-/Dichtungsdarstellung. +- Es gibt eine ZWEITE, ältere Tür-Repräsentation: `Door` + (`types.ts:1333`, `project.doors: Door[]`) mit eigenem Symbol-Renderer + `addDoorSymbol` (`generatePlan.ts:1840-1899`) — strukturell identisch zum + `Opening`-Pfad, aber ohne jeden Typ-Bezug. Zwei parallele Datenwege für + dieselbe Bauteilart sind selbst technische Schuld, nicht nur ein + BIM-Feature-Gap. +- Form (Rundbogen etc.) existiert nicht: `Opening.width`/`height` sind ein + reines Rechteck, `wallGaps`/`buildWallFootprints` + (`generatePlan.ts:1363-1457`) schneiden nur rechteckige Bänder aus der + Wand-Poché. +- IFC-Export: `IfcDoor` wird erzeugt (`src/export/exportIfc.ts:30-31`), aber + als reine Box-Geometrie ohne `IfcDoorType`/`PredefinedType` und ohne + `IfcOpeningElement`-Void (bewusste Design-Entscheidung, siehe Kommentar + `exportIfc.ts:18-31`: das Loch steckt bereits im geschnittenen Wand-Mesh). + +### 2.3 Lücken (Tür) + +| Feature | Status | Priorität | Aufwand | +|---|---|---|---| +| Zweiflügelige Tür rendert 2 Blätter (2D+3D) | ✗ (`leafCount` ungelesen) | **P0** | 2 PT | +| Teilverglasung nach `glazingRatio` (2D-Linie + 3D-Split) | ✗ | P1 | 1.5 PT | +| Kassettentür eigene Blattgeometrie (Füllungsfelder) | ✗ | P2 | 2 PT | +| `frameKind` (Blockrahmen) auch im 3D wirksam | ~ | P1 | 1 PT | +| Seitenteile (feste Verglasung links/rechts der Tür) | ✗ | P1 | 2 PT | +| Rundbogen-/Segmentbogen-Türform | ✗ | P2 | 4 PT (braucht gekrümmten Wandausschnitt, s. §5.3) | +| Schwellenprofil (Alu-Flachschwelle, Dichtung) statt Riegel | ✗ | P2 | 1 PT | +| `Door`/`Opening`-Doppelpfad konsolidieren | technische Schuld | P1 | 3 PT (Migration) | +| Beschlag (Drücker/Knauf) als Mesh + 2D-Symbol | ✗ | P2 | 1.5 PT | +| IFC `IfcDoorType`/PredefinedType/OverallWidth-Height-Properties | ~ | P2 | 1 PT | + +### 2.4 Umsetzungsvorschlag + +**Modell**: `DoorType.leafs?: { width: number; hingeSide: "left"|"right"; +fixed?: boolean }[]` analog `WindowType.sashes` (`SashDef`, `types.ts:367`) — +bewusst dieselbe Struktur, damit `resolveSashSpans` (`toWalls3d.ts:2019`) UND +die 2D-Pfostenlinien-Logik direkt wiederverwendet werden können, statt eine +Tür-eigene Variante zu bauen. Ein `fixed: true`-Leaf ist das Seitenteil. +`glazingRatio` wandert vom Skalar zu einer klaren Geometrie: Kämpferhöhe +innerhalb des Blatts, gerendert wie das bestehende Oberlicht +(`transomHeight`), nur INNERHALB des Blattrahmens statt darüber. + +**2D**: `addOpeningSymbol` (Tür-Zweig) über die Leaf-Liste iterieren statt +einer festen Blattlinie; pro Leaf ein eigenes `hinge`/`swing` (Default: +alternierend wie bei Fenstern, `sashesOfWindowType`, `types.ts:2132`). + +**3D**: `resolveOpeningFrame` liefert `wingCount = leafs.length` statt hart 1; +`frameMeshesForOpening` (bereits generisch über `params.sashes`) übernimmt +die Mehrflügel-Darstellung ohne Änderung — das ist der Vorteil der +Struktur-Wiederverwendung. + +**UI**: Im Tür-Editor (sofern nach dem Muster von +`window-editor-vectorworks-study.md` gebaut) eine Flügeltabelle wie bei +Fenstern, nur mit Tür-Vokabular (Gangflügel/Standflügel statt Flügel 1/2). + +--- + +## 3. Fenster (Window) + +Für Fenster existiert bereits eine vollständige Referenzmatrix in +`docs/design/window-editor-vectorworks-study.md` §2 (Basiseinstellungen, +Grösse, Brüstung, Rahmen, Flügeltabelle, Laibung/Form/Ober-Unterlicht, +Sonnenschutz/Beschlag, Attribute/IFC) mit eigener P0–P3-Phasierung. Diese +Studie ist der massgebliche Bezugspunkt; hier nur die Delta-Punkte, die dort +fehlen oder seither vom IST abweichen. + +### 3.1 IST-Ergänzung (was die Studie nicht/knapp behandelt) + +- `WindowType.glazing` (einfach/zweifach/dreifach) ist bis heute NICHT + renderwirksam — bestätigt weiterhin: `glazingPanesOf()` (`types.ts:2149`) + wird von `glassPanesForOpening` in `toWalls3d.ts` konsumiert, aber die + Studie selbst vermerkt (Zeile 61-65 dort), dass der 2D-Pfad die + Scheibenzahl weiterhin allein aus `DetailLevel` ableitet, nicht aus + `glazingPanes`. Das ist über ein Jahr nach der Studie noch offen — ein + Hinweis, dass P0/P1-Posten aus Fenster-Studien real liegen bleiben, wenn + niemand sie explizit nachzieht. +- `sillBoard` (Fensterbank keine/innen/aussen/beide, `types.ts:447`) ist + weiterhin ungenutzt (kein Treffer für `sillBoard` in `toWalls3d.ts` oder + `generatePlan.ts` ausserhalb der Typ-Definition und des Editors) — + entspricht dem in der Studie als P1 markierten "Fensterbank erstellen". + +### 3.2 Architektonische Grenze: gekrümmte Öffnungen + +Sowohl die Fenster-Studie (§2.6, "Form Eckig/Schräg/Spitz/Rund", P2, 4 PT) +als auch dieser Auftrag nennen Rundbogen-/Spitzbogenfenster. Das ist teurer, +als die Aufwandschätzung suggeriert, weil das gesamte Öffnungsmodell auf +GERADEN Bändern basiert: `buildWallFootprints`/`wallGaps` +(`generatePlan.ts:1363-1457`) schneiden ein rechteckiges Intervall `[from,to]` +entlang der Wandachse aus der Poché, `openingAxisBox` +(`toWalls3d.ts:1739`) baut im 3D ebenso einen achsparallelen Quader. Eine +Bogenform braucht entweder (a) eine gekrümmte Zusatzkontur, die die +Rechteck-Aussparung oben kappt (2D: zusätzliche Polygon-Boolean gegen die +Poché; 3D: gekrümmte Deckfläche statt ebenem Sturz) oder (b) ein komplett +neues, polygonbasiertes Öffnungsmodell. Vorschlag: (a) zuerst — ein +`headShape: "eckig"|"segment"|"spitz"|"rund"` mit Zusatzparametern +(Stichhöhe/Radius), das NUR die obere Kante der bestehenden Rechteck-Öffnung +ersetzt, während Pfosten/Sohlbank rechteckig bleiben. Deckt die reale +Mehrheit der Fälle (Haustür mit Rundbogen, Dachflächenfenster-Giebel) ohne +das Kernmodell umzubauen. + +### 3.3 Lücken (Fenster, Delta zur Studie) + +| Feature | Status | Priorität | Aufwand | +|---|---|---|---| +| `glazing`/`glazingPanes` 2D-wirksam (Scheibenzahl statt nur DetailLevel) | ~ (weiter offen seit Studie) | **P0** | 1 PT | +| `sillBoard` gerendert (2D-Kontur + 3D-Box) | ✗ | P1 | 2 PT | +| Kopfform (Rundbogen/Spitzbogen/Schräge) über Zusatzkontur | ✗ | P2 | 5 PT (s. §3.2) | +| Echtes Sprossengitter (Glasteilung UNABHÄNGIG von Flügelrahmen) | ✗ | P1 | 2 PT | +| Alle übrigen Fenster-Lücken | siehe window-editor-vectorworks-study.md §2/§4 | — | — | + +--- + +## 4. Dach (Roof) + +### 4.1 Was ein vollständiges BIM-Tool bietet + +| Bereich | Typische Parameter | +|---|---| +| Grundform | Pult, Sattel, Walm, Krüppelwalm, Zeltdach, Mansarde (mit Untertyp Giebel-/Walm-/Zeltmansarde), Flach/Terrassendach, Sheddach, Tonnendach, freie Neigungsflächen je Kante | +| Grundriss | beliebiges Polygon (nicht nur Rechteck), automatische Kehlen/Grate über Straight-Skeleton bei L-/T-/U-Grundrissen | +| Neigung | je Dachfläche einzeln editierbar, unterschiedliche Neigungen je Seite | +| Schichtaufbau | Eindeckung (Ziegel/Blech/Bitumen), Lattung, Konterlattung, Unterdach/-spannbahn, Sparren/Dämmung zwischen Sparren, Dampfbremse, Innenverkleidung — analog Wandaufbau, mit Deckenanschluss | +| Überstand | Traufe und Ortgang UNABHÄNGIG editierbar (Betrag + Ausbildung), Aufschiebling (Neigungsknick am Traufende), Ortganddetail (Windbrett, Blech) | +| Kniestock/Drempel | vertikale Wandaufkantung zwischen Deckenoberkante und Dach-Traufpunkt, definiert First-/Trauf-Geometrie mit | +| Öffnungen im Dach | Dachflächenfenster (schräg, in der Dachebene), Dachgauben (Schlepp-, Sattel-, Walm-, Spitzgaube, Fledermausgaube) als eigenständige Sekundärdächer mit eigenem First | +| First/Grat/Kehl/Ortgang | eigene Linientypen in 2D-Ansicht (Dachaufsicht) UND im Schnitt sichtbar (Sparrenlage, Dämmstärke) | +| Material/Poché | Dachfläche in der Aufsicht mit Eindeckungs-Symbol/-Schraffur (Ziegel-Textur o. Ä.), im Schnitt Vollschichten wie eine geneigte Wand | +| IFC-Rolle | `IfcRoof` (aggregiert `IfcRoofType`), Dachflächen selbst oft als `IfcSlab`-artige Elemente mit `IfcMaterialLayerSetUsage`, Gauben als eigene `IfcRoof`/`IfcBuildingElementProxy`-Unterobjekte | + +### 4.2 IST in DOSSIER + +`Roof` (`src/model/types.ts:1022-1047`) rechnet ausschliesslich auf der +**Bounding-Box** des Umrisses (Kommentar `types.ts:1016-1020`: "First entlang +einer Hauptachse ... die gängige, intuitive Vereinfachung"). Geometrie kommt +aus `roofGeometry()`/`computeCanonical()` (`src/geometry/roof.ts:80-267`), +explizit **"ohne Straight-Skeleton"** (Kommentar `roof.ts:5`). Unterstützte +`RoofShape` (`types.ts:1013`): flach/pult/sattel/walm/mansarde/zelt — je EINE +feste Berechnung, keine Untertypen. Mansarde hat eine feste, nicht editierbare +Knick-Geometrie (`d1 = halfD * 0.4`, `roof.ts:181` — 40 % der Tiefe von der +Traufe, hart codiert, keine Möglichkeit den Umbruchpunkt zu verschieben). + +Konkrete, verifizierte Lücken: + +- **Kein Schichtaufbau.** `Roof.thickness` (`types.ts:1044`) ist ein + einzelner Skalar. Er wird an KEINER Stelle im Code gelesen (`grep + "roof.thickness"` über `toWalls3d.ts`/`generatePlan.ts`/`roof.ts` liefert + null Treffer) — das Feld existiert im Typ, ist aber komplett tot. Die + 3D-Dachfläche ist eine unendlich dünne, einfarbige Fläche + (`emitRoofs()`, `src/plan/toWalls3d.ts:1670-1684`: nur `plane.pts`/ + `gable`-Fans, EINE Farbe `ROOF_RGB` bzw. `roof.color`, keine Dicke, keine + Materialschichten). +- **Kein `RoofType`.** `Project` hat `wallTypes`, `ceilingTypes?`, + `doorTypes?`, `windowTypes?`, `stairTypes?` (`types.ts:1936-1958`), aber + kein `roofTypes?`. Es gibt keinen Bauteil-Bibliothekseintrag für Dächer. +- **2D-Grundriss zeigt keine Poché.** `addRoof()` + (`src/plan/generatePlan.ts:2549-2605`) zeichnet AUSSCHLIESSLICH Linien + (Traufe/First/Grat/Knick, je feste Strichstärke `ROOF_EAVES_MM`/ + `ROOF_RIDGE_MM`/`ROOF_HIP_MM`) — keine Fläche, keine Schraffur, keine + Materialkennzeichnung. Deckungsgleich mit Wand/Decke, die BEIDE eine + Poché-Füllung mit Schraffur haben (`addWallPoche`, `addCeilingPoche`), + bleibt das Dach in der Aufsicht ein reines Liniendiagramm. +- **Kein Schnitt.** `src/plan/toSection.ts` hat KEINE Roof-Behandlung (kein + Treffer für `roof`/`Roof` im gesamten Datei-Grep). Ein Vertikalschnitt + durch ein Gebäude mit Satteldach zeigt heute keine Dachlinie, keine + Sparrenlage, keine Firstprojektion — ein Kernstück der BIM-1:1-Erwartung + fehlt vollständig. +- **Kein IFC.** `exportIfc.ts` erzeugt `IfcWall`, `IfcSlab`, `IfcDoor`/ + `IfcWindow`, `IfcStair`, `IfcBuildingElementProxy` (Kommentar + `exportIfc.ts:18-36`) — `Roof`/`IfcRoof` ist in der Abbildungsliste NICHT + aufgeführt und wird beim Export komplett übersprungen. +- **Kein Straight-Skeleton, kein L-Grundriss mit Kehle.** Ein L-förmiger + Baukörper mit durchgehendem Satteldach (Kehle an der Innenecke) lässt sich + nicht abbilden — die BBox-Rechnung würde ein Rechteck über die ganze + L-Ausdehnung legen. +- **Keine Gauben, keine Dachfenster.** Kein Treffer für Gaube/Dormer im + gesamten `src`-Baum (verifiziert per Suche). +- **Kein Kniestock als Bauteilbeziehung.** `baseElevation` (`types.ts:1042`) + erlaubt zwar, die Traufhöhe manuell über die Geschoss-Oberkante zu heben + (ein Kommentar in `ObjectInfoPanel.tsx:549` erwähnt das explizit als + Nutzungsmuster), aber es gibt keine Wand-Dach-Kopplung, die einen + Drempel/Kniestock als eigenes, vermasstes Bauteil führt — der Nutzer muss + die Zahl manuell abstimmen. +- **Traufe/Ortgang nicht unabhängig.** `overhang` (`types.ts:1038`) ist EIN + Wert "ringsum" — Traufüberstand und Ortgangüberstand (oft unterschiedlich, + z. B. 0.5 m Traufe / 0.3 m Ortgang) sind nicht trennbar. +- **UI**: `ObjectInfoPanel.tsx:479-561` bietet volle Instanz-Bearbeitung + (shape/ridgeAxis/pitch/pitchUpper/width/depth/overhang/thickness/ + baseElevation), aber keine Typ-/Stil-Verwaltung (kein `ResourceManager`- + Eintrag für Dächer, anders als Wand/Decke/Tür/Fenster/Treppe). + +### 4.3 Dach-Schichtlogik — konkreter Vorschlag (Kernthema dieses Dokuments) + +Der Vorschlag überträgt exakt das `WallType`/`CeilingType`-Muster: + +``` +export interface RoofType { + id: string; + name: string; + /** Aussen (Eindeckung) → innen (Verkleidung), analog WallType.layers. */ + layers: Layer[]; +} +``` + +Kein neuer Layer-Typ nötig — `Layer` (`types.ts:245`) ist bereits +"Bauteil + Dicke + optionaler Fugen-Linienstil", unabhängig davon ob sie +horizontal (Decke), vertikal (Wand) oder GENEIGT (Dach) gestapelt wird, weil +die Stapel-Richtung beim jeweiligen Renderer entschieden wird, nicht im +Datentyp. Typische Schichtfolge eines Steildachs (Eindeckung → Konterlattung +→ Lattung → Unterdach/Unterdeckbahn → Sparren+Dämmung → Dampfbremse → +Innenverkleidung/GKB) bildet sich 1:1 auf `Layer[]` ab, jede Schicht bekommt +ein `Component` mit eigener Schraffur/Farbe/Material wie bei Wand/Decke. + +`Roof.thickness: number` wird zu `Roof.roofTypeId?: string` (Verweis, analog +`Ceiling.ceilingTypeId`) mit optionaler `thicknessOverride?: number` — exakt +das Muster aus `Ceiling.thickness?` (`types.ts:952-953`, "Optionale +Übersteuerung der Gesamtdicke ... sonst Typ-Dicke"). `Project.roofTypes?: +RoofType[]` ergänzt die Bibliothek. + +**3D-Konsum**: `emitRoofs()` (`toWalls3d.ts:1670`) baut heute EINE +Dreiecksfläche je Dachfläche+Giebel. Mit Layern wird daraus — analog +`emitSlabs()` (`toWalls3d.ts:1352-1419`, das bereits genau diese +Proportional-Stapel-Logik für Decken hat) — ein Stapel PARALLEL versetzter +Flächen entlang der Flächennormalen (nicht entlang Z wie bei der Decke, +sondern entlang der Dachflächen-Normalen `n`, siehe `RoofGeometry.planes` +in `roof.ts:19-21`). Jede Schicht wird zum eigenen `RMesh` mit eigener Farbe/ +Schraffur-Metadaten (`RCutMeta`, wie bei `emitSlabs`). Der Versatz macht +zugleich die Dachdicke sichtbar (heute unendlich dünn) — ein Nebengewinn ohne +Mehraufwand. + +**2D-Konsum (Grundriss/Aufsicht)**: `addRoof()` bekommt eine Poché-Fläche +analog `addCeilingPoche` — Füllung mit der `viewHatchId` der obersten Schicht +(Eindeckungssymbol), gerahmt von den bestehenden Traufe/First/Grat/Knick- +Linien (die bleiben unverändert, sie sind flächen-unabhängig). + +**2D-Konsum (Schnitt, der grössere Umbau)**: `toSection.ts` braucht einen +neuen Roof-Zweig. Ansatz: die Dachebene mit der Schnittebene schneiden +(Ebene-Ebene-Schnitt, da `RoofPlane` eben ist), daraus ein Liniensegment je +betroffener Dachfläche gewinnen, dann `Layer[]` senkrecht ZUR +Dachneigung als Bandsequenz auftragen (wie `resolveWallBands`, +`toWalls3d.ts:521`, aber gedreht um den Neigungswinkel `pitchDeg`) und mit +`splitSlabLayers`-Logik (`toSection.ts:633`) füllen. Das ist der aufwendigste +Einzelposten dieses Dokuments (siehe Prioritätsliste), aber ohne ihn bleibt +"Dach im Schnitt" eine reine Lücke. + +**UI**: Ein `RoofType`-Eintrag im `ResourceManager` +(`src/ui/ResourceManager.tsx`), identisch zum bestehenden Ceiling-Typ-Editor +(Schicht-Liste, Dicke, Bauteil-Zuweisung) — kein neues UI-Paradigma. + +### 4.4 Dach 1:1 — Formen, Kehlen, Gauben (konkreter Vorschlag) + +Reihenfolge nach Aufwand/Nutzen, NICHT alles auf einmal: + +1. **Traufe/Ortgang trennen**: `overhang` → `{ eaves: number; gable: number + }`. Kleine, lokale Änderung in `roof.ts` (zwei statt einer Offset-Variable + je nach Kantentyp), grosser optischer Gewinn (das ist die häufigste + Rückmeldung "sieht nicht echt aus" bei Steildächern mit gleich langem + Überstand allseitig). +2. **Mansard-Untertyp** (`mansardVariant: "walm"|"giebel"|"zelt"`, wie in der + älteren Planung `elements.md:298` bereits vorgesehen, aber nie gebaut): + steuert nur, wie die STIRNSEITE der Mansarde behandelt wird (heute IMMER + `gables` = vertikale Giebelfläche, `roof.ts:200-203`) — bei "walm" wird + daraus eine geneigte Fläche wie beim Walmdach. Mittlerer Aufwand, da die + Mansard-Berechnung (`roof.ts:176-206`) bereits alle Eckpunkte hat, nur die + Gable-Erzeugung muss konditional werden. +3. **Editierbarer Mansard-Knickpunkt** (`kinkDepthRatio?: number` statt hart + `0.4`, `roof.ts:181`) — 0.5 PT, reine Parametrisierung einer bestehenden + Konstante. +4. **Krüppelwalm** (`hipTruncation?: number`, 0 = voller Walm, 1 = voller + Giebel/Sattel): der First bleibt voll lang, nur ein kleines Walmstück am + First-Ende — technisch eine Variation der bestehenden `walm`-Berechnung + (`roof.ts:147-174`, der First-Verkürzungs-Faktor `halfD` wird + parametrisiert statt fix). +5. **Dachflächenfenster** (kein neues Bauteil — ein `Opening`-ähnliches + Element, das in eine Dachfläche statt eine Wand einschneidet): neuer + `hostRoofId`-Pfad, eigenständiger Vorschlag; lohnt sich erst NACH der + Schichtlogik, weil das Fenster sonst nicht "in die Dämmebene" passt. +6. **Gauben** (Schlepp-/Sattelgaube als eigenständiges Sekundär-`Roof` mit + eigenem `outline`/`baseElevation`, das in die Hauptdachfläche einschneidet): + grösster Einzelposten, weil er eine echte Boolean-Verschneidung zwischen + zwei Dachkörpern braucht (ähnlich der bestehenden Wand-Boolean-Dominanz + über `joinPriority`, aber räumlich in 3D). Realistisch erst nach einem + Mesh-Boolean-Werkzeug (die begonnene truck-Integration, + `src-tauri/trucksolid/`, ist ein Kandidat dafür). +7. **L-/T-Grundriss mit Kehle (Straight-Skeleton)**: bewusst NICHT vor 6, + weil es die Bounding-Box-Vereinfachung komplett ersetzt (neue + Geometrie-Engine, kein inkrementeller Ausbau von `roof.ts`) — separates, + grosses Vorhaben, siehe Prioritätsliste. + +### 4.5 Lücken (Dach) + +| Feature | Status | Priorität | Aufwand | +|---|---|---|---| +| `RoofType`/`Layer[]`-Schichtaufbau (Modell) | ✗ (`thickness` toter Skalar) | **P0** | 3 PT | +| 3D-Schichten (gestapelte Flächen entlang Normalen) | ✗ | **P0** | 3 PT | +| 2D-Aufsicht-Poché (Eindeckungssymbol) | ✗ | P1 | 1.5 PT | +| Dach im Vertikalschnitt (Ebene-Ebene-Schnitt + Bänder) | ✗ | **P0** | 5 PT | +| Traufe/Ortgang getrennter Überstand | ✗ | **P0** | 1 PT | +| Mansard-Untertyp (Walm/Giebel/Zelt-Stirn) | ✗ | P1 | 2 PT | +| Editierbarer Mansard-Knick | ✗ | P2 | 0.5 PT | +| Krüppelwalm | ✗ | P2 | 1.5 PT | +| Dachflächenfenster | ✗ | P2 | 4 PT | +| Gauben (Boolean-Einschnitt) | ✗ | P3 | 8+ PT | +| L-/T-Grundriss, Straight-Skeleton-Kehle | ✗ | P3 | 10+ PT | +| `RoofType`-Ressourcen-UI | ✗ | P1 (folgt aus RoofType) | 1 PT | +| IFC `IfcRoof`-Export | ✗ | P2 | 1.5 PT | + +--- + +## 5. Decke (Ceiling / Slab) + +### 5.1 Was ein vollständiges BIM-Tool bietet + +| Bereich | Typische Parameter | +|---|---| +| Grundfläche | beliebiges Polygon inkl. Aussparungen (Treppenauge, Schacht, Kamindurchbruch) | +| Schichtaufbau | Rohdecke, Trittschalldämmung, Estrich, Bodenbelag — analog Wand, mit Deckenspiegel/Untersicht (abgehängte Decke, Akustikplatten) als eigene Schicht(en) | +| Randausbildung | gerader Rand, auskragender Balkon-/Vordachrand mit thermischer Trennung (Isokorb/Randdämmstreifen), Randschalung/Abschalungsprofil, Attika-Anschluss, Tropfkante | +| Deckenspiegel | abgehängte Untersicht mit eigener Höhe/Raster (Akustik-/Gipskarton-Decke), UNABHÄNGIG von der tragenden Rohdecke | +| Öffnungen | Deckenaussparungen als eigene, editierbare Polygone (nicht nur Gesamtumriss) | +| Neigung | geneigte Decke (Garagenrampe, Terrasse mit Gefälle) — nicht nur horizontal | +| 2D-Darstellung | Aufsicht mit Ansichts-Poché (unaufgeschnitten), Schnitt mit Vollschichten je Lage, Deckenspiegel-Plan (reflected ceiling plan) als eigene Zeichnungsart | +| IFC-Rolle | `IfcSlab` (PredefinedType FLOOR/ROOF/BASESLAB), `IfcMaterialLayerSetUsage` für den Schichtaufbau, `IfcCovering` für abgehängte Decken | + +### 5.2 IST in DOSSIER + +`Ceiling` (`types.ts:928-1000`) hat bereits die stärkste Tiefe der vier +Bauteile in diesem Dokument: geschlossenes Umriss-Polygon (`outline`), +`ceilingTypeId` mit Legacy-Fallback auf `wallTypeId` (`getCeilingType`, +`types.ts:2089`), volle Attribut-Override-Kette (`foreground`/`background`/ +`strokeWeight`/`hatchId` + `*Source`, wie bei `Wall`) und unabhängige +vertikale Bindung von OK/UK über `VerticalAnchor` (`top?`/`bottom?`, +`types.ts:990-999` — "floor"-gebunden oder "custom"-Z, exakt wie bei +`Wall.top`/`Wall.bottom`, `types.ts:887-893`). 3D-Schichtstapel ist +implementiert (`emitSlabs`, `toWalls3d.ts:1352-1419`), Schnitt-Schichtsplit +ebenfalls (`splitSlabLayers`, `toSection.ts:633`). + +Verifizierte Lücken: + +- **Keine Aussparungen.** `Ceiling.outline: Vec2[]` ist EIN geschlossenes + Polygon (`types.ts:936-939`) — kein `openings?: Vec2[][]` für + Treppenauge/Schacht/Kamin. Ein Treppenloch in der Decke muss heute über + die Aussenkontur der Decke "herumgeschnitten" werden (Decke als + komplexes, nicht-konvexes Polygon), nicht als saubere Innenaussparung. + (`elements.md:217` sah dieses Feld in der älteren Planung explizit vor, + es wurde nie in `types.ts` übernommen.) +- **Kein Randdetail.** Die Decke ist über die gesamte `outline` exakt + `thickness` dick, EINHEITLICH. Es gibt kein Feld für eine abweichende + Randausbildung (Aufkantung, Randdämmstreifen, Tropfkante, andere Dicke am + Balkonrand). Ein auskragender Balkon lässt sich zwar über eine erweiterte + `outline` modellieren, bekommt aber zwangsläufig denselben Vollschicht- + Aufbau wie die Innendecke — eine thermisch getrennte Balkonplatte + (Isokorb) ist nicht abbildbar. +- **Kein Deckenspiegel.** Abgehängte Untersicht (Akustik-/GKB-Decke mit + eigener, tieferer Kote) existiert nicht als eigenes Konzept — nur der + tragende Aufbau über `ceilingTypeId`. + Ein "Deckenspiegel-Plan" (reflected ceiling plan) fehlt als Zeichnungsart + komplett (`DrawingLevelKind`, `types.ts:722`, kennt nur "floor"/"section"/ + "elevation"/"drawing"). + (Randbemerkung: Beleuchtungsplanung/Deckenspiegel ist ein Elektro-Thema und + damit bewusst ausserhalb des DOSSIER-Kernscopes — siehe "nicht bauen", + Abschnitt 6. Die reine Geometrie einer zweiten, tiefer liegenden Fläche + bleibt aber ein legitimer BIM-1:1-Punkt.) +- **Keine Neigung.** `top`/`bottom` sind je EIN `VerticalAnchor` (ein + Z-Wert), keine Neigungsebene — eine geneigte Garagen-/Terrassendecke ist + nicht modellierbar, nur über mehrere ebene Teildecken behelfsweise + annäherbar. +- **2D-Aufsicht nutzt nur die erste Schicht.** `addCeilingPoche` + (`generatePlan.ts:2453-2536`) liest `wt.layers[0]` (Kommentar/Code + `generatePlan.ts:2465`) für die Ansichts-Schraffur — bei einer + mehrschichtigen Decke (z. B. Beton unten, Dämmung oben) zeigt die Aufsicht + immer nur die OBERSTE (erste) Schicht, was für eine unaufgeschnittene + Draufsicht baupraktisch korrekt ist (man sieht von unten die + Untersicht/erste Lage), aber nicht konfigurierbar ist, welche Lage als + "sichtbare" gilt, falls der Deckenaufbau umgekehrt sortiert wäre. +- IFC: `IfcSlab` wird erzeugt (`exportIfc.ts:28`), aber laut Kopfkommentar + (`exportIfc.ts:38-41`) bewusst OHNE `IfcMaterialLayerSet`/-`Usage` — der + Export verliert den Schichtaufbau, den DOSSIER intern bereits hat. + +### 5.3 Deckenrand/Randterminierung — vertieft + +Der Nutzer nennt explizit "Deckenränder, Stirnabschlüsse, Anschluss an Wand/ +Aussenkante, auskragende Ränder, Randabschalung" als Schwerpunkt. IST-Bild: +keines davon existiert als eigenes Konzept — die Decke ist ein reines +Extrusions-Polygon. Konkreter Vorschlag, dreistufig nach Aufwand: + +1. **Aussparungen** (`Ceiling.openings?: Vec2[][]`) — niedrigster Aufwand, + grösster praktischer Nutzen (Treppenauge ist im Wohnbau der Regelfall, + nicht die Ausnahme). 2D: zusätzliche Ausschnitts-Polygone in + `addCeilingPoche` (Loch im Fill, zusätzliche Randlinien). 3D: `emitSlabs` + bekommt Löcher im Extrusions-Profil (analog dem bereits vorhandenen + Loch-Schnitt bei Wand-Öffnungen, `wallMeshCut.ts`, als Vorlage). +2. **Randschicht-Override** (`Ceiling.edgeOverride?: { ringOffset: number; + ceilingTypeId: string }` — ein schmaler Innenring der Decke entlang des + Randes bekommt einen ANDEREN Layer-Aufbau, z. B. mit zusätzlicher + Randdämmschicht oder reduzierter Dicke für eine Tropfkante). Technisch: + `emitSlabs` erzeugt für den Ringbereich einen zweiten Layer-Stapel mit dem + Override-Typ, geometrisch als Offset-Polygon-Differenz (`outline` minus + `outline.offset(-ringOffset)`), eine Operation, die für Wandbänder + bereits ähnlich existiert (`buildWallFootprints`). +3. **Thermisch getrennte Auskragung (Isokorb-Fall)**: ein eigenes, + sekundäres `Ceiling`-Objekt für den auskragenden Teil mit eigenem + `ceilingTypeId` (dünnerer/anderer Aufbau) UND eigener `top`/`bottom`- + Bindung, das an die Hauptdecke stösst — kein neues Feld nötig, nur eine + UI-Erleichterung ("Deckenrand abtrennen"-Werkzeug, das die Decke entlang + einer gewählten Kante in zwei `Ceiling`-Objekte teilt). Niedrigster + Modell-Aufwand, weil er das bestehende Mehrfach-Decken-Prinzip nutzt statt + ein neues Konzept einzuführen. + +### 5.4 Lücken (Decke) + +| Feature | Status | Priorität | Aufwand | +|---|---|---|---| +| Aussparungen (`openings?: Vec2[][]`) in 2D+3D | ✗ | **P0** | 3 PT | +| Randschicht-Override (Ringzone anderer Aufbau) | ✗ | P1 | 3 PT | +| Deckentrenn-Werkzeug für Isokorb-Fall (UI, kein neues Modellfeld) | ✗ | P1 | 1.5 PT | +| Geneigte Decke (Rampe/Gefälle) | ✗ | P2 | 3 PT | +| Deckenspiegel (zweite, abgehängte Fläche) | ✗ | P3 | 2 PT (reine Geometrie) | +| IFC `IfcMaterialLayerSetUsage` für Decke (UND Wand) | ~ (bewusst ausgelassen) | P2 | 2 PT | +| Konfigurierbare "oberste Schicht" für Aufsicht-Poché | ✓ implizit (Layer-Reihenfolge = Sortierung) | — | — | + +--- + +## 6. Konsolidierte Priorisierung (über alle vier Bauteile) + +Sortiert nach "1:1-Zuwachs pro Aufwand", nicht nach Aufwand allein: + +1. **Dach-Schichtaufbau (Modell + 3D-Stapel)** — schliesst die grösste + strukturelle Lücke (totes `thickness`-Feld, kein `RoofType`) und liefert + sofort sichtbaren Tiefengewinn im 3D (§4.3, ~6 PT gesamt). +2. **Traufe/Ortgang getrennter Überstand** — 1 PT, sofortiger optischer + Sprung bei jedem Steildach-Projekt (§4.4 Punkt 1). +3. **Zweiflügelige Tür rendert wirklich 2 Blätter** — das `leafCount`-Feld + existiert seit der Türtyp-Einführung, wird aber komplett ignoriert; sehr + sichtbarer Bug-artiger Gap (§2.3, 2 PT). +4. **Deckenaussparungen** — Treppenauge ist der Wohnbau-Regelfall, heute nur + über Umweg (nicht-konvexes Aussenpolygon) lösbar (§5.3 Punkt 1, 3 PT). +5. **Fenster-Glazing 2D-wirksam** — seit über einem Jahr als P0 in der + Fenster-Studie dokumentiert und weiterhin offen; niedriger Aufwand, + sollte nicht liegen bleiben (§3.1, 1 PT). +6. **Dach im Vertikalschnitt** — grösster Einzelposten (5 PT), aber ohne ihn + bleibt jeder Gebäudeschnitt mit Steildach unvollständig; das ist die + Art Lücke, die bei einer Bemusterung/Baueingabe sofort auffällt. +7. **Deckenrand-Override / Isokorb-Trennwerkzeug** — folgt danach, weil er + auf demselben Mehrfach-Decken-Prinzip aufbaut wie Punkt 4. +8. **Mansard-Untertyp + editierbarer Knick** — mittlere Priorität, weil + Mansarde in der Schweiz/Süddeutschland baupraktisch häufig ist und die + heutige starre 40 %-Konstante sichtbar unrealistisch wirkt. +9. **Tür/Fenster-Rahmentiefe** (asymmetrische Rahmenbreiten, Beschlag, + Kopfform) — bewusst NACH den strukturellen Lücken, weil sie additive + Detailverbesserungen an einem bereits funktionierenden Pfad sind, während + 1–7 fehlende oder falsch dargestellte Kernfunktionen betreffen. +10. **Gauben, L-Grundriss/Kehle, Dachflächenfenster** — grösste Einzel- + Aufwände (8–10+ PT), architektonisch am voraussetzungsreichsten (Boolean- + Werkzeug bzw. neue Geometrie-Engine); erst nach 1–9 angehen. + +### 6.1 NICHT bauen (VW/Revit-Ballast ohne Nutzen für DOSSIER) + +- **Vollständiger Massketten-/Bezugsapparat** (VW B1..B5/H1..H7, + Roh-/Fertigmass-Umschaltung) — DOSSIER arbeitet mit lichten Massen, das + genügt für ein Schweizer Wohnbau-/Kleinprojekt-Tool (bereits so in + `window-editor-vectorworks-study.md` §5 entschieden, hier bestätigt für + Dach/Decke: keine Dach-Rohmass-/Fertigmass-Unterscheidung). +- **Sichtbarkeitsmatrix 3D-Objekte × Ansichten** (Augen-Tabelle je + Kategorie×Ansicht×Detailstufe) — DOSSIERs Layer-Sichtbarkeit + + `DetailLevel` deckt den praktischen Bedarf; eine volle Matrix ist + Verwaltungsaufwand ohne Mehrwert für Einzelprojekte. +- **Eckfenster/Eckdach als generischer Sonderfall über zwei Wirtsbauteile** + — seltene Geometrie, hoher Modellierungsaufwand (zwei Hosts, ein Element); + bei Bedarf als manueller Workaround (zwei separate Öffnungen) lösbar. + Ebenso: freie Neigungsflächen je Dachkante (VW erlaubt jede Kante einzeln + zu kippen) — für die abgedeckten Standardformen (Pult/Sattel/Walm/ + Mansarde/Zelt/Krüppelwalm) nicht nötig; wer eine Freiform-Dachlandschaft + braucht, ist besser mit den `ExtrudedSolid`/truck-Werkzeugen bedient. +- **Vollständige Beschlags-/Baubeschlag-Bibliothek** (Marken-Beschlagsätze, + Schliessplan) — Beschlag als generisches Griff-Mesh (§2.4) genügt für die + visuelle 1:1-Wirkung; eine Beschlags-PRODUKTBIBLIOTHEK ist Kataloggeschäft, + kein CAD-Kernfeature. +- **Deckenspiegel als vollwertige Beleuchtungsplanung** (Leuchtenraster, + Lichtberechnung) — reine Geometrie einer zweiten Fläche ist ok (P3), die + Elektro-/Lichtplanungslogik selbst liegt ausserhalb des Tool-Zwecks. +- **IFC `IfcOpeningElement`/Void-Semantik nachrüsten** — bewusste + Design-Entscheidung im bestehenden Export (`exportIfc.ts:22-27`), NICHT + revidieren: die heutige "Loch steckt im Mesh"-Lösung liefert visuelle + Parität in jedem Viewer ohne Boolean-Pflicht beim Empfänger; der reine + IFC4-Purismus (Wand als parametrische Extrusion + Void) würde + bestehende, bewusst getroffene Trade-offs zunichtemachen. +- **Straight-Skeleton/Kehlen und Gauben SOFORT** — nicht "nicht bauen", aber + bewusst zurückgestellt (§6, Punkt 10): ohne die Schichtlogik (Punkt 1) + vorher zu bauen, würde jede Kehlen-/Gauben-Lösung auf dem unendlich dünnen, + ungeschichteten Dach aufsetzen und müsste bei Einführung der Schichten + ohnehin neu gefasst werden.