1a1c3a5c59a3008aeb88107fd0af1b99f15bd238
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  D4rkst3randClaude Opus 4.8
|
1a1c3a5c59 |
Tree Gen 1.47.0: Hochstamm auf jeder Wachstums-Stufe
Bis 1.46 war am Obstbaum nur S4 kalibriert. Im Welt-Test ist der User auf einen
S3 gestossen, der sich als duenne Astgabel mit Laubklumpen las. Gemessen lag
der Kronenansatz bei 10 / 16 / 22 / 29 % ueber die Stufen - den freien Stamm
gab es nur ganz am Ende.
Ursache ist der allgemeine Setzlings-Faktor 0.35 auf Branch Start. Der bildet
die Selbstbeschneidung eines WILDEN Baums ab: junge Baeume tragen ihre Aeste
tiefer und asten sich erst spaeter auf. Ein Hochstamm wird aber GEZOGEN - die
Baumschule veredelt hoch und nimmt die unteren Triebe weg, der freie Stamm ist
von Anfang an da.
GROWTH_OVERRIDES["obstbaum"] = {"Branch Start": 1.0} - jetzt 29 % auf allen
vier Stufen. test_obstbaum prueft die ganze Wachstumsreihe; Gegenprobe ohne die
Ausnahme: drei Fehler.
Definitions-Hinweis fuer den Abgleich mit der Spielseite: dort wird "Ansatz"
ueber den tiefsten BLATT-Vertex gemessen, hier ueber den tiefsten AST-Vertex.
Die Spielseite sah deshalb einen Einbruch in der Mitte (33/17/13/21), wir eine
monotone Reihe - dasselbe Preset, zwei Definitionen, derselbe echte Befund.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
65feb71e56 |
Obstbaum-Test: Begruendung des Radius-Kriteriums richtiggestellt
Nur Doku, keine Schranke und keine Geometrie geaendert - deshalb kein Versionssprung. Der Dateikopf behauptete, "Kronenradius >= 1.80" sei die technische Voraussetzung der Frucht-Streuung. Das stimmte, solange die Streuung einen festen Radial-Schub (0.24 m) benutzte: bei zu kleiner Krone haette dieser feste Betrag die Fruechte nach draussen geschoben. Die Kopplung ist weg. Seit dem Umbau auf die Bueschel-Schalen arbeitet die Streuung mit einer Huellen-Tabelle (16 Sektoren x 6 Hoehenbaender) und setzt die Fruechte auf 94 % der LOKALEN Huelle - vollstaendig relativ. Das Kriterium bleibt (Entscheidung der Spielseite), aber als Look- und Gameplay-Boden: unter einem Obstbaum soll man ernten koennen. Und weil max ueber die RINDE von den Schalen unberuehrt bleibt, waehrend jedes Blatt-Mass mit der Bauform wandert - eine Umstellung auf ein Blatt-Perzentil wuerde die Zahl still umdeuten und zwei Kalibrier-Runden neu aufmachen. Eine Begruendung, die nicht mehr traegt, ist gefaehrlicher als gar keine: der naechste Leser haette die Kopplung fuer bestehend gehalten. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
9f4aad03ea |
Tree Gen 1.46.1: Kronenzylinder mit p90 statt Maximum
Befund der Spielseite beim Umbau ihrer Frucht-Streuung, hier nachgemessen: seit
den Bueschel-Schalen streut der Kronenradius viel breiter.
Obstbaum S4 p50 1.35 p90 2.12 max 3.17
Eiche S4 p50 1.12 p90 1.69 max 2.37
Tanne S4 p50 1.17 p90 2.49 max 3.91
Das Maximum haengt an EINER weit aussen sitzenden Card. Die Deckungs-Zahl faellt
damit 2.3-mal pessimistischer aus (Obstbaum 1.2 statt 2.8 m2/m3) - und weil das
Verhaeltnis max/p90 je Art verschieden ist (Tanne 1.57, Eiche 1.40), verzerrt es
auch den VERGLEICH gegen die Eiche, den dieser Test fuehrt.
Das Breitenprofil rechnete seit 1.41 mit p90; der Kronenzylinder der
Deckungs-Messung war die Stelle, die ich damals uebersehen habe. Jetzt beide
gleich.
Der Kronenradius fuer die Frucht-Bedingung (>= 1.80 m) bleibt bewusst das
Maximum ueber die RINDE: Bark ist von den Schalen nicht betroffen, die Zahl
bedeutet dort unveraendert dasselbe.
Nur Messung, keine Geometrie-Aenderung - die Deckungswerte verschieben sich von
2.6-4.5 auf 3.5-5.5 m2/m3, das Verhaeltnis zur Eiche von 104-179 % auf
86-136 %. Alle Schranken halten.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
6ed2257085 |
Tree Gen 1.46.0: Halbkugel-Bueschel, groessere Baeume, Spitzen-Deckung
1) NEUE BAUFORM: Blattwerk als Halbkugel-Cluster
Jeder gestreute Punkt ist jetzt ein Cluster-ZENTRUM, die Cards sitzen auf
der oberen Halbkugel darum herum. Untere Haelfte weggelassen - von unten
sieht man die Krone gegen den Himmel, das waere Overdraw fuer nichts.
Zwei Annahmen kassiert die Messung: GeometryNodeMeshIcoSphere liefert bei
Subdivisions 0 UND 1 dasselbe Ikosaeder, ein Cluster hat SECHS Cards statt
der angenommenen 26. Und die Stufen-Ziele muessen Cluster-Vielfache sein
(26/78/208/390) - S1 stand auf 10, unter der kleinsten Einheit, die Regelung
waere nie konvergiert. S4 ist seither geregelt statt "volle Dichte":
ungeregelt lieferte die Schale 2706 Cards an der Eiche.
ast_id ueberlebt Instanzieren + Realize, an den Cards nachgewiesen.
2) SPITZEN-DECKUNG: zwei echte Ursachen, beide vorher nur vermutet
- Der Kronenansatz-Filter stand auf 25 % der Baumhoehe, die Tanne setzt ihre
Aeste ab 12 % an: bei 5 von 22 Aesten lag das aeussere Fuenftel KOMPLETT
unter dem Filter. Jetzt auf den Branch Start der Art gedeckelt.
- Haengende Spitzen fielen unter den Filter. Jetzt zaehlt der ANSATZ des
Astes (anchor) mit, nicht nur die Punkthoehe.
Ergebnis: Eiche/Baum 100 %, Weide 100/90, Obstbaum 100/93, Tanne 86/86,
Birke 100/72. Die 85-%-Schwelle der Spielseite ist damit erreicht, ohne dass
die Rinden-Ersparnis noetig war.
Die Metrik war zweimal falsch: der Abstand zur Card-MITTE ist zu streng -
eine 0.85-m-Card deckt die Spitze auch aus 0.45 m Abstand, bei 1.9 m
Astlaenge kamen so 24 % heraus, obwohl das Polster genau auf der Spitze sass.
Jetzt zaehlt Deckung, nicht Abstand.
3) GROESSERE BAEUME, proportional skaliert
Eiche 9.3 m, Birke 11.0, Tanne 13.0, Weide 7.0 - Hoehe, Astlaenge und
Stammradius zusammen, sonst wird der Baum eine Stange mit Minikrone. Alle
unter dem 4300er-Deckel; die Birke brauchte eine Card-Deckelung auf 340.
4) Kugel-Kennwert RELATIV, Bbox-Kriterium ersetzt
Die Schalen schieben jede Card in ALLE Richtungen vom Ast weg: die Krone
gewinnt ringsum Breite, in der Hoehe nur oben. Der Obstbaum fiel dadurch von
1.35-1.47 auf 0.95-1.23, ohne dass an seiner Form etwas falsch war.
Zwei Hypothesen sind an der Messung gescheitert, beide klangen plausibel:
den Kappen-Faktor entkoppeln (0.93-1.14 -> 0.95-1.23) und den Kappen-Radius
vergroessern (59-77 % -> 58-75 %). Der Radius waechst in alle Richtungen und
verschiebt das Verhaeltnis deshalb kaum. Was wirkt, ist die Kronenbreite.
Schranke jetzt relativ: hoechstens 65 % des Eichenwerts aus DEMSELBEN Lauf.
Eine neue Konstante haette bei der naechsten Bauform dasselbe Schicksal.
LEAF_CLUSTER_PRESET bleibt trotzdem eine eigene Tabelle - Card-Grobheit und
Polster-Abstand sind zwei verschiedene Fragen.
"Bbox-Mitte == 0" ist raus. Nachgemessen ueber drei Presets und drei Seeds:
Stammachse 0.0000 m in allen neun Faellen, Bbox-Exzentrik 0.08-0.39 m mit
dem Seed streuend, 3-13 % des Kronenradius. Eine Verschiebung traefe den
Stamm mit und waere ueber die Seeds konstant - es ist Kronen-Schieflage.
An seine Stelle tritt der Bounds-Radius, an dem das Culling haengt, geprueft
gegen die Blender-Messung statt gegen eine Konstante.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
263b8507d8 |
Tree Gen 1.41.0: Obstbaum-Kugelkrone (Lollipop) ueber den Kronenansatz
Zielbild der Spielseite ist der Lollipop der stilisierten Vektor-Illustration. Der Weg dorthin fuehrt NICHT ueber mehr Baumhoehe (4.9 m sind die Ernte-Reichweite), sondern ueber einen tieferen Kronenansatz: 39 % -> 29 %, Stamm 1.9 -> 1.5 m. Die Krone wird dadurch von selbst hoeher (3.8 -> 4.3 m). Dazu Crown Taper 0.15 -> 0.35, Crown Bulge 1.1 -> 1.5, Branch Droop 0.4 -> 0.25. Gemessen ueber alle neun Produktions-Seeds: Kronenansatz 29 %, unten/mitte 0.86-1.01, oben/mitte 0.63-0.74, Kugel 1.35-1.47, Kronenradius 2.00-2.15 m, Deckung 81-103 % der Eiche, Hoehe 4.90 m. Das Messen war schwieriger als das Einstellen; zwei eigene Fehler, beide vor der Abnahme gefunden: 1) Die Kronenbreite je Drittel als MAXIMUM ueber die Card-Punkte zu messen haengt an EINER Card. Unten/mitte sprang je Seed zwischen 0.89 und 1.00 bei stabilem Mittelwert 0.94 - Rauschen, keine Form. Mit dem 90. PERZENTIL wurde es stabil und zeigte sofort etwas anderes: die Krone war unten tatsaechlich am breitesten (1.04), was das Maximum verdeckt hatte. 2) Der Kugel-Kennwert bekam erst die Schranke 0.88 - eine Zahl aus einem Messskript mit anderer Breitendefinition. Mit der Test-Formel liegen die Werte um 1.4, die Schranke haette alles durchgelassen. Zum zweiten Mal dieselbe Falle nach der Deckungs-Schwelle. Deshalb sind jetzt ALLE Referenzformen mit demselben Mass gemessen und stehen als Tabelle im Test (Eiche, Trichter, Haube, Pilz, Kugel). Die Tabelle zeigt auch, was NICHT trennt: der Kugel-Kennwert unterscheidet Kugel und Haube nicht (1.35-1.47 gegen 1.26-1.44) - das tut der Kronenansatz, und der wird geprueft. Die Kugel-Schranke bleibt als zweites Netz gegen Trichter und Pilz drin, mit genau diesem Vermerk. Das Wunschband der Spielseite (u/m 0.85-0.95) ist schmaler als die Streuung von Seed zu Seed (0.86-1.01). Die Schranken kommen deshalb aus der Messung aller Formen, nicht aus dem Band. Gegenproben: Haube 9 Fehler (Kronenansatz), Trichter 37 (alle vier Kriterien). 26 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
d87450a4b8 |
Obstbaum: B/H-Band gilt fuer dieses Preset nicht mehr (Regel festgehalten)
Nur Doku und Test-Kommentare, keine Geometrie-Aenderung - deshalb kein Versionssprung. Die Spielseite hat den Dauerkonflikt aufgeloest: Kronenradius >= 1.80 schlaegt B/H <= 0.75. Zweimal war die Abwaegung dieselbe (Kronenradius traegt die Frucht-Streuung), beim zweiten Mal wurde daraus eine Regel statt einer Einzelfallentscheidung. Die gemessenen 0.77-0.82 sind der Preis der Frucht-Tragflaeche. Sachlich richtig ist das auch deshalb, weil B/H die Form gar nicht absichert: es haette sowohl den Trichter (oben/mitte 1.07) als auch die Pilzform (unten/mitte 1.17) durchgelassen. Das Breitenprofil trennt beide sauber. Festgehalten in test_obstbaum.py (Kopf + Kommentarblock), im Preset selbst und in der README - damit die Abwaegung nicht ein drittes Mal von vorn gefuehrt wird. Im Preset stehen jetzt die Neun-Seed-Werte statt der alten Drei-Seed-Zahlen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
0b6f0deff9 |
Tree Gen 1.40.0: Obstbaum-Krone schliesst sich oben (Trichter behoben)
Der Baum erfuellte Kronenradius, Deckung, Kronenansatz und Tri-Budget - und sah trotzdem falsch aus. Sichtbar wurde es erst am BREITENPROFIL der Krone in Dritteln (unten/mitte/oben, Messung der Spielseite nachgestellt): Eiche 3.0 / 2.8 / 2.6 oben/mitte 0.90 (liest sich als Baum) Obstbaum 3.3 / 4.5 / 4.7 oben/mitte 1.07 (Trichter) Kein einzelner Regler hat das geloest: Crown Taper (-0.10 bis +0.50), Branch Droop (0.6-1.2), Crown Bulge (1.0-1.8) und Attraction Up einzeln durchgefahren liessen oben/mitte bei rund 1.0 stehen. Der Grund ist strukturell: die Kronenform folgt nicht der Astlaenge je Hoehe, sondern dem WEG DER ASTSPITZEN. Solange die Aeste aufwaerts schwingen, landet das aeusserste Laub oben. Loesung ist eine andere Bauform, kein Feintuning - kurze Aeste an einem hohen Stamm statt langer Aeste an einem kurzen: Height 3.8 -> 4.9, Branch Length 2.55 -> 1.25, Branch Start 0.52 -> 0.40, Attraction Up +0.40 -> -0.05, Crown Taper -0.30 -> +0.15, Crown Bulge 0.60 -> 1.10, Branch Droop 0.35 -> 0.40. Ueber alle neun Produktions-Seeds: oben/mitte 0.63-0.84, Kronenradius 1.88-2.01 m, Deckung 100-134 % der Eiche, 3752-4166 Tris, Ansatz 39 %. Beim Einregeln kippte die Form zwischendurch in eine PILZform (unten am breitesten) - deshalb steht das Profil jetzt als Test da. test_obstbaum prueft oben/mitte <= 0.85. Gegenprobe mit den 1.39er Werten: neun Fehler bei 0.98-1.11. B/H liegt jetzt bei 0.77-0.82 (Band der Spielseite 0.55-0.75). Bleibt bewusst ungeprueft, wie beim Kronenradius entschieden: die Vorgaben Kronenradius >= 1.80 und B/H <= 0.75 sind bei 4-5 m Hoehe nur im Mittel gleichzeitig erfuellbar. 26 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
5a43ead8d1 |
Tree Gen 1.39.0: Kronenfuellung des Obstbaums - Flaeche statt Card-Zahl
Der Obstbaum las sich in der Engine als einzelne belaubte Ast-Schlaeuche mit Himmel dazwischen. Die Card-Zahl erklaert das nicht; die Blattflaeche pro Kronenvolumen tut es: Eiche (schliesst) 444 Cards, Krone 18.9 m3 -> 24.6 m2/m3 Obstbaum vorher 399 Cards, Krone 36.2 m3 -> 11.4 m2/m3 Fast doppeltes Volumen bei gleicher Card-Zahl. Der Vorschlag der Spielseite - mehr und laengere Sub-Aeste als Fuellwerk - wurde durchgemessen und VERWORFEN: Sub Count 5/7, Sub Length 1.0/1.3, Sub Start 0.20/0.30, Branch Count 12/14 bewegten den Fuellgrad um hoechstens 7 Punkte und trieben die Dreiecke auf 4310-5162. Strukturell: neue Zweige wachsen aus denselben wenigen Hauptaesten und vergroessern dabei die Krone, das Volumen waechst also mit. Ebenfalls verworfen: mehr Cards (Ziel 740 = 5426 Tris, 26 % ueber Budget, und der Fuellgrad stieg nur auf 75 %). Und eine kleinere Krone: Branch Length 2.35 sah ueber drei Seeds mit 1.83 m gut aus, im Neun-Seed-Test fielen SECHS Seeds unter die 1.80 m der Frucht-Streuung. Was wirkt, ist die Card-GROESSE (neu: LEAF_SIZE_PRESET, Faktor je Preset). Sie kostet kein Dreieck, weil die Card-Zahl gedeckelt ist - aber OVERDRAW, und der ist bei Bueschel-Cards der eigentliche Engpass. Deshalb der maessige Faktor 1.47: Deckung von 46 auf 87-114 % der Eiche, Card-Flaeche 414 -> 893 m2, bei 3697 statt 3714 Tris. Faktor 1.71 brachte 79 % Fuellgrad bei 2.7-facher Flaeche - das waere eine Overdraw-Entscheidung der Spielseite. test_obstbaum prueft die Deckung jetzt mit, und zwar gegen die im SELBEN Lauf gemessene Eiche statt gegen eine feste Zahl: die Deckung haengt an der Card-Flaeche, eine 6-Tri-Card bringt das Dreifache einer flachen Raute. Der erste Anlauf des Checks ist genau daran gescheitert. Gegenprobe gefahren: mit Faktor 1.0 meldet der Test 9 Fehler bei 42-54 % der Eiche. 26 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
4aaf3231ef |
Tree Gen 1.37.0: Obstbaum-Preset + Card-Groesse gegen die Baumhoehe
1) Neues Preset "obstbaum" (Apfel/Kirsche/Birne) Eigenes Preset statt Umbau von "baum": der wird anderswo verwendet, und ein Hochstamm ist keine Standard-Silhouette. Der Zweck ist funktional, nicht bloss optisch: die Frucht-Streuung setzt Fruechte auf die AUSSENHAUT der Krone. Am generischen baum war der Kronenradius 0.78 m bei 1.28 m Card-Diagonale - die Cards waren groesser als die Krone, es gab keine Haut. Proportion belegt (Hochstamm): Kronenansatz 180-220 cm, Krone selbst 3-4 m. Ergibt 4.8 m Gesamthoehe und knapp 40 % Ansatz - genau das Band der Spielseite. Gemessen ueber alle NEUN Seeds der Spielseite: Hoehe 4.91-5.12 m, Kronenradius 1.83-2.05 m, Ansatz 38-40 %, Kronenradius/Card 2.15-2.42, 3560-3824 Tris. Deckelung auf 420 Cards ueber LEAF_STUFEN_PRESET, sonst 4304-4400 Tris. Zwei Fallen, gemessen statt vermutet: "Height" ist die STAMMlaenge, nicht die Baumhoehe (Height 4.8 ergab 5.4-6.2 m), und der Kronenansatz zaehlt gegen die GESAMThoehe (Branch Start 0.37 ergab 29 %). test_obstbaum.py prueft die funktionale Bedingung ueber alle neun Seeds. B/H ist BEWUSST nicht hart geprueft: B/H 0.55-0.75 und Kronenradius >= 1.80 bei 4-5 m Hoehe lassen zusammen nur ein 4 % breites Fenster, waehrend die Streuung von Seed zu Seed 12 % betraegt. Vorrang hat der Kronenradius. 2) Card-Groesse misst sich an der BAUMHOEHE Mit 0.45/0.63/0.82/1.00 schrumpfte die Card um Faktor 2.2, der Baum um 6.2. Gemessen an der Birke 27/14/11/9 % der Baumhoehe, an der Eiche 33 gegen 11 - der Setzling trug relativ dreimal so grosses Laub wie der Altbaum. Jetzt 0.24/0.46/0.75/1.00: 14/10/10/9 %. Nicht ganz flach, ein junger Baum traegt seine Bueschel relativ groeber; auf Altbaum-Proportion gezwungen (0.18) wird er kahl. test_blatt_bueschel prueft die Spreizung jetzt direkt und ueber Inseln statt ueber Face-Index-Paare. HINWEIS an die Spielseite: der Addon-Pfad skaliert S1 auf 0.45 der S4-Groesse, auf BEIDEN Wegen nachgemessen (Einzelcard und Sammlung). Die dort gemessenen 0.76 entstehen also erst danach - bitte growth_t am S1-Objekt direkt vor treegen_leaves pruefen, das muss 0.0 sein. 25 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |