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>

stylized_tree_generator.py

@@ -1,7 +1,7 @@
 bl_info = {
     "name": "Stylized Tree Generator",
     "author": "D4rkst3r",
-    "version": (1, 38, 0),
+    "version": (1, 39, 0),
     "blender": (4, 2, 0),
     "location": "View3D > Sidebar > Tree Gen",
     "description": "Parametrischer Baum-/Palmen-/Busch-Generator (Geometry Nodes) mit Wachstums-Stufen",
@@ -197,6 +197,11 @@ PRESETS = {
     "obstbaum": {
         "Height": 3.8, "Trunk Radius": 0.13, "Bend": 0.3, "Taper": 0.7,
         "Branch Count": 9,         # offene Krone: wenige Leitaeste, Licht durch
+        # Bleibt bei 2.55. Die Krone zu verkleinern waere der zweite Hebel gegen
+        # den niedrigen Fuellgrad gewesen - bei 2.35 fielen aber SECHS der neun
+        # Seeds unter den Kronenradius von 1.80 m, den die Frucht-Streuung
+        # braucht (1.73-1.79). Ueber drei Seeds gemittelt sah es mit 1.83 noch
+        # gut aus; erst der Neun-Seed-Test hat es aufgedeckt.
         "Branch Length": 2.55, "Branch Up": 0.7,
         "Branch Start": 0.52, "Branch End": 0.90,
         "Crown Taper": -0.30, "Crown Bulge": 0.60,   # rund, Bauch in der Mitte
@@ -1627,6 +1632,41 @@ LEAF_STUFEN_PRESET = {
     "obstbaum": {3: 420},
 }
 
+# Card-GROESSE je Preset, als Faktor auf die eingestellte Groesse.
+#
+# Warum das ueberhaupt eine eigene Tabelle braucht: die Kronenfuellung haengt an
+# der Card-FLAECHE, nicht an der Card-Zahl - und wie viel Flaeche eine Krone
+# braucht, haengt an ihrem Volumen. Gemessen (S4, Cards je m3 Kronenzylinder /
+# Anteil belegter 0.4-m-Voxel):
+#
+#   Eiche      444 Cards, Krone r 1.26 x 3.78 = 18.9 m3 -> 23.7/m3, 88 % belegt
+#   Obstbaum   399 Cards, Krone r 2.00 x 2.88 = 36.2 m3 -> 11.1/m3, 60 % belegt
+#
+# Die Obstbaum-Krone hat fast das doppelte Volumen bei gleicher Card-Zahl -
+# daher las sie sich als einzelne belaubte Ast-Schlaeuche mit Himmel dazwischen
+# ("behaarte Finger", Abnahme der Spielseite).
+#
+# Durchgemessen und VERWORFEN: mehr und laengere Sub-Aeste als Fuellwerk. Sub
+# Count 5/7, Sub Length 1.0/1.3, Sub Start 0.20/0.30, Branch Count 12/14 - der
+# Fuellgrad bewegte sich um hoechstens 7 Punkte, die Dreiecke stiegen auf
+# 4310-5162. Der Grund ist strukturell: neue Zweige wachsen aus denselben wenigen
+# Hauptaesten und vergroessern dabei die Krone, waehrend die Card-Zahl gedeckelt
+# bleibt. Das Volumen waechst also mit.
+#
+# Ebenfalls verworfen: mehr Cards. Bei Ziel 740 (was rechnerisch fuer 25/m3
+# noetig waere) kamen 5426 Tris heraus - 26 % ueber Budget - und der Fuellgrad
+# stieg nur auf 75 %. Cards zaehlen ist nicht dasselbe wie Flaeche decken.
+#
+# Was wirkt, ist die Card-Groesse: sie kostet KEIN einziges Dreieck, weil die
+# Zahl gedeckelt ist. Sie kostet aber OVERDRAW - und der ist bei Bueschel-Cards
+# der eigentliche Engpass, nicht der Dreieckszaehler. Deshalb der maessige
+# Faktor: 1.47 hebt den Fuellgrad von 60 auf 74 % und verdoppelt die Card-
+# Flaeche (414 -> 832 m2). 1.71 brachte 79 % bei 2.7-facher Flaeche - das waere
+# eine Overdraw-Entscheidung der Spielseite, keine Generator-Frage.
+LEAF_SIZE_PRESET = {
+    "obstbaum": 1.47,
+}
+
 
 def _stufen_anteile(growth_t, preset=None):
     """Ziel-Cardzahl, Groessen- und Kronenansatz-Wert fuer einen Wachstums-Fortschritt.
@@ -1803,7 +1843,10 @@ def make_leaves(context, tree_obj, card_obj, name=None, card_coll=None,
 
         basis = dict(LEAF_DEFAULTS)
         basis.update(overrides)
-        overrides["Size"] = basis["Size"] * g_anteil
+        # Preset-Faktor auf die Card-Groesse: eine weite Krone braucht mehr
+        # Card-FLAECHE, um geschlossen zu wirken (siehe LEAF_SIZE_PRESET).
+        p_faktor = LEAF_SIZE_PRESET.get(tree_obj.get("preset") or "", 1.0)
+        overrides["Size"] = basis["Size"] * g_anteil * p_faktor
         overrides["Max Radius"] = basis["Max Radius"] * r_faktor
         overrides["Min Height"] = h_anteil