6ed2257085f235ef39afa79615e3035a50db1f54
6
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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> |