Vom „undefinierten Kasten" zur wasserdichten Kachel

Lifetiles druckt Marathon-Strecken als taktile Hexagon-Kacheln: Terrain, Gewässer, Brücken, Gebäude — als ein einziges, physisches Objekt. Solange der Kurs kompakt ist (ein Stadtmarathon), passt genug Maßstab für erkennbare Straßenzüge auf die Kachel. Bei lang gezogenen Strecken (Trail-Läufe, Karwendelmarsch, alles über ~15 km Ausdehnung) zwingt die Geometrie einen deutlich kleineren Maßstab — und genau dort brach das bisherige Gebäude-Rendering zusammen: Städte am Streckenrand (Innsbruck beim Karwendelmarsch, Garmisch-Partenkirchen beim GaPa Trail) wurden zu einem einzigen, formlosen schwarzen Klumpen.

Statt am Code zu raten, wurde das Addon in einem reproduzierbaren Blender-Container gegen drei reale Strecken laufen gelassen — München Marathon 2025 (kompakt), GaPa Trail Langstrecke (Stadt am Rand) und Karwendelmarsch (extrem lang gezogen) — mit echten, aktuellen Overture-Maps-Daten. Das deckte fünf zusammenhängende Konstruktionsfehler auf, von denen zwei überraschend gravierend waren:

• Die Hülle war nicht nur unschön, sie war ein Symptom. Die konvexe Hülle kaschierte eine tiefere Schwäche: extreme Maßstäbe rundeten Gebäudehöhen auf null — bei 1:243.600 waren 728 von 731 Karwendelmarsch-Gebäuden faktisch flache, kaputte Flächen.
• Die Kachel wurde teilweise ohne Gebäude ausgeliefert — bei bestandenem Test. Diese kaputten Gebäude ließen die anschließende 3D-Verschmelzung mit dem Gelände lautlos scheitern; der automatische Test prüfte nur „Objekt vorhanden", nicht „Objekt tatsächlich enthalten" — ein Blindspot, der ohne diese Analyse vermutlich erst bei Kunden aufgefallen wäre.

Kurz nachdem die Korrektur aus Akt 2 produktiv war, meldete die Qualitätskontrolle: die exportierten Druckdateien zeigten extrem dünne, gebrochene Wände und fehlende Dächer — schlechter als vor der Korrektur. Das war kein Rückfall in Akt 1, sondern ein neuer, eigenständiger Fehler: Der 3D-Druck-Export zerlegt jede Gebäude-Dachfläche in Dreiecke für den Drucker. Das bisherige Verfahren dafür (ein simpler „Fächer" von einer Ecke aus) war für die alten, immer konvexen Hüllen unsichtbar harmlos — funktioniert aber bei den neuen, realistisch geformten (und damit oft konkaven) Gebäudeumrissen aus Akt 2 nicht mehr zuverlässig.

Die Nachfrage aus Akt 3 — „können wir das grundsätzlich neu denken, jetzt wo wir eh dabei sind?" — löste eine vollständige Architektur-Untersuchung der Geometrie-Erzeugung aus. Ergebnis: die exportierte Kachel-Basis war noch nie im strengen Sinn wasserdicht gewesen — schon die Produktionsversion von vor dieser ganzen Analyse-Runde enthielt 1.945 offene Kanten und 6.703 mehrfach belegte Kanten, weil Terrain und Hexagon-Grundplatte sich an ihren Nahtstellen absichtlich überlappten und Blenders eingebautes 3D-Verschmelzungswerkzeug bei nicht perfekt „sauberer" Geometrie lautlos versagen konnte, statt einen Fehler zu melden. Slicer haben das bisher toleriert — aus Glück, nicht aus Garantie.

Die Lösung ersetzt Blenders bisherige Boolesche Verschmelzungs-Kaskade durch eine exakte CSG-Komposition auf Basis der Bibliothek manifold3d — derselben Technologie, mit der auch professionelle CAD-Systeme Volumenkörper verschneiden. Der gesamte Kompositions-Schritt läuft jetzt in einer eigenständigen, von Blender unabhängigen Codeschicht, die sich ohne die grafische Oberfläche automatisiert testen lässt. Jede exportierte Kachel-Basis ist dadurch nicht mehr „wahrscheinlich in Ordnung", sondern nachweisbar: null offene Kanten, null mehrfach belegte Kanten, geschlossenes Volumen — geprüft bei jedem einzelnen Export, mit hartem Abbruch statt stillem Weiterlaufen bei einem Defekt.

Dieselbe Disziplin aus Akt 4 wurde konsequent auf Brücken angewendet: die alte, unbestimmt „gute" BMesh-Brückengeometrie (Deck + Bogen + Pfeiler, von Hand entworfen) wurde komplett durch eine deterministische, manifold-by-construction-Pipeline ersetzt — dieselbe CSG-Bauweise, mit der Akt 4 bereits Gebäude wasserdicht gemacht hat. Vier Phasen, jede unabhängig testbar: (1) deterministische Brücken-Topologie, (2) Regime A — die sichere Standard-Brücke, (3) Regime B — druckbare Hohlräume für Wahrzeichen-Brücken mit echter Durchfahrtshöhe, (4) Verifikation gegen echte Düsseldorfer und Münchner Daten.

Der Blick auf echte Renderings von Düsseldorf- und München-Marathon-Kacheln zeigt ein bislang unadressiertes Problem: an Flussufern, Biegungen und Mündungen erscheinen unruhige, scharfkantige Dreiecks-Fetzen statt einer glatten Wasserfläche — sichtbar dieselbe Handschrift wie die „sternförmigen Dreiecks-Fetzen" aus Akt 3, nur an Wasser statt an Dächern. Der Grund ist derselbe strukturelle: Wasser ist die einzige verbleibende Geometrie-Klasse, die die manifold-by-construction-Disziplin aus Akt 4 (Gebäude) und Akt 5 (Brücken) nie bekommen hat.

WaterBuilder.create_water_surface triangulierte die Fluss- und Seepolygone bislang mit Blenders eingebautem Ear-Clipping-Verfahren (tessellate_polygon) statt mit der manifold3d-CrossSection-Extrusion, die Gebäude und Brücken längst nutzen — und prüfte das Ergebnis nur auf grobe Nicht-Mannigfaltigkeit, nicht auf Qualität. Beim 3MF-Export wird dieselbe Fläche ein zweites Mal trianguliert, diesmal mit mapbox_earcut. Zwei unabhängige Ear-Clipper auf derselben Kontur, keiner davon manifold-garantiert.

Die ehrliche Ausgangslage: Wasserfälle oder abrupte Höhensprünge im Flussverlauf wurden vor diesem Umbau nicht erkannt und nicht dargestellt. Jeder Wasser-Vertex bekam seine Höhe aus dem Geländemodell, aber statt dem tatsächlichen Verlauf zu folgen, wurde pro Polygon Richtung eines einzigen Mittelwerts geglättet (Ausreißer per Interquartilsabstand gekappt). Flüsse bekamen dabei nur 60 % der Glättungsstärke von Seen — sie behielten also etwas Gefälle gegenüber der reinen Ebene, aber das war eine Nebenwirkung der Glättungsstärke, kein Modell des tatsächlichen Gefälles entlang der Fließrichtung. Ein realer Sprung (Wehr, Kaskade, Wasserfall) wurde von diesem Verfahren einfach mit in den Mittelwert gezogen und als sanfte Diagonal-Rampe über die ganze Flussbreite verschmiert — die Stufe verschwand, statt gedruckt zu werden. Die Terrassierung unten (Roadmap-Schritt 03) behebt genau das.

Hier lohnt sich dieselbe Rechnung wie bei der Gebäudehöhen-Quantisierung aus Akt 2: Die Druckerauflösung erzwingt einen Z-Rasterschritt von Schichthöhe × Maßstab. Jede reale Höhenänderung, die kleiner als dieser Schritt ist, kann der Drucker ohnehin nicht auflösen — sie ist in diesem Sinn vernachlässigbar. Alles darüber ist echte, verlorene taktile Information.

Alle fünf Schritte (D1–D5) sind umgesetzt und in main-fähigem Zustand: Fetcher, Optimizer und Builder wurden umgebaut, 70 neue/angepasste Unit-Tests grün, und beide gemeldeten Städte wurden im selben headless-Blender-Container aus Akt 2 zweimal generiert — einmal mit dem Stand vor diesem Akt, einmal danach, bei identischen Kamera-Koordinaten für den direkten Vergleich.

Akt 1 hat das settlement_footprint-Regime eingeführt: bei sehr gestreckten Strecken (Karwendelmarsch, 1:243.600) wird die Stadt nicht mehr einzeln, sondern als ruhiges, zweilagiges Plateau gerendert — Innsbruck als taktile Fläche statt als schwarzer Klumpen. Das Plateau entstand bis dahin aus der Vereinigung aller Gebäude-Footprints in der Kachel. Das druckt zuverlässig, ist aber die falsche Datenquelle: ein Gebäude-Footprint beantwortet „wo steht ein Haus", nicht „wo ist Siedlung" — und Overture liefert die eigentlich richtige Antwort längst mit, klassifiziert nach Nutzungsart, im land_use-Datensatz. Issue #287 macht genau diesen Punkt und bringt bereits eine eigene Live-Recherche gegen Innsbruck/Karwendelmarsch mit.

Anders als zunächst geplant blieb es nicht bei der reinen Vorbereitung: ein neuer land_use_fetcher.py (gleiche Bauweise wie Wasser/Brücken), die Anbindung ans settlement_footprint-Regime samt automatischem Fallback auf die alte Gebäude-Union, und ein togglebares SSOT-Setting (settlement_use_land_use, Blender-UI und Web-Wizard) wurden noch am selben Tag umgesetzt — und gegen den echten Karwendelmarsch-Track verifiziert, der als GPX-Fixture zum ersten Mal überhaupt im Repo existiert.

Derselbe reale Track, derselbe Maßstab (1:243.600), zweimal generiert — einmal mit der alten Gebäude-Footprint-Union, einmal mit der neuen land_use-Quelle. Der Zoom zentriert automatisch auf die Bounding Box des Building-Objekts — bei diesem Track ist das praktisch deckungsgleich mit Innsbruck am südlichen Streckenrand, dem einzigen nennenswerten Siedlungsgebiet der ganzen Strecke.

Akt 7 endete mit einer offenen Frage: derselbe entartete Shell (64 Faces, is_volume=False, Volumen −0,127) im exportierten Karwendelmarsch-Export, byte-identisch in zwei Läufen mit komplett unterschiedlicher Gebäude-/land_use-Eingabe — also musste die Ursache im gemeinsamen Terrain- oder Kompositions-Code liegen, nicht im Fetcher. Diese Sitzung hat den gemeinsamen Code isoliert nachgestellt (dieselbe to_manifold/compose_tile-Kette, aber ohne Blender, mit einem synthetischen Cutter) und den echten Verursacher gefunden: ein Wasser-Schnitt, der bei diesem Maßstab nie die Geländeoberfläche durchbricht.

Wasser wird bewusst zweimal verwendet — einmal von der Basis-Geometrie subtrahiert (schneidet eine Vertiefung ins Gelände), einmal als eigenständiges, eingefärbtes Objekt in genau diese Vertiefung gesetzt. Ohne den Schnitt läge das blaue Wasser-Objekt nur lose auf dem Gelände und würde beim Slicen mit der Landoberfläche kollidieren — der Schnitt selbst ist also die richtige Absicht. Die feste Druck-Extrusion (water_extrusion_up/down_mm, 0,2/0,4 mm) wird aber über den Maßstab in reale Meter zurückgerechnet: bei 1:243.600 werden daraus ~146 m reale Schnitttiefe. Auf dem steilen Alpenprofil des Karwendelmarsches bricht dieser Schnitt die geglättete Geländeoberfläche nie — die Subtraktion schneidet dadurch keine offene Rinne, sondern eine vollständig eingeschlossene, unsichtbare Blase.

Der Fix: compose_tile (core/geometry/csg.py) erkennt nach der Komposition jede vollständig eingeschlossene Shell mit negativem Volumen und füllt sie — eine gefangene, unerreichbare Kavität trägt ohnehin keine druckbare Information, das Auffüllen ist die geometrisch korrekte Auflösung, kein Datenverlust. Echte getrennte Volumen (disjunkte Gebäude-Shells, mehrteiliges Wasser) bleiben unangetastet; offene oder inkonsistent gewickelte Shells fallen weiterhin durch die Prüfung. Ein Regressionstest (test_buried_water_cutter_fills_enclosed_void) hält den Fall fest.

Nebenfund, gleich mitbehoben: terrain_builder.pys Seitenwände waren als Dreiecks-Fächer von einer einzigen Bodenecke konstruiert — eine Konstruktion, die nur auf einem „sternförmigen" Höhenprofil überschneidungsfrei bleibt. Auf einem echten, nicht-monotonen Alpenprofil (Grat–Tal–Grat) überlappt sich der Fächer selbst. In der Praxis unsichtbar (das rohe Terrain-Objekt wird nach der CSG-Vereinigung versteckt, und die Überschneidung blieb zufällig exakt planar, erzeugte also nie einen 3D-Hohlraum) — aber grundsätzlich falsch. Ersetzt durch einen Quad-Strip mit einem Bodenpunkt direkt unter jedem Kanten-Vertex, exakt nach demselben Muster wie die Top-Fläche ihre eigenen Zellen baut — dadurch beweisbar überschneidungsfrei, unabhängig vom Höhenprofil.

Auslöser war ein Nutzer-Screenshot vom München-Marathon-Tile: rund um den Marienplatz stand ein auffällig hoher, uniformer Block, deutlich über der Umgebungshöhe — in der echten Innenstadt gibt es dort so etwas nicht. Die erste Vermutung (explizite num_floors-Werte in den Overture-Daten) ließ sich schnell widerlegen: vier Gebäude nahe der vermuteten Stelle hatten tatsächlich eine explizite height von 40–41 m — aber ohne num_floors, also lief die vermutete num_floors × 3.5-Fallback-Kette gar nicht.

Der eigentliche Mechanismus lag eine Stufe tiefer, in _printability_pass() (core/fetchers/building_fetcher.py, ADR-0036): Im city_detail-Regime werden alle Gebäude-Footprints global auf Lücken < min_gap_lines × Düsenbreite geprüft und verschmolzen — in der dicht bebauten Altstadt (Gassenbreite oft < 18 m bei diesem Maßstab) verschmilzt praktisch der gesamte Block zu einem einzigen Teil. Für diesen Teil gilt dann height = max(heights) — eine hohe Höhe reicht, um alle Nachbarn mitzuziehen.

Vier Ansätze lokal gegeneinander getestet (echte Marienplatz-Geometrie, echte Druckbarkeits-Parameter bei 1:59.100): globales max() pro verschmolzenem Teil (Baseline), Höhen-Ratio-Clustering, diskrete Höhen-Bänder, und schließlich — nach dem Hinweis, dass kleine Kioske/Nebengebäude gar nicht individuell erhalten werden müssen — die Idee, nur benannte Gebäude aus dem Merge-Pool auszuschließen und individuell zu verarbeiten, während der Rest unverändert durch die bestehende Logik läuft.

Der Fix: Gebäude mit einem Overture-Namen werden jetzt aus dem DBSCAN-Clustering und aus dem globalen Gap-Closing-Pool des city_detail-Regimes ausgeschlossen und einzeln verarbeitet — eigene Höhe bleibt erhalten, ein zu schmaler Footprint (wie das Torbogen-Gebäude) wird per Closing-Operator auf Mindestwandbreite aufgeblasen statt verworfen. Der reguläre Gebäudebestand (92 % aller Gebäude in dieser Kachel sind unbenannt) durchläuft exakt dieselbe, unveränderte Logik wie zuvor — kein Verhaltensunterschied, keine zusätzlichen Kosten für den Großteil des Bestands.

Nebenfund beim echten Blender-Lauf: der Fix legte einen zweiten, unabhängigen Bug in der CSG-Komposition offen. Ein einzeln verarbeitetes, aufgeblähtes Namens-Gebäude direkt neben einem regulär verschmolzenen Nachbarn erzeugte beim Boolean-Union eine hauchdünne, deckungsgleiche Artefakt-Shell (4 Faces, Volumen exakt 0 m³) — wasserdicht, aber kein echter Körper, und damit vom Export-Gate zurückgewiesen. _fill_enclosed_voids() (core/geometry/csg.py, bereits seit Akt 8 für eingeschlossene Hohlräume zuständig) erkennt jetzt zusätzlich exakt diese Nullvolumen-Flachschale und verwirft sie — dieselbe „trägt keine druckbare Information"-Logik, nur für einen zweiten Degenerations-Fall.

Auslöser war wieder ein reales Rendering, diesmal vom Nutzer selbst geschickt: an einer Straßenkreuzung verschwand die eigene Streckenführung — das emotionale Zentrum jeder Kachel — sichtbar unter einem zusammenhängenden Gebäudeblock. Der Mechanismus dahinter ist derselbe globale Gap-Closing-Schritt aus ADR-0036/Akt 9: Lücken unter min_gap_lines × Düsenbreite werden geschlossen, weil ein Slicer sie ohnehin verschmelzen würde. Für eine schmale Gasse ohne Strecke ist das genau richtig. Läuft aber die eigene GPX-Strecke exakt durch diese Gasse, wird sie vom selben Schritt einfach mitverschluckt — nichts in der Pipeline kannte bis dahin den Unterschied zwischen „irgendeine Gasse" und „die Gasse, die die Marathonstrecke selbst ist".

Der erste Entwurf hätte den Schnitt direkt in BuildingFetcher.process_raw_buildings() eingebaut und den Optimierungs-Cache-Schlüssel um Track-Punkte erweitert — dieselbe Stelle, an der Akt 7 bereits settlement_use_land_use ergänzt hatte. Der Nutzer stoppte das während der Umsetzung selbst mit einer einfachen Frage: „wieso muss ich denn anders fetchen, wenn ich nur track carven möchte?" — zu Recht: der Fetch/Cluster-Schritt bleibt unverändert, der Schnitt ist eine reine, günstige 2D-Nachbearbeitung der bereits fertigen Footprints. Der Cache wird für teure Overture-Abfragen gebraucht, nicht für eine Shapely-difference, die pro Lauf Millisekunden kostet — sie dort hineinzuziehen hätte nur zusätzliche Cache-Key-Fläche geschaffen, ohne jeden Nutzen.

Die reale München-Marathon-Kachel (1:59.100, city_detail-Regime) zeigt: das ist kein Einzelfall. Über die gesamte Strecke hinweg schneidet der Korridor 145 Gebäude-/Blockteile zurück und verwirft 150 weitere vollständig — das sind 150 Stellen, an denen vor dieser Korrektur ein Gebäudeblock die Strecke komplett unter sich begraben hätte, nicht nur angeschnitten. Mehrere davon liegen im selben Altstadt-Ausschnitt, den schon Akt 9 am Marienplatz untersucht hat — derselbe dichte Gassenraster, nur diesmal mit der eigenen Streckenführung mittendurch.

Zwei berechtigte Einwände kamen direkt nach dem ersten Entwurf zurück, beide noch am selben Tag umgesetzt:

1. „Das Feature ist sehr einschneidend — kann ich es bei Bedarf deaktivieren und die Korridorbreite im Verhältnis zur Track-Breite konfigurieren?" Ein fester Sicherheitsabstand in Metern (der ursprüngliche Entwurf) skaliert nicht mit dem Kachel-Maßstab — 1 m ist bei 1:20.000 kaum sichtbar, bei 1:243.600 unverhältnismäßig knapp. Jetzt gibt es zwei echte, in Blender-UI und Web-Wizard sichtbare Einstellungen (SSOT, ADR-0017): track_corridor_enabled (Default an — schaltet exakt auf das alte Verhalten zurück) und track_corridor_width_factor (Default 1,5×, ein Verhältnis zur Track-Eigenbreite statt eines fixen Meterwerts, damit es über alle Maßstäbe konsistent bleibt).
2. „Gibt es ein Gate gegen 0/Mini-Artefakte nach dem Carven? Das sah im Screenshot verdächtig aus." Der reine Flächen-Filter (min_part_area_m2) lässt einen langen, dünnen Span durch, solange seine Fläche über der Schwelle liegt — 0,3 m × 20 m sind 6 m², klar über 4 m², aber als Wand unbedruckbar. Jeder verbliebene Teil läuft jetzt zusätzlich durch dieselbe morphologische Öffnungs-Schranke (Erodieren + Dilatieren), die die Gebäude-Druckbarkeitsprüfung ohnehin schon global anwendet (ADR-0036) — mit demselben building_min_wall_lines-Wert. Ein Regressionstest (TestWallGate) baut genau so einen zu dünnen Rest nach und bestätigt: er wird jetzt verworfen, ein solider Rest bleibt unangetastet.

Beide Nachschärfungen zusammen erklären, warum die Zahlen oben (145/150/79) deutlich einschneidender ausfallen als im allerersten Durchlauf (193/33) — der Korridor ist mit Faktor 1,5 breiter als der ursprüngliche feste 1 m-Sicherheitsabstand, und die Mindestwandbreiten-Schranke räumt zusätzlich 79 Reste weg, die vorher als knapp-druckbare Splitter durchgerutscht wären.

Anstoß war eine ganz praktische Frage: Wie druckt man Düsseldorfs Hochhäuser — Rheinturm, ARAG-Hochhaus, Mannesmann-Hochhaus — ohne dass sie als dünne, verzugsanfällige Stifte scheitern? Eine echte Overture-Analyse der Düsseldorf-Marathon-Kachel (43.283 Gebäude, 1:44.200 — der tatsächliche Auto-Maßstab dieser Strecke) fand die exakte Ursache, keine Vermutung: gedrucktes Aspektverhältnis = reales Aspektverhältnis × z_scale. Die Höhenüberhöhung (nötig, damit Geländerelief überhaupt sichtbar wird) multipliziert die Schlankheit jedes Gebäudes 1:1 mit sich selbst — bei einem echten, mäßig schlanken Turm (Rheinturm, reales Aspektverhältnis 4,7) macht z_scale = 2,5 daraus beim Druck ein Aspektverhältnis von 11,9 — ein 4,7 mm hoher, 0,86 mm breiter Stift.

Der Fix — zwei unabhängige Maßnahmen, beide nur oberhalb einer Knick-Höhe aktiv: Erstens wird die Höhe oberhalb von landmark_height_knee_m (Default 30 m) logarithmisch statt linear skaliert — C1-stetig am Knick, damit kein sichtbarer Sprung zwischen „normalem Gebäude" und „Landmark" entsteht; unterhalb von 30 m ist die Formel exakt identisch zur bisherigen linearen Skalierung. Zweitens weitet sich das untere landmark_taper_fraction (Default 30 %) der (bereits gedämpften) Höhe zu einem verbreiterten Sockel auf — eine Smoothstep-Kurve (nullsteigend an beiden Enden, damit weder am Boden noch am Übergang zur wahren Silhouette eine Kante entsteht), dimensioniert, damit das Aspektverhältnis am Sockel nie landmark_max_base_aspect (Default 4,0) überschreitet. Downward-widening heißt außerdem: jede Schicht ist gleich breit oder breiter als die darüber — von Natur aus überhangfrei, keine Stützen nötig.

Ein zweiter, unabhängiger Bug beim echten Blender-Lauf gefunden: der Sockel wird intern aus 8 gestapelten Kegelstumpf-Segmenten plus einem geraden Aufsatz zusammengesetzt (Boolean-Union, manifold3d). Bei realen — auch konvexen! — Düsseldorf-Footprints kam dabei nicht ein zusammenhängender Turm heraus, sondern mehrere disjunkte, einzeln wasserdichte Teilschalen, unsichtbar für jede reine „ist es wasserdicht"-Prüfung, nur durch Zählen der zusammenhängenden Komponenten auffindbar. Direkt am realen Colorium-Footprint reproduziert und eingegrenzt auf zwei unabhängige Ursachen: Segmente, die sich nur exakt berühren statt echt zu überlappen, verschmilzt manifold3ds exakte Boolesche Union nicht zuverlässig — und dieselbe Union verliert bei den realen Kachel-Weltkoordinaten (mehrere tausend Meter vom Ursprung entfernt) selbst mit Überlapp noch genug Präzision, um Segmente getrennt zu lassen. Behoben, indem der komplette Sockel in lokalen, zentroid-relativen Koordinaten aufgebaut und erst das fertig verschmolzene Ergebnis an seine Weltposition verschoben wird.

Anstoß war die Nutzerfrage zu einem selbst hochgeladenen 60 km-Ultramarathon-Track (11,9 × 8,7 km Bbox) — bei diesem Zuschnitt landet der Auto-Maßstab bei 1:96.300, deutlich im block_level-Regime (ADR-0036). Der Verdacht: „gefühlt sind die Gebäude so klein, dass sie beim Slicen rausfliegen." Eine echte Regenerierung der Kachel (98.076 rohe Overture/OSM-Footprints → 1.418 druckbare Teile) bestätigte das mit Zahlen statt Gefühl: 68,8 % der 573 Landmark-Gebäude druckten unter einem einzigen 0,2 mm-Layer, 97,9 % unter zwei.

Genau genommen sind die übrigen 845 Teile keine Einzelgebäude, sondern Cluster aus im Schnitt drei, maximal 60 verschmolzenen Rohgebäuden (cluster_size) — das block_level-Regime flacht sie ohnehin auf eine gemeinsame Höhe ab (Akt 9). Nur die 573 „Landmarks" sind wirklich einzelne, unveränderte Gebäude: jedes mit einem Overture-name-Tag, plus die preserve_landmarks_per_tile-höchsten pro Kachel — Akt 9s Sicherheitsnetz gegen Höhen-Ausreißer, hier zum ersten Mal an einer Kachel mit diesem Regime und dieser Größe durchgerechnet.

Der Fix: _printability_pass() berechnet dieselbe Floor jetzt auch für den Standalone-Pfad — aber ausdrücklich nur im block_level-Regime. Im city_detail-Regime bleibt die echte Höhendifferenzierung pro Landmark unangetastet, exakt die Eigenschaft, die Akt 9 am Marienplatz-Fall erst erkämpft hat (Talbrucktor 40 m, zwei Kirchtürme, echte Höhenvarianz) — dort würde dieselbe Floor die gerade gewonnene Differenzierung wieder verwaschen. settlement_footprint erreicht diesen Codepfad ohnehin nie (eigener Dispatch-Zweig, siehe Akt 7).

Auslöser war wieder ein echter Nutzer-Track, kein Testfall: die Düsseldorf-Marathon-Kachel zeigte das Medienhafen-Becken im Wasser-Layer sauber auf einer Höhe, aber sobald die Base-Schicht dazugeschaltet wurde, verschwand genau dieses Becken komplett unter dem Terrain — der Rheinbogen selbst blieb offen. Ein direktes Vermessen an der hochgeladenen 3MF (Ray-Cast: Base-Oberflächenhöhe gegen die eigene Z-Spanne jedes Wasser-Features, an jedem Punkt des Hafenbecken-Footprints) bestätigte es ohne Vermutung: 82 % des Rheinbogens waren korrekt bis auf Wassertiefe geschnitten — aber praktisch das gesamte Hafenbecken lag 20 bis 35 m real zu hoch unter unsichtbarem Terrain.

Der Fix: ein gemergtes Feature erbt jetzt den Typ des flächenmäßig dominant überlappenden Eingabe-Features statt eines pauschalen Stempels — stellt den Terrassierungs-Pfad für jedes gemergte Gewässer wieder her. Zusätzlich erkennt eine neue _spatial_lobe_split-Prüfung einen echten Höhensprung in den Randproben, bevor der Fluss-/Seen-Pfad überhaupt greift, und teilt ein verschmolzenes Mehrkörper-Polygon in unabhängige Lappen — als Absicherung für Fälle, die nicht entlang einer einzigen Fließachse liegen (z. B. ein seitlich abzweigendes Becken).

Zusätzlich zum Lappen-Split kam als Backup ein Mechanismus dazu, der den Wasser-Schnitt zusätzlich bis über die tatsächliche lokale Terrain-Höhe anhebt — falls die Level-Zuweisung trotzdem irgendwo zu niedrig ausfällt. Kaum gemergt (derselbe Sitzungsablauf, direkt im Anschluss), meldete derselbe Nutzer: das Wasser schwebt jetzt 1,2 bis 1,8 mm über dem umgebenden Terrain — im Slicer nachgemessen (Distance 1.771 mm).

Die naheliegende erste Erklärung war eine Abtast-Ungenauigkeit: die neue Absicherung hat die Bounding Box jedes Wasser-Polygons abgetastet statt dessen tatsächlichen Footprint, und bei länglichen Flusspolygonen reicht die Bbox kilometerweit in viel höheres Uferland hinein (gemessen am Rheinbogen-Feature: zugewiesenes Niveau 20,6 m, lokales Maximum in der Bbox 47,7 m — der Cutter damit 27,1 m real zu hoch). Das ist zwar real und messbar, aber nicht die eigentliche Lehre — und, wichtiger noch: das großzügige Bemessen des Cutters war für sich genommen nie das Problem. Ein Cutter darf beliebig aggressiv sein, notfalls bis +∞ auf der Z-Achse: Base − Cutter entfernt dann im Wasser-Footprint einfach jedes Material oberhalb des Wasserbodens, egal wie hoch — in derselben PR fusionieren Brücken-Causeways jetzt ohnehin erst nach der Wasser-Subtraktion in die Base statt davor, ein noch so großzügiger Cutter kann sie also gar nicht mehr erreichen, und dass Wasser Gebäude in seinem Footprint mitschneidet, ist seit Akt 6/#286 sogar ausdrücklich gewollt. Die eigentliche Ursache liegt eine Ebene tiefer: Schneiden (Base großzügig freischneiden, damit die CSG-Subtraktion garantiert eine offene Rinne statt einer eingeschlossenen Blase erzeugt, Akt 8) und Extrudieren (die sichtbare, exportierte Wasserfläche exakt bauen) sind zwei konzeptionell getrennte Operationen mit entgegengesetzten Zielen — die eine darf/soll großzügig sein, die andere muss exakt sein — und der Code hat sie nie als getrennte Operationen behandelt. WaterBuilder.create_water_surface baut pro Feature genau ein Objekt und benutzt es unverändert für beide Rollen: einmal als Cutter für compose_tile, danach (nur auf das Hexagon geclippt) als das exportierte „Water"-Objekt selbst. Selbst eine korrekt am tatsächlichen Footprint statt an der Bbox gemessene Absicherung hätte den Fehler nicht verhindert — jede zusätzliche Höhe, die der Cutter zum sicheren Durchschlagen bekommt, wäre unweigerlich auch zur sichtbaren Wasserfläche geworden, weil beide Rollen am selben Objekt hingen. Die Bbox-Ungenauigkeit war ein echter, aber sekundärer Fehler; der Sizing-Mechanismus selbst war als Cutter-Strategie durchaus vertretbar, nur eben nie dafür gedacht, auch die Extrusion zu bestimmen.

Die Entscheidung: die Absicherung komplett zurückgenommen, statt Cutter und Extrusion sauber zu trennen (ein separates, nie exportiertes Cutter-Manifold ausschließlich für compose_tile, während create_water_surface weiterhin nur die festen Druck-mm-Margins verwendet) — beide Wege führen zum selben Ergebnis. Der Lappen-Split von oben behebt den eigentlich gemeldeten Fehler auf echten Daten bereits nachweislich korrekt, ganz ohne diesen zusätzlichen Mechanismus; eine sauber getrennte Cutter-Logik wäre ein spekulatives Sicherheitsnetz ohne belegten Bedarf gewesen — nicht wert, dauerhaft eine zweite Objekt-Rolle zu pflegen.

Bei der Rücknahme blieb eine tiefere Frage offen, die der Nutzer selbst aufwarf: liegt water_level_z überhaupt dort, wo wir das Terrain sehen? water_level_z ist ein einziger flacher Wert pro Feature — ein niedriges (15.) Perzentil über alle Rand-Vertices, auf das Druck-Layer-Raster gerundet. Genau das round() war der zweite, unabhängige Fehler: an echten Daten gemessen sackte ein Teich, dessen kompletter Rand bei 37,5–39,9 m real lag (roher 15.-Perzentil-Wert ~37,6 m), durch die Rundung auf ein 10,3 m-Raster auf 41,2 m — höher als jeder einzelne Randpunkt dieses Features. Das widerspricht dem im Code selbst dokumentierten Ziel „water never stands above its banks" nicht nur im Detail, sondern systematisch: round() rundet per Konstruktion in ~50 % der Fälle nach oben.

Der dritte Fund wurde gemergt. Der Nutzer generierte eine neue Kachel und meldete: das Terrain bedeckt den Rhein jetzt fast vollständig — fast das Gegenteil des ursprünglich gemeldeten Problems. Drei berechtigte Fragen kamen zurück: Wofür die Bedenken zu Cutten vs. Extrudieren äußern, wenn am Ende doch wieder dasselbe Objekt für beides benutzt wird? Wieso eine Heightmap-Analyse als Beleg verwenden, die genau diese Klasse von Fehler prinzipiell nicht aufdecken kann? Und was ist jetzt eigentlich der Root Cause?

Alle drei trafen zu. water_extrusion_up_mm=0 plus floor() hatten der sichtbaren Wasserfläche jeden Puffer nach oben genommen — und weil water_level_z bewusst ein niedriges 15.-Perzentil ist, liegt sie damit fast überall unter dem real schwankenden Terrain, nicht mehr darüber. Überkorrektur, keine Korrektur. Und die Validierung aus dem dritten Fund hatte water_level_z nur gegen Heightmap-Randstichproben geprüft — nie gegen die tatsächlich komponierte Base-Mesh nach Terrain-Optimierung/-Dezimierung und CSG-Union. Genau die Methode, die den allerersten Fund dieses Akts überhaupt aufgedeckt hat (Ray-Cast auf die echte 3MF), wurde für die eigene Fix-Verifikation nicht wiederholt.

Der Fix: WaterBuilder.build_water_cutters() baut jetzt pro Feature ein separates, nie exportiertes Cutter-Manifold, dessen Deckfläche bis über das reale lokale Terrain-Maximum im tatsächlichen Footprint angehoben wird (nicht mehr die Bounding Box — der ursprüngliche Fehler aus Fund 2, dieses Mal per shapely.contains_xy vermieden). create_water_surface() — das exportierte, sichtbare Objekt — bleibt dagegen komplett unverändert und bekommt gar keine Terrain-Logik: sobald der Cutter seinen Job gemacht hat, gibt es dort nichts mehr, das die unveränderte, korrekt niedrige Fläche bedecken könnte.

Auslöser war ein direkter Vorher/Nachher-Vergleich vom Nutzer selbst: ein älteres, vor dem großen Rework gedrucktes Tile gegen ein aktuelles. Die Beobachtung war präzise — die Gebäudeumrisse auf dem neuen Druck lasen sich schlechter, und kleine Innenhöfe tauchten als offene Löcher auf, die wie Druckfehler statt wie Absicht wirkten. Die Nachfrage, die die eigentliche Arbeit auslöste, kam gleich hinterher: „Du solltest alle Akte der Success Story gelesen haben, WARUM wir die einzelnen Änderungen gemacht haben — die Frage ist, ob wir das weiter optimieren können, ohne die Vorteile zu verlieren." Jede vorherige Entscheidung — Akt 1s echte Vereinigung statt Hülle, Akt 4s beweisbare Wasserdichtigkeit, Akt 9s Schutz vor Höhen-Leck durch benannte Gebäude, Akt 10s Freihaltung des Track-Korridors — musste unangetastet bleiben.

Die Ursache lag in BuildingFetcher._printability_pass_merge (Akt 2/ADR-0036): eine einzige morphologische Öffnung — union.buffer(-wall/2).buffer(+wall/2) — musste gleichzeitig vier verschiedene Fragen beantworten: Ist diese Wand druckbar? Ist dieser Innenhof groß genug, um als Loch zu bleiben? Ist dieses Detail über der Slicer-Auflösung? Und — separat davon — eine einzelne max()-Höhe pro zusammengeführtem Teil verschluckte jede Dachhöhen-Variation innerhalb eines Blocks. Eine Öffnung erodiert die gesamte Fläche mit demselben Radius und dilatiert danach nur die erodierte, nicht die ursprüngliche Form zurück — jede echte Ecke, jede Innenhof-Wand, die die Erosion berührt, aber nicht tatsächlich durchtrennt hat, kommt gerundet und geschrumpft zurück, obwohl sie nie unprintbar war.

Der Nutzer stellte die richtige Frage, bevor Code geschrieben wurde: „Ich habe die Sorge, dass wenn wir zu kleinteilig werden, wir wieder Details im Slicer verlieren?" Statt das anzunehmen, wurde real gesliced und im erzeugten G-Code nachgemessen, welche Balkenbreiten (0,10 bis 1,00 mm getestet) ein 0,2 mm-Düsenprofil tatsächlich noch als eigene Extrusion reproduziert — nicht nur theoretisch, sondern als reale, extrudierende Werkzeugbahn im G-Code. Ergebnis, direkt in building_min_feature_lines' eigener Schema-Beschreibung dokumentiert: ein 0,2 mm-Düsenprofil reproduziert noch eine freistehende 0,10 mm-Struktur (~0,5 Düsenbreiten) — der Default (0,25 Düsenbreiten) liegt bewusst unterhalb dieser gemessenen Grenze, damit er ein reiner Rauschfilter bleibt statt aktiv Form zu verändern.

Der reale München-Datensatz crashte beim ersten vollständigen Lauf mit einer Selbstüberschneidung an einem einzelnen Feature (printable_1174_3). Drei unabhängige, jeweils für sich korrekte Reparaturversuche änderten nichts: (1) Prüfung des Live-Objekts, (2) eine round-trip-bewusste Prüfung (Shapely kann is_valid=True am Live-Objekt melden, während ein aus genau denselben, extrahierten Koordinaten neu gebautes Polygon False meldet — real reproduzierbar, kein hypothetischer Fall), (3) ein Leck im covered-Akkumulator von relief_partition. Derselbe Crash, dieselbe Koordinate, jedes Mal.

Erst ein Vorher/Nachher-Dump desselben Feature an zwei Stellen der Pipeline in einem einzigen Lauf fand die eigentliche Ursache — nicht in diesem Akts eigenem neuen Code: dedupe_ring, eine bereits bestehende, unabhängige Funktion in core/geometry/solids.py (Epsilon 1e-9), entfernte einen Punkt aus einem 11-Punkte-Ring, der davor nachweislich gültig UND einfach war (is_valid=True, is_simple=True) — und machte ihn dadurch selbst zu einem sich selbst schneidenden Ring. Der entfernte Punkt lag nur 8,87e-10 von seinem Nachbarn entfernt, unter dem Epsilon der Funktion. Erreichbar wurde das erst durch diesen Akt: relief_partition erzeugt spürbar feinteiligere, dichter aneinanderliegende Geometrie als die alte flache max()-Ausgabe je hatte — der Fehler ist alt, seine Sichtbarkeit ist neu.

Nach dem dedupe_ring-Fix lief die komplette München-Kachel durch die Geometrie-Erzeugung und die eigene In-Szene-Prüfung fehlerfrei — scheiterte aber beim 3MF-Export an sechs neuen, hauchdünnen entarteten Schalen (Volumen zwischen 1e-9 und 1e-12 m³), obwohl compose_tiles eigene Aufräum-Stufe (_fill_enclosed_voids, ursprünglich für #297s vergrabenen Wasser-Schnitt gebaut) an genau diesem Mesh nichts zu bereinigen fand. Ursache: Blender speichert Vertex-Koordinaten intern als float32. Ein Mesh, das im Moment der CSG-Komposition nachweislich sauber ist, kann nach dem Schreiben in ein Blender-Objekt und dem erneuten Auslesen beim Export neue, hauchdünne entartete Schalen entwickeln — weil relief_partition erheblich mehr aneinandergrenzende, fast deckungsgleiche Flächen erzeugt (benachbarte Dachrelief-Stufen) als die alte flache Geometrie je hatte, und der float64→float32→float64-Roundtrip genau präzise genug ist, um gelegentlich das Vorzeichen einer dieser Grenzflächen zu kippen.