diff --git a/PENDENZEN.md b/PENDENZEN.md index 119247b..87abfa0 100644 --- a/PENDENZEN.md +++ b/PENDENZEN.md @@ -24,6 +24,21 @@ ## 🔧 In Arbeit +- [ ] **GEO-BLOCK Folgepunkte (2026-07-12, nach dem swissBUILDINGS3D-DXF-Fix)** — Nutzer-Report, noch NICHT umgesetzt: + - **Georeferenzierung fehlt strukturell:** Jeder Import (`fetchBuildings3d`/`fetchBuildings`/`fetchOsm`/`fetchTerrainXyz`) berechnet seine `GeoOrigin` aus dem GESUCHTEN Standort (`makeOrigin(center)`, sucht Zentrum → Modell-(0,0)) — es gibt KEIN `Project`-Feld, das verbindet „mein Wand-Grundriss sitzt HIER im Modell" mit „das entspricht DORT in LV95". Funktioniert nur, wenn zufĂ€llig das eigene GebĂ€ude nahe Modell-(0,0) gezeichnet UND exakt die eigene Adresse gesucht wurde — sonst landet importierter Kontext (NachbargebĂ€ude/Terrain) lagefalsch relativ zu den eigenen WĂ€nden. Nutzer-Zitat: „ich hab das GefĂŒhl du platzierst das nicht georeferenziert". Braucht einen echten Referenzpunkt-Mechanismus (Nutzer klickt einen Punkt im Grundriss, ordnet ihm eine reale Adresse/Koordinate zu — vermutlich ein neues `Project`-Feld + Werkzeug/Dialog). **Nicht umgesetzt, Design mit Nutzer klĂ€ren.** + - **Importierte GebĂ€ude sollen anwĂ€hlbare Meshes auf einer Ebene sein, nicht nur ein Geo-Panel-Eintrag.** Aktuell landen sie in `project.context` (`ImportedMesh`), nur in `SitePanel`/`ContextImportDialog` sichtbar/entfernbar — kein Ebenen-Zuordnung, keine normale Element-Auswahl im 3D/Grundriss wie Wand/Dach/Decke. **Nicht umgesetzt, Design mit Nutzer klĂ€ren** (welche Ebene? Wie weit soll die Auswahl gehen — nur Farbe/Löschen, oder volle Attribut-Bearbeitung wie andere Bauteile?). + - ✅ **Zwei echte Bugs im swissBUILDINGS3D-Pfad behoben (`35a6834`+`9705890`):** (1) Absturz bei riesigen Kacheln (JSZip „Invalid string length" — DXF komprimiert stark, eine Kachel unter dem 150-MB-Limit kann entpackt trotzdem >700 MB Text ergeben; nur `asset.size` aus der STAC-API zu prĂŒfen reichte nicht, jetzt zusĂ€tzlich die JSZip-interne GrössenschĂ€tzung + genereller Try/Catch, ĂŒbersprungene Kacheln landen sichtbar in `skippedTiles`/UI-Meldung statt stumm 0 GebĂ€ude). (2) **Der eigentliche „Import funktioniert nicht"-Bug:** die installierte `dxf-parser`-Version liefert Polyface-Mesh-Face-Indizes als vier einzelne Felder (`faceA`/`faceB`/`faceC`/`faceD`, Gruppencodes 71–74) statt als `faces`-Array — unser Code prĂŒfte auf das Array, das nie existierte, jede swissBUILDINGS3D-DXF-Kachel ergab dadurch 0 Dreiecke. Live gegen echte Kacheln verifiziert: jetzt tausende Dreiecke mit realistischen Höhenwerten. **Damit ist der GebĂ€ude-Import technisch lauffĂ€hig — die beiden Design-Punkte oben (Georeferenzierung, Ebenen-Zuordnung) bleiben offen.** + +- [ ] **3D-Kanten-Folgepunkte ("Schattiert mit Kanten", 2026-07-12)** — nach dem Fix der falschen FlĂ€chendiagonalen (`7dc8f0d`) zeigte der Nutzer drei weitere Beobachtungen, NOCH NICHT behoben: + - **Fenster-Rahmenecken ĂŒberlappen statt sauber zu stossen** (Screenshot: doppelte/kreuzende Linien an den Blendrahmen-Ecken bei „fein"). Vermutlich KEIN Kanten-Rendering-Bug, sondern echte ĂŒberlappende Geometrie — die Rahmen-/Sprossen-Riegel (`openingAxisBox` in `toWalls3d.ts`) sind separate Boxen ohne Gehrung/Union an den Stössen. **Nutzer-Folgewunsch dazu:** bei „fein" einstellbar machen, ob die Ecke vertikal-dominant, horizontal-dominant oder auf Gehrung gelöst wird. + - **Dach ebenfalls kein sauberer Verschnitt am First/Grat** (Screenshot: kleines Störtriangle exakt am First-Apex). Gleiche Kategorie — mehrere DachflĂ€chen (`emitRoofs`) sind separate, nicht verschnittene Meshes. + - **Im OG viele vertikale Striche auf den WandflĂ€chen** — noch NICHT diagnostiziert (nicht als Textur-Pipeline-Artefakt bestĂ€tigt, evtl. eine mehrschichtige Wandtyp-Verkleidung mit vielen dĂŒnnen Einzelelementen). **Braucht weitere Untersuchung**, idealerweise mit Angabe welcher Wandtyp/welche Schicht im betroffenen Projekt verwendet wird. + - Alle drei sind vermutlich FĂ€lle fĂŒr eine echte Boolean-Verschneidung (Kandidat: `csgrs`/`boolean_mesh`, bereits als WASM-Export vorhanden aus der truck-Integration, s. u.) statt nur Kanten-Heuristik — grösserer, eigener Task. + +- [ ] **Warteschlange „fĂŒr danach" (Nutzer 2026-07-12, noch nicht begonnen):** + - Luftbild/SWISSIMAGE wahlweise als Drapierung auf das Terrain-Mesh ODER als eigenstĂ€ndiges „Dokument" einfĂŒgbar (Bild/PDF generell als einfĂŒgbares Dokument-Objekt — noch keine Anforderungen prĂ€zisiert). + - Import-Mesh (swissBUILDINGS3D u. Ä.) wahlweise geglĂ€ttet („gerundet") oder kantig/eckig belassen, wĂ€hlbar beim Import oder am Objekt. + - [ ] **truck-Integration (Profil-Extrusion / B-Rep)** (Plan: [docs/design/truck-plan.md](docs/design/truck-plan.md)). Ziel: Nutzer zeichnet 2D-Querschnitt → truck-Extrusion → 3D-Körper + spĂ€ter Boolean gegen Wand/Decke. Umfang gesamt: ~4–6 Wochen. Fortschritt: - [x] Phase 1: Geometrie-Schicht — Crate `src-tauri/trucksolid` (`extrude_polygon_core`/`extrude_circle_core`, `truck_modeling` nur zur B-Rep-Validierung/`try_attach_plane`/`tsweep`, Tessellierung manuell aus den Ring-Koordinaten — truck-rendimesh-Tessellierung fĂŒr Solids in 0.3 nicht verfĂŒgbar, daher Abweichung vom Übergabe-Dokument), WASM-Bindings (Feature `web`) + `build:truck`-Script + `exclude`-Eintrag, TS-Wrapper `src/engine/truckSolid.ts` (`extrudePolygon`/`extrudeCircle`), `RMeshKind` um `"extrusion"` erweitert (`toWalls3d.ts`). Verifiziert: `cargo test` 5/5 grĂŒn, `npm run build:truck` sauber, `tsc --noEmit` 0 Fehler, `vitest run` 339/339 grĂŒn. - [x] Phase 2 (MVP, Nutzer-Entscheid 2026-07-06: **"Nur Viewer-Wiring"**, kein Werkzeug/Store) — Ende-zu-Ende-Beweis, dass die Pipeline bis ins Bild funktioniert: ein fest verdrahtetes L-Profil (`emitTruckFixture` in `toWalls3d.ts`, 2 m abseits vom Ursprung) wird bei Bedarf per `trucksolid`-WASM extrudiert und erscheint im 3D-Viewport. **Zwei echte LĂŒcken dabei gefunden und geschlossen:** (1) `render3d::types::MeshKind` kannte nur `Terrain`/`Imported` — ein `kind:"extrusion"` ohne passende Rust-Variante hĂ€tte die serde-Deserialisierung des GESAMTEN Modell-Pushes zum Absturz gebracht (nicht nur die Fixture); `Extrusion`-Variante + warmes Orange als Default-Farbe ergĂ€nzt (`cargo test` render3d 58/58 weiterhin grĂŒn). (2) `updateModel(project)` lĂ€uft nur bei ProjektĂ€nderung (`useEffect`-Dep `project`) — die asynchron ladende Fixture hĂ€tte trotz Erfolg NIE einen Re-Push ausgelöst; Fix via Browser-Event `TRUCK_FIXTURE_READY_EVENT` (`toWalls3d.ts` dispatcht, `Wasm3DViewport.tsx` hört + stösst `updateModel` erneut an). **Visuell verifiziert** (Playwright, `?engine=wasm`, Chromium mit `--use-angle=metal` fĂŒr echten WebGPU-Adapter headed): orangene Extrusion sichtbar neben dem Demo-Haus im Viewport. `tsc --noEmit` + `vitest run` 339/339 + `cargo test` render3d 58/58 grĂŒn. **Noch uncommittet** (Bearbeiter committet nicht selbst). @@ -194,6 +209,8 @@ _Nur jĂŒngste Session; Ă€ltere Historie siehe `git log` und HANDOVER-Narrative._ +- [x] 2026-07-12 **3D-Ansicht: „Schattiert mit Kanten" (BIM-Look) + Fix falscher FlĂ€chendiagonalen** (`a84dc7a`+`7dc8f0d`) — neuer `RenderStyle::ShadedEdges` (render3d): Bauteilfarben + dunkle Modell-Kanten obenauf, wie Revit/ArchiCAD. Direkt danach Nutzer-Report: sichtbare Dreiecks-Diagonalen auf Dach/Fensterglas im neuen Modus. Root Cause: Kontext-Meshes (Dach/Glas/Rahmen, auch swissBUILDINGS3D-Import) werden wegen aktivem Backface-Culling IMMER doppelseitig aufgebaut (`mesh.rs::push_ctx_tri`, Dreieck + gespiegelte RĂŒckseite) — jede Kante bekam dadurch ein exakt entgegengesetztes Normalen-Paar, das die Knick-Erkennung fĂ€lschlich als Kante wertete. Fix in `edges.rs::should_draw`: RĂŒckseiten-Duplikate (dot≈-1) werden vor der Rand-/Knick-Entscheidung zusammengefĂŒhrt. +11 Rust-Tests, 88/88 grĂŒn (`--features render`). **Drei Folgepunkte dabei entdeckt, noch offen** (s. „🔧 In Arbeit" oben): Fenster-Rahmenecken/Dach-First ohne sauberen Verschnitt (vermutlich fehlende Boolean-Union, kein Kanten-Bug), OG-WandflĂ€chen mit vielen vertikalen Strichen (nicht diagnostiziert). +- [x] 2026-07-12 **swissBUILDINGS3D-Import repariert: Absturz + eigentlicher „funktioniert nicht"-Bug** (`35a6834`+`9705890`) — zwei getrennte, echte Bugs gefunden und behoben. (1) Harter Absturz (JSZip „Invalid string length") bei Kacheln, deren ENTPACKTE Grösse (DXF komprimiert stark) die max. JS-String-LĂ€nge sprengt, obwohl die ZIP-Grösse selbst unter dem Limit lag — `downloadAssetText` prĂŒft jetzt zusĂ€tzlich die JSZip-interne GrössenschĂ€tzung und fĂ€ngt alle Fehler sicher ab; ĂŒbersprungene Kacheln landen sichtbar in `skippedTiles`/einer UI-Meldung statt eines stummen Leer-Ergebnisses. (2) **Der eigentliche Grund, warum der Import nie GebĂ€ude lieferte:** die installierte `dxf-parser`-Version liefert Polyface-Mesh-Face-Indizes als vier einzelne Felder (`faceA..faceD`, Gruppencodes 71–74) statt als erwartetes `faces`-Array — `addPolyfaceMesh` prĂŒfte auf ein Array, das nie existierte, jede swissBUILDINGS3D-DXF-Kachel (exakt dieses Format) ergab dadurch 0 Dreiecke. Live gegen echte Kacheln verifiziert (vorher 0 Meshes, jetzt tausende Dreiecke mit realistischen Höhenwerten). +3 Tests mit rohem DXF-Text (deckt auch die zugrundeliegende Bibliothek ab), Suite 794 grĂŒn. **Georeferenzierung und „anwĂ€hlbares Mesh auf Ebene statt Geo-Panel-Eintrag" bleiben als eigene, ungelöste Design-Fragen offen** (s. „🔧 In Arbeit" oben). - [x] 2026-07-12 **Fenster-Grundriss komplett ĂŒberarbeitet** (`e65a6b7`..`d2758ef`, iterativ ĂŒber mehrere Live-PrĂŒfungsrunden in Tauri) — Nutzer-Report mit SIA-Referenzbildern deckte mehrere ĂŒbereinanderliegende Probleme auf, alle einzeln gefixt + verifiziert: - Sims/Anschlag-Kerben nutzten pauschal die volle WandflĂ€che statt der tatsĂ€chlichen (ggf. per `insetFromFace` eingezogenen) Rahmen-Aussenkante. - Stulp-Marken waren kleine, von der Rahmentiefe unabhĂ€ngige Quadrate statt Profilquerschnitte ĂŒber die GANZE Rahmentiefe; die Blendrahmen-Querschnittsblöcke an den Laibungs-Enden fehlten komplett — beide jetzt als `meetingMarks` in `windowSymbol` berechnet (inkl. Laibungs-Enden), `generatePlan.ts` nutzt sie direkt statt einer zweiten, abweichenden Neuberechnung.