Bordstein 184,33 km statt 120,28 km (+53 %) in 1.341 Stücken je Chunk statt
1.415 — mehr Länge in weniger Stücken, weil der Rand jetzt durchläuft,
statt an jeder Gasse unterbrochen zu werden.
Abdeckung des Fahrbahnrands, an den fertigen Chunks nachgemessen: Gasse
7,0 % → 83,1 %, Wohnstraße 87,9 % → 88,0 %, Hauptstraße 87,2 % → 87,3 %,
Boulevard 86,3 % → 86,3 %. Fahrbahn (0,9076 km²), Gehweg (0,2987 km²),
Restflächen (0,0967 km²) und Markierungen (23.272 Stücke) bleiben, wie sie
waren.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auf Wunsch des Nutzers: brushed_concrete_04 statt der Textur aus
modular_sidewalk_curb_kit. Die Wand ist 18 cm hoch, da trägt eine Textur mit
waagerechter Struktur mehr als das Modulmuster des Kits.
Damit ist das Kit nirgends mehr im Spiel: Die Geometrie des Bordsteins war von
Anfang an selbst gebaut, der Gehweg nimmt seit der Platzhalter-Korrektur
concrete_pavement, und der Bordstein jetzt brushed_concrete_04 - beides
Poly Haven (CC0). Der Kit-Import in tools/assets/textures.mjs entfällt samt
sharp-Abhängigkeit, die drei kopierten Kit-Texturen sind entfernt, und die
Namensnennung im Manifest nennt Just8 nicht mehr, weil nichts davon mehr
benutzt wird. Der Kit-Ordner des Nutzers bleibt unangetastet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bringt den Stand von main (Animationen, Showroom) in den Straßenzweig,
damit die zusammengeführte Fassung geprüft werden kann, bevor main auf
diesen Stand vorgezogen wird. main ist in einem zweiten Arbeitsverzeichnis
ausgecheckt und kann hier nicht ausgecheckt werden.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
cd tools/extract && PYTHONUTF8=1 uv run python run.py, nur wegen der
geaenderten Namensnennung im Manifest (Bordstein statt Bordstein und
Gehweg). Wie erwartet aendern sich nur manifest.json (die Attribution-
Zeile) und map.json (ihr abhaengiger manifest_sha256) - alle 144
Chunk-Dateien und die beiden Bilder bleiben byte-gleich, das Straßennetz
unveraendert (1.537 Knoten, 1.790 Kanten; 830 Bordsteinstuecke, 169
Restflaechen, 22.393 Markierungen, 56 Palmen entfernt - identisch zum
Fixwelle-Stand).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Die Fixwelle hat loadSet() so geaendert, dass eine Textur auch ohne
Normal- und ARM-Karte laedt (Befund 2) - richtig fuer sich, aber dadurch
laedt public/textures/sidewalk_Diffuse.jpg jetzt tatsaechlich. Die Datei
ist keine Betontextur, sondern das Platzhalterbild aus
modular_sidewalk_curb_kit: dunkler Grund, roter Schriftzug "Tru-planar
Sidewalk texture", im Browser geprueft. Vorher fiel das nie auf, weil
loadSet() an der fehlenden Normal-/ARM-Karte scheiterte und auf den
einfarbigen Ersatz zurueckfiel.
TEXTURES.sidewalk zeigt jetzt auf concrete_pavement (Poly Haven, CC0),
denselben Belag wie die Parkwege (curb_Diffuse.jpg ist dagegen eine
echte Betontextur mit Fugen und bleibt beim Kit). uvScale wechselt
von 4 auf 1,8, wie paths schon vormacht - Poly Haven misst die Kachel
mit 1,8 x 1,8 m. Der Kopierschritt fuer sidewalk_baseColor.jpeg entfaellt
in tools/assets/textures.mjs, die Namensnennung in run.py und im Entwurf
nennt fuer den Kit nur noch den Bordstein, und die committete
Platzhalter-Kachel ist aus dem Repository entfernt (der Kit-Ordner des
Nutzers bleibt unangetastet). tests/materials.test.js prueft jetzt die
neue Quelle, nicht mehr den Kit-Slug.
Sichtgeprueft im Browser: Gehwege zeigen helle Betonplatten statt
rotem Schriftzug, keine "Textur ... fehlt"-Warnung in der Konsole.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ein Lauf (cd tools/extract && PYTHONUTF8=1 uv run python run.py) nach allen
datenwirksamen Fixwelle-Korrekturen (Befunde 3-8): Markierungsrichtung an
geknickten und an sich selbst zurücklaufenden Zufahrten, robuste
Markierungsgeometrie bei engem Zickzack, gültige Ringe durch
set_precision(), carriageway ohne das irreführende klasse-Feld,
geschlossene Gehweglücke an gewöhnlichen Kreuzungsecken, mittig verteilte
Zebrabalken und gerundete Kantenbreite.
Straßennetz und Kantenzahl unverändert (1.537 Knoten, 1.790 Kanten - keiner
der Fixes rührt am Graphen). Bordstein (830 Stücke, 120,28 km) und Fahrbahn
(0,9076 km²) ebenfalls unverändert. Gehweg wächst leicht (0,2987 statt
0,2982 km², Befund 7 schließt die Eckenlücke), Restflächen entsprechend
kleiner (169 statt 171 Stücke). Markierungsstückzahlen je Chunk verschieben
sich geringfügig durch die neue Position (Befunde 3 und 8), die
Gesamtsumme vor dem Chunk-Zuschnitt bleibt bis auf eine entfernte
Nullflächen-Randlinie gleich (22.393 statt 22.394 - Befund 4 fängt genau
diesen einen Fall ab).
Einzelheiten und alle Messwerte im Fixwelle-Bericht.
modular_sidewalk_curb_kit (Just8, CC BY 4.0) liefert 2048er Karten für
Bordstein und Gehweg. Sie werden auf 1024 verkleinert und im Namensschema
der Poly-Haven-Texturen abgelegt, damit createMaterials() sie ohne
Sonderfall lädt. Das Kit selbst bleibt außerhalb des Repos; das Skript
überspringt den Schritt, wenn der Ordner fehlt.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
140 der 144 Chunkdateien ändern sich einmalig durch die Normalisierung in
emit.py, ohne dass sich außerhalb der acht Parkchunks in irgendeiner Ebene die
Fläche bewegt: symmetrische Differenz 0,00 m² für land, surfaces, roads,
buildings und paths über alle 136 übrigen Chunks.
In den Parkchunks ändert sich allein die Wegschicht, und zwar genau um die
runden Kappen: außerhalb des Parkvierecks liegen jetzt 0,02 statt 95,96 m² Weg
(der Rest ist die Rundung auf zwei Stellen). Wegfläche gesamt 7.999,35 ->
7.903,38 m². Palmen (2.257), Mittellinien und Gebäude bleiben unverändert;
map.png folgt der kleineren Wegfläche.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Die Pipeline erzeugt auf diesem Rechner nicht dieselben Daten wie auf dem Mac,
auf dem der bisherige Stand entstand: Pillow dekodiert die JPEG-Kacheln
minimal anders, bei unveränderten Paketversionen aus uv.lock. Betroffen sind
22 von 144 Chunks und die drei Kartendateien.
In neun Chunks ändert sich dabei auch die Zahl der Objekte je Ebene, weil
Flächen an Berührungspunkten anders verschmelzen oder sich teilen. Der
relative Flächenanteil je Ebene ist dabei kein verlässliches Maß und läuft bis
31.69 % hoch, weil einzelne Ebenen je Chunk nur wenige hundert m² groß sind.
Absolut liegt der größte Einzelverlust bei 1651 m² (chunk_1_3, Straße), davon
1541 m² räumlich deckungsgleich als Stadtfläche wiedergefunden; ähnlich
sauber chunk_3_0 mit 1286 m² verlorenem Gebäude gegen 1266 m² neue
Stadtfläche am selben Ort. Ausnahme: in chunk_1_1 verschwinden 66 m²
Gebäudefläche ersatzlos, ohne Entsprechung in Straße oder Stadtfläche
desselben Chunks.
Die Landplatte (`land`) bleibt in 20 von 22 Chunks unverändert. In chunk_4_11
Randrauschen (±11 m²), in chunk_3_11 schließt sich eine rund 150 m² kleine
Aussparung (netto +140 m² Land) – in keinem Chunk verliert die Landplatte per
Saldo Fläche.
Die Parkchunks (J6 bis K9) sind bis auf chunk_10_6 nicht betroffen; dort
ändern sich nur Koordinaten, weder Objektzahl je Ebene noch die Landplatte.
Ab hier ist Windows der Referenzrechner, damit spätere Läufe nur noch die
gewollten Änderungen zeigen.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
tribuene.glb mit places.mjs aufbereitet (6,3 MB -> 1,7 MB, 69 557 Dreiecke, 14 Primitive, 49 MB Grafikspeicher). PLACES-Eintrag bei (1409,9 | 1051,1), 45° gedreht, lift 0, replaces auf den 18,6 m hohen Kasten. Der Lage-Test übergeht ersetzte Grundrisse und prüft, dass jeder replaces-Punkt genau ein Gebäude unter dem Ort trifft.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- Himmel: 4k-HDRI von Poly Haven (CC0, tools/assets/hdri.mjs) statt Sky-Shader. Kuppel zeigt das Foto
ab 12°, darunter weiches Band und Dunst in Nebelfarbe; Umgebungslicht und Spiegelungen per PMREM;
Sonne aus dem Bild gekappt und als Licht übernommen (77°, Stärke 2,5)
- Schatten: CSM mit vier Stufen (25/100/350/1000 m, je 2048²), Schutznetz für beleuchtete Materialien,
Normal-Bias 1,5 Texel je Stufe gegen Streifen auf doppelseitigen Materialien (Figur, Autos)
- Startfigur wirft Schatten, Palmen und Laternen empfangen Schatten, Wasser als ruhige See
- Debug-Panel: Sonne, Himmelslicht, Himmelshelligkeit; Namensnennung um das HDRI ergänzt
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
727 von 2.286 rohen Grundrissen (31,8 %, aber nur 1,8 % der bebauten Fläche) sind
unter 4 m an der kurzen Seite ihres gedrehten Hüllrechtecks — extrudiert werden
daraus Wände, keine Häuser. Eine Mindestbreite allein reicht nicht: einzelne Formen
bleiben bei >= 4 m Breite trotzdem extrem lang und dünn (z.B. 4,27 m x 153 m,
Verhältnis 35,9). MAX_ASPECT_RATIO=12 ergänzt die Mindestbreite MIN_BUILDING_WIDTH=4,
an einer echten Lücke in den gemessenen Verhältnissen festgemacht (größte plausible
große Grundfläche: Verhältnis 10,8 bei 7.196 m²; nächste eindeutig wandartige Form:
Verhältnis 12,0 bei 60,5 m²). Zusammen fallen 766 Grundrisse (33,5 %, 36.986 m² =
3,3 % der Fläche) weg.
Bestehende Fixture in test_small_staircase_building_is_not_dropped vergrößert (4x4-
auf 6x6-Block): ihre kurze Seite lag zufällig bei ~3,7 m, unter der neuen Schwelle,
und hätte den Test sonst für den falschen Grund bestehen lassen (Ruling 74 statt
Ruling 28).
Pipeline neu durchgelaufen: eindeutige Gebäude 2.282 -> 1.520 (-33,4 %), Dreiecke
über alle 144 Chunks 327.181 -> 307.678 (-6,0 %, vollständig aus der Gebäude-Ebene),
public/data/vice-a 2,73 M -> 2,50 M.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Task 11: Figuren (Mannequin/Superhero Male/Female) mit auf ual.glb
retargeteten Animationen, Frisuren, vier SUVs auf angehefteten Chunks,
ein lil-gui-Debug-Panel (Figur/Frisur/Höhe/Hitbox/Chunk-Grenzen/
Kartenbild/Nebel/Wahrzeichen-Sprung) und die verpflichtende
Namensnennung fürs HUD (Kartenkacheln, Wahrzeichen, SUV, Texturen,
Palme, Figuren — jede Quelle mit ihrer eigenen Lizenz).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ruling 60: vergeLampPoints sucht von 6 bis 16 m nach außen und verwirft eine
Laterne ganz, wenn keiner der sechs Abstände die Straßenpolygone des Chunks
verlässt (Punkt-in-Polygon mit Löchern, pointInPolygon). Ruling 61: die vier
nie platzierten Requisiten (Bank, Mülleimer, Hydrant, Absperrung) fliegen aus
props.mjs und aus dem Repository, ~18 MB auf 1,9 MB im Arbeitsverzeichnis.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Ruling 34 (Important, Fix-Runde 1 zu Aufgabe 6): _ring() verwarf jedes Loch
eines Polygons (nur poly.exterior wurde in Weltkoordinaten -> three.js
uebertragen). Vor dem Chunk-Zuschnitt war das meist harmlos, weil das
groesste Loch die Bucht selbst ist und beim Zuschneiden ohnehin herausfaellt
- danach blieb es aber ein echter Datenverlust: ein von Strassen umschlossener
Block wurde zu Asphalt, ein Innenhof zu Gebaeudemasse, ein Teich im Park zu
Wiese. Gemessen an echten Daten: 120 Strassen-Chunk-Stuecke (449.876 m2),
127 Stadtflaechen-Stuecke (208.657 m2 wobei 1 weiteres Park-Stueck), 30
Land-Stuecke (11.402 m2) und mindestens 75 Gebaeude-Stuecke trugen ein
verworfenes Loch.
_ring() wird _rings(): liefert [poly.exterior, *poly.interiors] in derselben
Transformation, Aussenring zuerst. Payload-Schema aendert sich entsprechend
fuer land/surfaces/roads/buildings von einem flachen Ring zu einer Liste von
Ringen; centerlines und palms sind unveraendert (keine Polygone). Task 7s
extrudePolygons() ruft ShapeUtils.triangulateShape(ring, []) bereits mit
einem (bisher leeren) Loecher-Array - die Aenderung passt jetzt durchgehend,
bevor Aufgabe 7 gebaut wird. write_debug_png() zeichnet weiterhin nur den
Aussenring (poly[0]), Loecher werden im Debug-Bild nicht dargestellt.
Neuer Test test_polygon_holes_survive_into_the_payload prueft das direkt an
einem Block mit Loch; die Koordinaten wurden vor dem Festschreiben gegen die
tatsaechliche chunk_payload()-Transformation nachgerechnet (uv run python,
nicht nur von Hand). test_coordinates_are_chunk_local_three_js musste auf
das neue [0]-Aussenring-Indexing angepasst werden.
Ruling 35 (Important): split_by_chunk_all() - die Variante, die run.py
tatsaechlich benutzt, nicht das getestete split_by_chunk() - hatte einen
MultiPolygon-Zweig ohne jede Testabdeckung. Neuer Test mit einer Klammerform
(Steg ausserhalb der Chunk-Zelle, zwei Zinken je einmal hineinreichend)
trifft genau diesen Zweig gezielt; er war schon vor der Aenderung gruen -
bestaetigt als Abdeckungsluecke, nicht als Bug.
uv run pytest -v: 36 passed (34 zuvor + 2 neu).
Pipeline (run.py) am gecachten Mosaik neu durchlaufen: weiterhin 144
Chunk-Dateien, public/data/vice-a/ jetzt 2,7 MB (zuvor 2,5 MB; +0,2 MB fuer
die erhaltenen Loecher). Insgesamt tragen jetzt 415 Chunk-Stuecke mindestens
ein Loch: Land 30/213, Stadtflaechen 127/1145 (+1 Park-Flaeche), Strassen
120/953, Gebaeude 137/2859 (80 global-eindeutige Gebaeude vor
Chunk-Duplizierung). Land/Strassen/Stadtflaechen treffen die oben genannten
Referenzwerte exakt; bei Gebaeuden weicht die Stueckzahl vom Review-Befund
(75) ab. Stichprobe der vier flaechenmaessig groessten Gebaeude-Loecher
(Debug-PNGs chunk_8_0, chunk_2_10, chunk_5_11 sowie ein viertes) zeigt
plausible echte Ring-Bauwerke (ein stadionartiger Rundbau, eine
Wendel-Parkrampe) statt offensichtlicher Fehlklassifikation - die
verbleibende Abweichung duerfte an der bereits im Task-6-Bericht
offengelegten Restunsicherheit der Gebaeude-Ueberlappungsrekonstruktion
liegen (263 vs. 258 spekulative Gebaeude), nicht an dieser Aenderung; im
Fix-Bericht dokumentiert.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Task 6: leonida/emit.py (chunk_box, split_by_chunk, chunk_payload und die
Chunk-lokalen three.js-Koordinaten, write_chunks, write_debug_png) sowie
run.py als Ablaufsteuerung, die alles aus den Tasks 3-5 zu 144 Chunk-Dateien
und einem Manifest unter public/data/vice-a/ zusammenfuehrt.
Zwei Abweichungen vom Referenzcode der Aufgabe, beide durch Gegenrechnen
gegen die dort genannten Realwerte gefunden:
- test_emit.py::test_coordinates_are_chunk_local_three_js gab im Original
das ungeschnittene BIG (spannt vier Chunks) direkt an chunk_payload();
chunk_payload() clippt selbst nicht (das tut in run.py split_by_chunk_all
vorher), darum lag der Rand bei x=300 statt <=250 und der Test schlug mit
dem gegebenen Code fehl. Fix: BIG vor dem Aufruf mit split_by_chunk auf
Chunk (0,0) zuschneiden, wie es run.py fuer "land" ohnehin tut.
- run.pys Filter "Gebaeude, die zu >50% in einem Strassenpolygon liegen,
gelten als Strasse" pruefte im Original ALLE rohen Gebaeude gegen
road_polygons(labels) direkt. road_polygons() zaehlt "spekulativ" selbst
zu den Strassenklassen (ROAD_CLASSES) und schliesst zusaetzlich mit
disk(3) gegen Strassennamen; ein isoliertes "spekulativ"-Gebaeude
ueberlappt sich darueber praktisch mit sich selbst. Ergebnis am realen
Mosaik: von 267 rohen spekulativen Gebaeuden ueberlebten nur 3 (statt der
in der Aufgabe genannten Groessenordnung von 258), und die Schliessung
riss zusaetzlich 211 gewoehnliche graue Gebaeude mit heraus, die die
Notiz aus Task 5 ausdruecklich nicht meinte ("die ROTEN Flaechen ...
werden abgezogen"). Fix: eigenes, unzweideutiges Strassenmass nur aus
"strasse"/"weg" (ohne "spekulativ", ohne Namens-Schliessung), Pruefung
nur auf spekulative Kandidaten begrenzt. Ergebnis: 2.348 Gebaeude, davon
263 spekulativ (Aufgabe: 2.352 bzw. 258) - Wahrzeichenhoehen (68 Stueck,
31-248 m) und Palmenzahl (2.133) treffen die genannten Referenzwerte exakt.
Pipeline-Lauf am gecachten Mosaik: 144 Chunk-Dateien + Manifest, 2,5 MB
gesamt (Budget 10 MB), groesste Datei chunk_9_1.json/chunk_10_1.json mit
je 40 KB. Alle drei Toleranzgrenzen (wasser/strasse/gebaeude) eingehalten.
Debug-PNGs stichprobenartig gesichtet: Kuestenlinie, Strassennetz
(inklusive Kreuzungen und einer Auffahrt-Rampe) und ein Strand mit
Palmenreihe liegen deckungsgleich auf dem Mosaik; der wasserreine Chunk
(4,10) zeigt korrekt keine Vektoren.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
knsoandClaude Opus 5