D4rkst3randClaude Opus 4.8
6ed2257085
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>
23 lines
439 B
TOML
23 lines
439 B
TOML
schema_version = "1.0.0"
|
|
|
|
id = "stylized_tree_generator"
|
|
version = "1.46.0"
|
|
name = "Stylized Tree Generator"
|
|
tagline = "Parametrische Baeume, Palmen, Bueschen mit Wachstums-Stufen"
|
|
maintainer = "D4rkst3r"
|
|
type = "add-on"
|
|
|
|
website = "https://git.d4rkst3r.de/D4rkst3r/stylized-rock-generator"
|
|
|
|
tags = ["Object", "Mesh", "Modeling"]
|
|
|
|
blender_version_min = "4.2.0"
|
|
|
|
license = [
|
|
"SPDX:GPL-3.0-or-later",
|
|
]
|
|
|
|
copyright = [
|
|
"2026 D4rkst3r",
|
|
]
|