Vom User im Wald abgenommen: "sehr schoen etwas weniger blaetter und wir
koennen das fuer alle baeume uebernehmen".
1) KRONEN-HUELLE statt Einzelkappen
Kugeln auf die Aeste, Mesh to Volume, Volume to Mesh, dann Streuung auf der
verschmolzenen Oberflaeche - der Standard-Ablauf aus den
Produktions-Breakdowns, den wir uebersprungen hatten. Die Aeste verschwinden
im Inneren der Krone; die Polster sind nicht mehr als getrennte Koerper
sichtbar.
Drei Befunde, alle gemessen:
- ast_id kam nur an 3 von 10 Aesten an. Nicht das Sampling, sondern die
Eingabe: nur VIER Cluster-Zentren auf drei Aesten. Sichtbar erst mit
Points to Vertices - to_mesh() auf eine Punktwolke liefert eine leere Mesh
und misst nichts.
- S1 stand kahl. Reihe ueber die Stufen 0/20/41/109 Zentren: allmaehlicher
Abfall, keine Klippe, also die Cluster-Dichte. "Dichte" ist Kugeln je m2
Zweigflaeche, die schrumpft quadratisch - sie laeuft jetzt mit 1/g^2
gegen die Groesse, damit die ANZAHL konstant bleibt. Skalenfrei, kein
Sonderweg fuer Setzlinge.
- 31 % der Cards lagen unter dem Kronenansatz: die Verschmelzung weitet die
Form nach unten, der Filter griff nur auf den Zentren. Jetzt auch auf der
Huelle.
2) WENIGER BLAETTER (-15 % auf die Stufen-Ziele)
Gemessen an der Eiche: 381 -> 319 Cards, Deckung 10.4 -> 8.6, 372 Tris
gespart. Der Gegenversuch - Cards um 15 % verkleinern - kostet MEHR Deckung
(7.9, die Flaeche geht quadratisch) und spart kein Dreieck.
3) FORMBAND um das Abgenommene gelegt, nicht umgekehrt
Alle Referenzformen unter der neuen Bauform neu gemessen:
Eiche u/m 1.04-1.16 o/m 0.79-0.91
abgenommen u/m 0.78-1.02 o/m 0.68-0.79
Trichter u/m 0.68-0.78 o/m 1.04-1.14
Pilz u/m 0.59-0.90 o/m 0.82-0.95
Haube u/m 0.94-1.03 o/m 0.71-0.78
u/m TRENNT NICHTS MEHR - der abgenommene Bereich ueberlappt den Pilz und
stoesst an den Trichter. Die alte 0.82-Schranke stammt aus der
Einzelkappen-Aera; dagegen zu kalibrieren haette die Krone verbogen, um eine
Zahl zu retten, die ihre Aussagekraft verloren hat. u/m wird nur noch
mitgedruckt. o/m trennt sauber und traegt die Formpruefung allein.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
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>
Der Legacy-Importer matcht UCX_<Mesh-Node>, nicht das LodGroup-Empty. Eine
Huelle mit dem Gruppennamen liegt in der Datei und ein Reimport nach Blender
zeigt sie an - Unreal verwirft sie aber STILL. Gemeldet von der Spielseite:
convex = 0 an 108 Stand-Baeumen und 57 Fels-Meshes; dieselbe Datei mit der
Huelle auf dem LOD0-Node liefert convex = 1.
UCX_<Basisname> stimmt nur OHNE LOD-Kette, weil der Mesh-Node dann so heisst -
deshalb waren Faell-Teile und _Pieces_All die ganze Zeit in Ordnung.
BEIDE Addons betroffen: der Fels-Export hatte den Fehler zuerst, der
Baum-Export hat ihn 1.42 von dort uebernommen.
Wie es durchrutschen konnte, ist die eigentliche Lehre: fuer 1.42 habe ich die
Konvention am Fels-Export NACHGEMESSEN statt sie zu raten - exportieren,
reimportieren, Name und Hierarchie pruefen. Das war richtig und hat trotzdem
nichts bewiesen, weil die Quelle denselben Fehler hatte. Gemessen wurde die
STRUKTUR, nicht die WIRKUNG. Eine abgeschaute Konvention ist nur so gut wie die
Quelle, von der sie stammt.
Die Tests pruefen jetzt die REGEL statt des Namens: hinter UCX_ muss ein
Mesh-Node aus derselben Datei stehen, und zwar LOD0 (hoechste Vertexzahl). Das
haette den Fehler in beiden Addons gefunden, ohne die Antwort vorher zu kennen.
Gegenproben: Baum 9 Fehler, Fels 1 Fehler.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Die Zusammenbau-Datei trug den SZENEN-Nullpunkt mit: ein Baum bei x = 18 m
exportierte gemessen mit X 16.5..19.3, Y -8.7..-6.2. Die Einzel-Teile hatten
das Problem nie (sie sitzen auf ihrem Massenmittelpunkt), der Stand-Baum folgt
der Stammbasis seit 1.36 - nur diese eine Datei fiel heraus.
Der Versatz kommt aus DERSELBEN Funktion wie beim Stand-Baum: die Rechnung ist
aus _origin_bottom_center als _stammbasis_versatz herausgeloest und wird von
beiden Wegen benutzt. Zwei Rechnungen fuer denselben Nullpunkt waeren genau die
Fehlerklasse, die hier schon dreimal zugeschlagen hat - und hier haette sie
besonders weh getan, weil die zusammengesetzten Truemmer exakt auf dem Platz
des Baums liegen muessen.
Angewendet nur fuer diesen Export, danach zurueckgenommen: mit "Teile behalten"
staenden sie sonst verschoben neben dem Baum in der Szene.
test_faell_teile stellt den Baum jetzt bewusst auf (18, -7.5) und prueft den
Stammfuss ueber den QUERSCHNITT auf Fusshoehe, nicht ueber die Bbox-Mitte - die
Krone haengt einseitig und wuerde den Fehler verwischen.
Gegenprobe ohne Versatz: Stammfuss bei 18.000 / -7.500, exakt der gemeldete
Wert.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Die Gesamtdatei kam ohne Kollision an, waehrend die Einzeldateien welche
hatten. Jetzt bekommt jedes Teil auch dort seine Huelle, gleiche Konvention wie
beim Stand-Baum: UCX_<Teilname> als Geschwister, kein Elternteil. Sie entstehen
VOR dem Umsetzen der Pivots, weil in der Gesamtdatei alle Teile noch an ihrer
Originalposition stehen.
Beim Nachmessen kamen zwei Fehler heraus, die auch die BESTEHENDEN
Einzeldateien betrafen:
1) Die Huellen umschlossen das Laub mit
_tree_ucx las alle Vertices eines Teils, also auch die Blatt-Cards. Gemessen
am baum-Preset war die Huelle dadurch 1.4- bis 2.1-mal so gross wie das Holz.
Jetzt nur noch Material-Slot 0. Die Spielseite hatte das fuer ihre
Interim-Boxen laengst so gemacht - zu Recht.
2) Das Aufweiten war fuer schlanke Teile kaputt
Nach dem Vereinfachen wurde die Huelle durch Skalieren um die Huellenmitte
aufgeblasen. Bei langgestreckten Teilen entgleist das: liegt eine Flaeche
fast durch die Mitte, wird der Hebel winzig und der Faktor explodiert -
gemessen 4.2 an einem Stammsegment mit Laenge zu Dicke 13:1. An der dicken
Eiche blieb es bei 1.0-1.4, deshalb ist es nie aufgefallen; erst der Wechsel
auf Rinde-only machte die Teile schlank genug.
Jetzt wird je Flaeche der ECHTE Fehlbetrag gemessen und die Vertices um genau
diesen Betrag nach aussen geschoben - eine Verschiebung in Metern, kein
Verhaeltnis. Iterativ, weil ein Vertex mehreren Flaechen angehoert und
entlang seiner eigenen Normale wandert (ein Durchgang liess einen Rest
stehen, der Test schlug an). Bleibt danach etwas uebrig, faellt die Funktion
auf die unvereinfachte Huelle zurueck.
Ergebnis am 12-teiligen Baum: alle Huellen 14-31 Verts (Budget 32), keine
groesser als das 1.35-fache ihres Holzes.
test_faell_teile prueft die Gesamtdatei jetzt auf: je Teil genau eine Huelle,
richtiger Name, kein Elternteil, und Huellengroesse gegen die RINDE.
Gegenproben: ohne Rinde-Filter 10 Fehler (1.41x bis 2.06x), ohne Huellen in der
Gesamtdatei 1 Fehler.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Die Stand-Baeume bekommen eine konvexe Kollisionshuelle um den STAMM, vom Fuss
bis zum Kronenansatz - keine Kronen-Huelle: gegen die liefe der Spieler, bevor
er den Baum beruehrt.
Die Trennung kommt aus ast_id (0 = Stamm), dasselbe Attribut wie beim Ursprung
und bei den Faell-Teilen. Kronenansatz = tiefster Punkt mit ast_id > 0 plus ein
Zehntel Stammhoehe Luft (der tiefste Astpunkt kann eine herabgebogene Spitze
sein). Ohne Aeste ist die ganze Pflanze Stamm - beim Kaktus genau richtig.
Name und Hierarchie sind NICHT geraten, sondern am Fels-Export nachgemessen,
der in der Pipeline schon abgenommen ist: UCX_<LODGroup-Name>, als GESCHWISTER
des LodGroup-Empty. Ein Kind der Gruppe wuerde Unreal als LOD-Stufe lesen.
Zwei Befunde aus der Messung:
- Die Huelle rutschte 4-6 cm UNTER den Boden. Das Vereinfachen auf 12 Verts
schneidet Ecken ab, das anschliessende Aufblasen skaliert um die Huellenmitte
und schiebt dabei die Unterseite nach unten. Im Spiel waere das eine
Kollision, die aus dem Terrain ragt. Boden wird jetzt auf Z = 0 geklemmt.
- Der erste Anlauf des Tests holte die FBX-Skala aus der Gesamthoehe - die
Blatt-Cards ragen ueber die Rinde hinaus, die Skala kam zu gross heraus und
die Huelle sah zu klein aus. Massstab kommt jetzt aus Material-Slot 0.
Neu: tests/test_stamm_ucx.py, vier Faelle (gerader Stamm, krummer Stamm mit
Bend 1.5, Obstbaum, einmal ohne LODs), gemessen im reimportierten FBX.
Gegenprobe ohne Boden-Klemmung: vier Fehler.
test_baum_export, test_baum_lod und test_ursprung zaehlten die Huelle als
Render-Mesh mit und schlugen zu Recht an - sie filtern jetzt UCX_.
Schalter im Export-Panel: "UCX-Stammhuelle" (an) + max. Verts (12).
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
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>
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>
1) Zwei-Pfade-Fehler behoben (von der Spielseite gemeldet)
Blattwerk entstand an zwei Stellen - Haekchen "_Leaf anlegen" beim Erzeugen
und Knopf "Blattwerk streuen" - und nur der zweite rechnete die
Wachstums-Staffel. Am Modifier nachgemessen trug der S1-Setzling aus dem
Create-Pfad Size 0.85, Max Radius 0.04, Min Height 0.25: die Altbaum-Werte.
Zum dritten Mal dieselbe Fehlerklasse (nach Stufen-Deckung und build_group):
zwei Quellen fuer dieselbe Frage. Die Staffel liegt jetzt in make_leaves
selbst und zieht growth_t/preset vom Baum-Objekt - ein Aufrufer KANN sie
nicht mehr vergessen. Darueber blattwerk_streuen() als der eine Einstieg
fuer beide Knoepfe, inklusive der Dichte-Regelung, die vorher ebenfalls nur
der Operator hatte. Nebenbei bekommt der Create-Pfad damit auch die
Card-SAMMLUNG, die ihm bisher fehlte.
test_zwei_pfade.py prueft die DIFFERENZ zwischen beiden Wegen, nicht die
absoluten Werte - ein Test, der nur einen Weg anschaut, findet so etwas nie.
Plus die Gegenprobe im Test selbst: waeren beide Wege gleich falsch, muss
auffallen, dass S1 und S4 dieselbe Card-Groesse tragen.
Gegenprobe gefahren: mit dem alten Create-Pfad meldet der Test 10 Fehler und
reproduziert exakt die gemeldeten 0.85 / 0.04 / 0.25.
2) Generischer "baum" entsaeult
Gemessen B/H 0.18 ueber fuenf Seeds - schmaler als jedes andere Laubgehoelz.
Ursache dieselbe wie bei der Birke: Branch Up 1.3 aus den DEFAULTS. Zielband
der Spielseite 0.45-0.60, jetzt 0.55 (0.52-0.56).
Die DEFAULTS bleiben unangetastet - sie sind die Socket-Vorgaben, an denen
die haendischen Regler haengen. Nur "baum" bekommt eigene Werte.
26 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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>
1) Ursprung: Stammbasis statt tiefstem Slot-0-Punkt
Zweimal war das schon "behoben". Erst kam der Ursprung aus der Gesamt-Bbox
(eine Blatt-Card hob den Baum an), dann aus Material-Slot 0 - aber die AESTE
gehoeren ebenfalls zum Rinden-Slot. Gemessen an Tanne_01_S1: tiefster
Slot-0-Punkt -5.35 cm, tiefster STAMM-Punkt -0.02 cm. Die Stammbasis
schwebte 5.3 cm ueber dem Boden.
Die exakte Trennung liefert ast_id (0 = Stamm) - dasselbe Attribut, das der
Baum fuer die Faell-Teile ohnehin traegt. Ein Schwellwert auf den
Achsabstand faellt beim Kaktus um: dessen Stamm ist dicker als jeder
sinnvolle Schwellwert. X/Y kommt jetzt aus dem untersten RING statt aus der
Stamm-Bbox; bei Bend 1.5 liegt die Bbox-Mitte in der Kruemmung.
Neu: tests/test_ursprung.py, gemessen am reimportierten FBX. Die erste
Fassung des Tests suchte den "tiefsten Punkt nahe der Achse" - die
Gegenprobe hat sie umgeworfen, weil bei der Tanne eine Astspitze ins
Achsband faellt. Ein Schwellwert, der die Bugfassung durchlaesst, prueft
nichts. Jetzt wird ein Stammquerschnitt gesucht: Vertices, die die Achse in
allen Himmelsrichtungen umschliessen. Gegenprobe bestanden.
Nebenbefund: ein Baum ohne Aeste traegt gar kein ast_id (Branch Count 0
schaltet den Ast-Zweig des Graphen ab). Dann ist alles Stamm und der
Fallback exakt.
2) Weide S4 auf 350 Cards gedeckelt - Entscheidung des Users
Gemessen 5456-5594 Tris ueber drei Seeds gegen 4300 Budget; nach der
Deckelung 3890-3962. LEAF_STUFEN_PRESET haelt solche Ausnahmen je Preset.
3) Birke war eine Saeule
Gemessen B/H 0.15 - schmaler als der Standardbaum (0.22), nicht die Haelfte
der Eiche (0.36). Ursache: Branch Up 1.1, die Aeste klebten am Stamm.
Zielband 0.35-0.55 aus Van den Berk (8-12 m bei 15-20 m) und Woodland Trust
(6-10 m bei 15-25 m); jetzt 0.51.
Haengende Zweigenden ueber Branch Droop 0.8 + Droop Curve 3.5, nicht ueber
negatives Sub Up: das wurde von +2.2 bis -2.0 durchgemessen und bewegt
nichts (1-6 %), weil die Sub-Aeste zu kurz sind. Mit Droop 26 % bei einem
Fall von 0.033 x Hoehe - wie die Tanne (0.030), weit weg von der Weide
(0.213).
4) run_tests.ps1 benennt Blender-Abstuerze
test_export_robust starb rund in jedem sechsten Lauf mit
EXCEPTION_ACCESS_VIOLATION und der Runner meldete "<keine Ergebniszeile>".
Der Stack enthaelt keinen einzigen Addon-Frame (RNA_property_int_get ->
rna_property_rna_or_id_get -> IDP_GetPropertyFromGroup, Null-Deref), und mit
eingebauten Markern verschwindet der Absturz: Heisenbug in Blender 5.1.2.
Der Runner wiederholt jetzt einmal und benennt den Absturz.
24 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
1) build_group riss Szenen-Baeume ab
Die Gruppe GN_Tree wurde bei JEDEM Erzeugen geloescht und neu angelegt -
damit zeigten alle bereits erzeugten Baeume auf ein totes Datablock und
evaluierten leer. Gemessen: nach vier Arten-Erzeugungen lebte nur noch die
letzte. Dass direkt nach dem Erzeugen exportiert wurde, hat das verdeckt.
Jetzt ein Waechter mit ZWEI Kriterien: abgelegte Schema-Version
(TREE_SCHEMA) UND die tatsaechlich vorhandenen Eingaenge. Die Version allein
reicht nicht - wer waehrend der Entwicklung Sockets aendert ohne die Zahl
anzufassen, bekaeme eine veraltete Gruppe untergeschoben. Muss doch neu
gebaut werden, werden bestehende Modifier auf die neue Gruppe umgehaengt.
Beide Pfade gemessen: vier Arten nacheinander leben alle (624/796/924/1036
Verts), und nach build_group(rebuild=True) ebenfalls unveraendert.
2) Saemlinge zu duenn
Die McMahon-Skalierung macht duennstaemmige Arten am Setzling zu Draehten:
Birke 0.6 cm Fussradius gegen 1.9 der Eiche - dreimal duenner, waehrend der
Unterschied beim Altbaum nur 1.2x betraegt. Die Regel gilt fuer die Statik
ausgewachsener Baeume; ein Saemling ist eine Pflanze, kein Balken.
SEEDLING_MIN_RADIUS + SEEDLING_MIN_FLARE heben die duennen Arten an, ohne
die dicken anzufassen. Danach liegen alle bei 2.8 cm.
test_proportionen laesst die McMahon-Abweichung genau dort zu, wo der Boden
greift, und prueft dass sie nicht weiter geht - die Regel bleibt sonst scharf.
23 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Zwei Befunde von der Spielseite.
1) Dichte-Kompensation ueberschoss preset-abhaengig
Die Eichung am Standardbaum (11 Cards / 486 Tris) kam auf der Eiche als
1008 Tris an. Ursache ist strukturell: "Dichte" ist Punkte pro m2
Zweigflaeche, und die verteilt sich je Preset voellig anders. Jeder
Konstanten-Satz haette fuer den naechsten Baum neu geeicht werden muessen.
Strukturwechsel wie vorgeschlagen: in LEAF_STUFEN steht jetzt die
ZIEL-STUECKZAHL (S1 10, S2 40, S3 120, S4 = volle Dichte), und der Generator
regelt die Dichte per Bisektion dagegen ein. Der Seed wird dabei nicht
angefasst - gleicher Baum und Seed ergeben dieselbe Verteilung.
Gemessen ueber vier Presets (Ziel 10 / 40 / 120):
baum 9 41 104 eiche 10 43 138
birke 9 36 136 tanne 9 38 125
Die Eiche liegt bei S1 jetzt bei 576 Tris statt 1008.
Der Test prueft die Anzahl DIREKT, statt ueber Dichte x Anteil x Flaeche zu
rechnen - genau der Punkt des Vorschlags.
2) Baum stand "etwas in der Luft"
Der Export-Ursprung kam aus der Gesamt-Bbox inklusive Blatt-Cards. Eine
einzige tief haengende Card hebt damit den ganzen Baum an. Jetzt kommt er aus
der STAMM-Geometrie (Slot 0). Gemessen an der Eiche: Stamm-min.Z 0.000 auf
allen vier Stufen, waehrend die Gesamtbox bei S1 auf -0.106 liegt - das waren
die 10 cm, um die er zu hoch stand.
Beim Einbauen selbst verursacht und behoben: eine abgebrochene Befehlskette
liess die Operator-Verdrahtung aus, wodurch die Dichte mit der ZIEL-ANZAHL
multipliziert wurde (170 x 40) - 732 Cards statt 40. Faellt sofort auf, wenn man
die Zahlen anschaut, statt den Durchlauf fuer erfolgreich zu halten.
23 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Befund aus der Turnhalle: die Setzlings-Blaetter verteilen sich ueber die ganze
Stammhoehe, es entsteht eine belaubte Saeule statt einer Krone. Nachgemessen:
44 % der Cards sassen unter 40 % der Baumhoehe, die tiefste bei 6 %.
Der Radius-Filter kann das nicht loesen - er trennt duenn von dick, aber ein
junger Stamm ist UEBERALL duenn. Also ein zweiter Filter ueber die Hoehe: Laub
erst ab dem Kronenansatz, als Anteil der Baumhoehe. Die Schwelle kommt aus der
Bounding Box des Baums, nicht als Meterwert - fest waere sie beim Setzling die
halbe Pflanze und beim Altbaum wirkungslos.
Kronenansatz je Stufe (LEAF_STUFEN): S1 40 %, S2 35 %, S3 30 %, S4 25 %.
unter Ansatz tiefste Card
vorher nachher vorher nachher
S1 44 % 0 % 6 % 46 %
S2 32 % 0 % 24 % 36 %
S3 9 % 0 % 31 % 34 %
S4 3 % 0 % 34 % 34 % (unveraendert)
Beim Altbaum ist der Filter praktisch ein Sicherheitsnetz - dort sitzt ohnehin
nichts tief, genau wie gemeldet.
Dichte von S1/S2 nachgezogen: der Filter nimmt dem Setzling sonst die Haelfte
der Cards (9 -> 4), weil dessen Laub vorher ueber die ganze Stammhoehe verteilt
war. Jetzt 11 Cards bei S1, und 486 Tris gegen 800 Budget.
23 Tests bestehen (Suite zweimal durchlaufen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Drei Befunde aus der Turnhalle abgearbeitet.
1) Deckung PRO STUFE statt globaler Formel
Die alte Rechnung (Dichte durch faktor^2) hielt den Setzling vor der
Kahlheit, gab ihm aber die Deckung eines Altbaums. Jetzt Tabelle
LEAF_STUFEN. S4 traegt die volle Dichte 170, S2 liegt 15 % darunter, S1
deutlich. Der Dichte-Anteil bei S1/S2 sieht hoch aus - "Dichte" ist Punkte
pro m2 ZWEIGFLAECHE, und die waechst ueber die Stufen dramatisch. Was zaehlt
ist die Anzahl: 17 / 43 / 67 / 130 Cards, Kante 0.19 / 0.29 / 0.37 / 0.45.
Budget S3/S4 auf 4300 (die Spielseite hebt ASSETS.md nach dem 170er-Export
entsprechend an).
2) Radius-Filter skaliert mit dem Wachstum (der S3-Befund)
Der Filter trennt duenne Zweige von dickem Geaest - aber mit starren 0.04 m
greift er bei jungen Baeumen nicht: gemessen sassen bei S2 81 % der Cards am
Stamm, bei S3 58 %. Jetzt 48 bzw. 52 %.
Dabei eine eigene Fehldeutung korrigiert: bei S1 bleiben ~88 % am Stamm, und
das ist KEIN Defekt. Nachgemessen ist die zulaessige Flaeche dort fuer jeden
Schwellwert identisch (0.013 m2) - der Saemling hat kein dickes Geaest, an
dem sich etwas trennen liesse. Blaetter am Stiel sind bei einem Saemling der
Normalfall. Ein erster Sweep hatte mich in die Irre gefuehrt, weil ich
growth_t=0 auf einen AUSGEWACHSENEN Baum gesetzt hatte - der hat die volle
Zweigflaeche und verhaelt sich voellig anders als ein echter Setzling.
3) LOD-Reduktion als TEILSET der LOD0-Cards
Bisher wurde je Stufe neu gestreut - die Cards sassen an anderen Stellen und
die Silhouette sprang beim LOD-Wechsel um. Jetzt wird ausgeduennt: jede
verbleibende Card liegt genau dort, wo sie in LOD0 schon war, die
Ueberlebenden werden groesser. Gearbeitet wird auf zusammenhaengenden
INSELN, nicht auf Faces - eine Card muss ganz bleiben oder ganz verschwinden.
Auswahl ist seed-stabil.
Gemessen am reimportierten FBX: 260 / 156 / 78 / 32 Blatt-Faces, und 100 %
der Cards auf LOD1-3 sitzen auf einer LOD0-Position. Der Versatz zu LOD0 ist
dabei kleiner geworden als beim Neustreuen.
23 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Fehler: _origin_bottom_center backt zuerst die Weltmatrix ins Mesh und wendet
DANN die Zentrierung an - zurueck gibt es aber nur die Zentrierung. Den Stufen
1-3 wurde nur diese aufgedrueckt, ihre Weltmatrix blieb ungebacken. Ergebnis:
sie landeten bei MINUS der Standposition. Gemeldet fuer einen Baum bei x = 18 m,
dessen LOD1-3 bei x = -1894 cm sassen - exakt die Standposition, in Zentimetern
wegen FBX_SCALE_ALL. Jetzt backt jede Stufe erst ihre EIGENE Weltmatrix, dann
kommt die gemeinsame Zentrierung aus LOD0.
Warum der Test das nicht gefunden hat: er baute den Baum am URSPRUNG. Dort ist
minus null eben null. Der Baum steht jetzt bewusst bei (18, -7.5), und je Stufe
wird die X/Y-Mitte im reimportierten FBX gemessen - an derselben Stelle wie die
Radialitaets-Pruefung.
Gegenprobe gemacht: mit zurueckgedrehtem Fix meldet der Test LOD1-3 bei
-17.87/7.46, also exakt minus der Standposition, und faellt mit 6 Fehlern durch.
Mit Fix liegen alle Stufen bei 0.000-0.135 um den Ursprung.
Ausserdem Dichte 170 -> 150. Grund: mit der REALEN Diamond-Card (6 Tris, nicht
die 2-Tri-Attrappe aus meinen Sweeps) landet die Eiche bei Dichte 170 auf 4206
Tris - 2778 Krone plus 1428 Stamm - und damit ueber dem 4000er-Budget aus
ASSETS.md Teil 6. Die abgenommene Krone (2778) und das dokumentierte Budget
(4000) sind also nicht gleichzeitig haltbar. 150 liegt im abgesegneten
Sweetspot 130-170 und haelt das Budget mit 3816. Wenn der Look bei 170 wichtiger
ist, muesste das Budget auf ~4300 - das ist eine Entscheidung der Spielseite.
Nebenbei: test_leaves hatte leaf_size fest auf 0.22 stehen (alter
Blaettchen-Wert) und pruefte gegen ein fest verdrahtetes 2500er-Budget. Beides
kommt jetzt aus den Einstellungen.
23 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Blatt-Defaults auf die Bueschel-Atlas-Aera umgestellt. Eine Card ist ein ganzer
Zweigbueschel, kein einzelnes Blatt - die alten Werte streuten hunderte winziger
Cards, wo ein paar Dutzend grosse hingehoeren. Werte an einer S4-Eiche in UE
gemessen und abgenommen:
Groesse 0.22 -> 0.85
Dichte 500 -> 170
Max Radius 0.02 -> 0.04 <- der Volumen-Hebel
Kippung 0.5 -> 0.9
Max Radius ist der unscheinbare Held: bei 0.02 trugen nur die aeussersten
Zweigspitzen Laub, die Krone hatte nur Kontur und war innen nackt.
Bueschelgroesse haengt jetzt am Wachstum: make_object merkt growth_t am Objekt
(aus dem Namen zu lesen waere bruechig), der Blattwerk-Operator skaliert die
Cards damit. Gemessen ueber vier Stufen: Card-Kante 0.19/0.28/0.37/0.45.
Falle dabei: "Dichte" ist Punkte pro m2 Zweigflaeche, und ein Setzling hat davon
fast keine - bei Stufe 1 kamen exakt NULL Cards heraus, der Setzling stand kahl
da. Da die Bueschel um denselben Faktor kleiner sind, deckt jeder nur faktor^2
der Flaeche; die Dichte gegenlaeufig anzuheben haelt die Blattdeckung gleich.
Tri-Budget PRO STUFE (ASSETS.md Teil 6): S1 <= 800, S2 <= 1200, S3/S4 <= 4000.
Bewusst Stufen und keine Interpolation; die Schwellen greifen auch bei drei
Stufen richtig (t = 0 / 0.5 / 1.0). Gemessen 494 / 878 / 1032 / 1396 - alle im
Rahmen.
WICHTIGSTE FALLE, von der UE-Seite gemeldet und hier nachgestellt:
md[socket] = wert loest KEINE Neuauswertung des GN-Modifiers aus. Die
Blattebene blieb bei 118 Faces stehen, obwohl die Dichte von 90 auf 400
geschrieben war - auch view_layer.update() half nicht, erst ein
show_viewport-Toggle. Der Knopf-Weg funktionierte bisher nur ZUFAELLIG, weil
make_leaves jedes Mal auch die Objekt-Zeiger neu schreibt und das Aendern eines
ID-Zeigers die Depsgraph-Beziehungen umbaut. Wer das spaeter optimiert ("nur
geaenderte Werte schreiben"), haette den Fehler still zurueck.
_modifier_anstossen() macht es jetzt explizit - in make_leaves UND make_object.
Nebenbei: der Variantentest rundete Card-Flaechen auf 5 Stellen; seit die
Kippung bei 0.9 steht streuen sie in der sechsten und eine einzige Card-Sorte
zerfiel in vier Eimer.
Neu: tests/test_blatt_bueschel.py. 23 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Punkt 5 - LOD-Kette fuer den Stand-Baum
Haken "LOD-Kette erzeugen" liefert <Name>_LODGroup.fbx mit _LOD0..3 unter
einem fbx_type=LodGroup-Empty, wie die Fels-Pipeline. NUR der Stand-Baum -
die Faell-Teile leben Sekunden als Physik-Actor, dort reicht LOD0.
Blatt-Reduktion ueber die DICHTE, nicht ueber Decimate: eine Card besteht aus
zwei Dreiecken und laesst sich nicht vereinfachen, man muss weniger davon
setzen. Die verbleibenden werden groesser, damit die Krone nicht ausduennt.
LOD0 578 Rinde / 170 Blatt / 1306 Tris
LOD1 477 / 118 / 912
LOD2 364 / 66 / 575
LOD3 221 / 28 / 302 (16 % der Cards von LOD0)
Kugel-Normalen auf JEDER Stufe gemessen, nicht nur LOD0 - LOD1-3 haben eine
eigene Card-Verteilung. Am reimportierten FBX: 100 % radial auf allen vier.
Zwei Reihenfolge-Sachen: das Rinden-Decimate laeuft VOR dem Verschmelzen,
danach wuerde es die Blatt-Cards mit einschmelzen. Und der Ursprung kommt aus
LOD0 (Unreal platziert danach); alle Stufen werden um denselben Betrag
verschoben, sonst springt der Baum beim LOD-Wechsel.
Punkt 6 - Aufraeumen und Pruefen
Blatt-Streuung ueber alle neun Presets nachgemessen. Der Max-Radius-Filter
arbeitet richtig: 0-22 % der Cards landen am Stamm (meist unter 9 %), und
alle Presets bleiben unter dem 2500-Tri-Budget (Maximum weide 2246).
Messfalle, die ich dabei selbst produziert habe: zuerst hatte ich den Anteil
der VERTICES unter der Radius-Schwelle gemessen - beim Busch 95 %, sah nach
einem Problem aus. Das misst aber die Vertex-Verteilung, nicht wo Blaetter
landen; ein Busch besteht fast nur aus duennen Zweigen. Die richtige Frage
beantwortet erst ast_id.
Der Kaktus erzeugt regulaer 0 Cards (kein Ast duenner als Max Radius, botanisch
richtig). Das lief still durch und man stand vor einer leeren _Leaf-Ebene -
jetzt sagt der Operator es und nennt den Regler beim Namen.
Panels: das Export-Panel trug Stand-Baum, LODs und Faell-Teile in einem
Kasten. Die Teile haben jetzt "5 - Faell-Teile" fuer sich.
Neu: tests/test_baum_lod.py. 22 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Knopf "Faell-Teile exportieren": Stamm in 2-3 Segmente, jeder Ast als eigenes
Teil SAMT seinen Sub-Aesten und Blatt-Cards, dazu <Name>_Pieces_All.fbx mit
gemeinsamem Ursprung. Je Teil zwei Material-Slots, Pivot am Massenmittelpunkt,
eigene UCX-Huelle.
Die Ast-Zugehoerigkeit ist ein ATTRIBUT, keine Schaetzung - wie von der
UE-Seite vorgeschlagen. Der Generator legt "ast_id" an den Astpunkten ab
(0 = Stamm, 1..N = Aeste). Sub-Aeste erben die ID ihres Astes automatisch, weil
sie aus Punkten auf dessen Kurve entstehen; nachgemessen: bei Sub Count 0 hat
jeder Ast 28 Verts, bei 3 dann 64, der Stamm bleibt konstant bei 156. Beim
Blatt-Streuen wird ast_id am Punkt abgegriffen und auf die Card gespeichert.
Damit ist die Zuordnung exakt nachzaehlbar, und genau das prueft der Test:
Summe der Cards ueber alle Teile == Cards des Stand-Baums. 170 = 170.
Die Falle, die diese Bilanz aufgedeckt hat: die Z-Schnitte am Stamm zerschnitten
anfangs auch Blatt-Cards. Aus einer wurden zwei, die Bilanz stand auf 178 gegen
170 - und die Atlas-UVs der Haelften waeren kaputt gewesen. Eine Card ist ein
unteilbares Billboard; sie wandert jetzt als GANZES in das Segment, in dem ihre
Inselmitte liegt. Nur die Rinde wird geschnitten, ihre Schlagflaechen werden
gedeckelt.
Massenmittelpunkt flaechengewichtet statt Vertex-Mittelwert: wo das Mesh dicht
tesselliert ist (Astansatz), wuerde der Mittelwert den Pivot dorthin ziehen und
das Teil torkelte beim Fallen.
Alles am REIMPORTIERTEN FBX gemessen: 12 Teile (3 Stamm, 9 Ast), UCX 18-32
Verts im Budget, Pivot maximal 16 mm vom Schwerpunkt, 0 non-manifold Kanten,
Gesamtdatei 5.41 m hoch - also volle Baumhoehe und deckungsgleich
rekonstruierbar.
Nebenbei: _deselect fiel ueber None-Eintraege in der Objektliste, die beim
Entfernen von Objekten zwischen den Teilen staendig auftreten.
Neu: tests/test_faell_teile.py. 21 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
"Leaf Card" kann jetzt eine COLLECTION sein: je Blattpunkt wird zufaellig eine
Card gezogen (Pick Instance, seed-stabil). Damit legt der Nutzer 4-6
Diamond-Cards mit unterschiedlichen Atlas-UVs an und die Krone mischt sie.
Rueckwaertskompatibel - ein einzelnes Objekt geht weiter, die Sammlung hat
Vorrang.
Umsetzung: Collection Info mit Separate Children (sonst kaeme die Sammlung als
ein Klumpen an und Pick Instance haette nichts zum Auswaehlen), Geometry-Switch
zwischen Einzel- und Sammlungspfad, Instanz-Index aus einem Random Value, dessen
Obergrenze aus der TATSAECHLICHEN Anzahl kommt - eine feste Obergrenze wuerde
bei weniger Cards Luecken erzeugen. Geometry Nodes kann einen leeren
Collection-Zeiger nicht selbst pruefen, deshalb setzt make_leaves einen
"Use Collection"-Schalter.
Beweisfuehrung im Test: die Zufalls-Groesse wird ABGESCHALTET, dann kommt jede
Groessenabweichung nur von der Card-Variante und die Anzahl verschiedener
Face-Flaechen ist ein exakter Zaehler. Gemessen: Einzel-Card 2 Flaechen (ein
Card-Paar), Sammlung mit 4 Cards 10 Flaechen - alle Varianten kommen vor.
Gleicher Seed identisch, anderer Seed anders.
Nebenbei: die Vorpruefung des Blattwerk-Operators war eine zusammengesetzte
Bedingung, die bei gesetzter Sammlung ohne Einzel-Card auf None zugriff.
Neu: tests/test_blatt_varianten.py. 20 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Punkt 1 - "Spielfertig exportieren"
Stamm und _Leaf-Ebene werden zu EINEM Mesh mit zwei Material-Slots
verschmolzen (Slot 0 = M_Bark, Slot 1 = M_Foliage). Die getrennten Objekte
im Blend bleiben die Arbeitsebene - verschmolzen wird nur eine Export-Kopie.
Ursprung Bbox-Unterseite Mitte und FBX-Einstellungen wie in der
Fels-Pipeline (use_selection, FBX_SCALE_ALL).
Punkt 2 - Kugel-Normalen auf die Blatt-Cards
Alle Blatt-Normalen zeigen radial vom Kronen-Schwerpunkt nach aussen, damit
die Krone als EIN weiches Volumen liest statt als Haufen flacher Bleche.
Der Schwerpunkt wird nur aus den BLATT-Faces gebildet - der Stamm wuerde die
Mitte nach unten ziehen und die Kugel verkippen.
Bewusst direkt ueber normals_split_custom_set statt ueber den
Normal-Edit-Modifier: der Modifier muesste vor dem Export angewendet werden,
und angewendete Modifier plus Custom Normals ist genau die Kombination, bei
der der FBX-Export gerne flachbuegelt. Am REIMPORTIERTEN FBX gemessen:
mittlere Radialitaet 1.000, 100 % der 510 Blatt-Loops ueber 0.8. Gegenprobe
Rinde 0.043 - die bleibt unangetastet.
Drei Fallen unterwegs:
- Ueber bmesh.from_mesh zusammenfuegen haengt die Geometrie zwar an, wirft
aber die MATERIAL-INDIZES weg: danach lagen alle 748 Faces auf Index 0,
Blaetter und Rinde ununterscheidbar. Blenders join fuehrt die Slot-Listen
zusammen und rechnet die Indizes korrekt um.
- join loescht das zweite Objekt; jede gehaltene Referenz darauf ist danach
tot. Die Aufraeumliste fuehrt deshalb NAMEN statt Objekte.
- Die Export-Kopie muss exakt so heissen wie der Baum (Unreal leitet den
Asset-Namen davon ab). Solange das Original den Namen haelt, haengt Blender
".001" an - Original wird fuer die Exportdauer beiseite benannt, wie bei den
Felsen.
Neu: tests/test_baum_export.py misst die Normalen im EXPORTIERTEN FBX, nicht
am Szenenobjekt - nur so faellt ein plattgebuegelter Custom-Normal auf.
19 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Drei gemeldete Probleme - alle bestaetigt, Ursachen gemessen statt geraten.
1) Palme sah "extrem komisch" aus
Gemessen: Kronenradius/Hoehe 0.11 - die Wedel klebten als Mop-Kopf am
Stamm. Zielwert aus zwei unabhaengigen Quellen, die sich decken:
tree-gen palm.py (Weber&Penn) setzt Wedellaenge = 0.3 x Stamm, die
TreeIt-Referenzpalme kommt auf 3.3 m bei 4.33 m = 0.38.
Jetzt 0.30. Dazu der Winkel: tree-gen gibt down_angle 60 + curve 40 an,
also schraeg raus und ueberbiegen. Mit Branch Up 0 allein standen die
Wedel als gerade Antennenspeichen ab; mit Up 0.35 / Droop 1.2 steigen sie
gemessen 1.1 m ueber den Ansatz und kippen dann ab.
2) Busch sah aus wie ein Baum
Gemessen: 1.81 m hoch bei 0.84 m Breite (B/H 0.46), durchgehender Stamm,
Aeste erst ab 15 %, Wurzelanlauf wie beim Baum. Das IST ein Baeumchen.
Botanisch ist der Unterschied nicht die Groesse, sondern die Architektur:
mehrere Stiele ab Boden, kein Leittrieb, gemessen nach Hoehe UND Breite.
Jetzt kurzer Stumpf + Aeste ab Boden: 1.20 m hoch, 2.0 m breit (B/H 1.6).
3) Kleinste Wachstumsstufe sah komisch aus / "nur runterskaliert"
Gemessen: der Setzling war relativ zu seiner Hoehe 2.4x DICKER als der
Altbaum (r/H 0.025 gegen 0.0104), weil Trunk Radius mit 0.30 skalierte,
die Hoehe aber mit 0.16. Botanisch gilt die elastische Aehnlichkeit nach
McMahon: Hoehe ~ Durchmesser^(2/3), also Faktor 0.16^1.5 = 0.064.
Dazu behielt jeder Setzling den vollen Wurzelanlauf -> Trichterfuss.
Neu ausserdem: Aeste schrumpfen mit der Hoehe statt langsamer, sitzen
tiefer (Aufasten kommt erst mit dem Alter) und haengen weniger.
Nicht jede Pflanze waechst wie ein Laubbaum -> GROWTH_OVERRIDES:
Palme kein Dickenwachstum, erst Durchmesser dann Hoehe (UF/IFAS ENH1212:
"its diameter is fixed for life") -> Setzling ist ein kurzer Stumpf
Kaktus Sukkulent, gleiche Logik, und OHNE Arme: Saguaros bilden die erst
mit 50-70 Jahren bei rund 2 m Hoehe (NPS)
Weide haengt erst mit langen Zweigen; sonst reichten sie 0.27 m unter
den Stammfuss und das Asset waere in UE geschwebt
Zwei Bugs fielen dabei auf:
- Branch Count = 0 schaltete die Aeste NICHT ab - dieselbe Falle wie damals
bei Sub Count (Curve to Points klemmt Count auf min. 1). Fuer die Sub-Ebene
gab es laengst einen Geometry-Switch, fuer die Hauptaeste nicht.
- Im Busch-Preset stand "Branch Count" zweimal im selben Dict; der zweite
Eintrag (10) hat den ersten (14) still ueberschrieben.
Die sieben uebrigen Presets sind unveraendert (gleiche Maße, gleiche Tris).
Neu: tests/test_proportionen.py nagelt die Zielwerte fest. 14 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Panel-Umbau
-----------
Jedes Addon hatte seine Einstellungen als Kette dauerhaft offener Boxen - beim
Rock Generator 15 Stueck, man musste am ganzen Panel vorbeiscrollen, um an den
Erzeugen-Knopf zu kommen. Jetzt steht oben nur, was man bei jedem Asset anfasst
(Vorlage, Name, grosser Erzeugen-Knopf, Zufall), der Rest liegt in nummerierten,
eingeklappten Unter-Panels in der Reihenfolge des Arbeitsablaufs:
Rock Gen 9 Unter-Panels (Benennung ... Textur-Bake)
Tree Gen 4 (Wachstum, Blattwerk, Zusatz-Ebenen, Export)
Grass Gen 4 (Form, Haltung, Batch, Kanal-Belegung)
Asset Utils 5 (war schon so, dient als Vorlage)
Schalter, die ein ganzes Unter-Panel steuern (Vertex-Farben backen,
Wachstums-Stufen), sitzen jetzt als Haekchen im Panel-Kopf - Zustand sichtbar
ohne aufzuklappen.
Gemessen statt geglaubt: test_panels.py registriert alle vier Addons, laesst
jedes Panel zeichnen, prueft Tab-Zugehoerigkeit und Auf-/Zugeklappt-Absicht,
dass jeder angebotene Operator existiert - und vor allem, dass JEDE definierte
Property irgendwo erreichbar bleibt (Zweige wie base_shape='BOX' werden dabei
durchgeschaltet). Ergebnis: 0 von 122 Properties beim Umbau verloren.
Test-Suite
----------
Beim Gegenpruefen kam heraus, dass fuenf Tests still veraltet waren und eine
echte Regression nicht gemeldet haetten:
test_rock_gen suchte Objekte mit Praefix "Rock_" - die heissen seit dem
Benennungssystem "Fels_A_M_01". Fand 0 von 3.
test_base_shapes loeschte am Schleifenanfang ALLE Objekte, auch die eigenen
Kopien aus vorigen Durchlaeufen -> StructRNA removed.
test_ecogame_tree erwartete eine feste Namensliste ohne die spaeter
dazugekommenen _Leaf-Objekte.
test_tree_addon dito, ausserdem Zip-Version 1.22.0 fest verdrahtet.
test_leaves Zip-Version 1.23.0 fest verdrahtet.
Drei Muster vermieden statt nur die Symptome geflickt: neue Objekte ueber die
Differenz vorher/nachher finden statt ueber ein Namens-Praefix, Zips per glob
statt mit fester Version, Zusatz-Ebenen beim Zaehlen herausfiltern.
Neu: run_tests.ps1 faehrt die komplette Suite mit einem Befehl (-Filter fuer
einzelne). Genau das fehlte - deshalb war das Veralten nicht aufgefallen.
13 von 13 Tests bestehen.
Nebenbei
--------
build.ps1 ruft server-generate jetzt mit --html auf (browsbare index.html fuer
statisches Hosting). Nachgemessen und im README festgehalten: zwei Zips
derselben Extension-ID sind KEIN Versions-Archiv - server-generate warnt
("archive found with duplicates ... conflicting blender versions"), mehrere
Versionen einer ID gehen nur bei verschiedenen Blender-Bereichen.
Versionen: Rock 2.13.0, Tree 1.24.0, Grass 1.1.0, Asset Utils 1.1.0
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Blatt-Card waehlen -> wird auf die duennen Zweige gestreut (Filter ueber das
Radius-Attribut des Meshes) und als <Name>_Leaf mit identischem Ursprung abgelegt.
Regler fuer Dichte, Groesse, Streuung, Kippung, Zweig-Schwelle. Der Button meldet
Stamm + Blatt = Summe und warnt bei Ueberschreitung des Tri-Budgets.
Gemessen: Eiche 1428 + Blattwerk 1032 = 2460 von 2500 Tris bei Default-Dichte 150.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aeste kruemmen sich zur Spitze hin zur Senkrechten - als echte Rotation um den
Astansatz, nicht als Z-Versatz. Die Astlaenge bleibt dabei erhalten (gemessen:
+0.08 m Hoehe statt +0.93 m beim alten Droop-Hack). Pro Preset abgestimmt.
Idee aus UE 5.8 Procedural Vegetation / Weber-Penn.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
"Sub Count = 0" schaltete die Sub-Aeste nicht ab (Curve to Points klemmt auf 1) ->
duenne "Nadeln" bei Palme und Kaktus. Jetzt echter Geometry-Switch.
Palme am TreeIt-Referenzbaum ausgemessen: kurze Wedelstiele (0.78 m statt 3.4 m),
Stamm 4.4 m mit dickem Kronenschaft. 854 statt 1784 Tris.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Palmenstamm mit nahezu konstantem Durchmesser (Taper 0.22), glatt geschwollener
Fuss ohne Wurzelbretter, 15 kraeftige Wedelstiele im Bogen statt duenner
haengender Draehte. 1784 von 2500 Tris.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rock Generator 2.5.0:
- "Zufaellig"-Button: wuerfelt Seed und Form-Parameter, "Streuung" steuert die
Abweichung von den aktuellen Werten (0 = nur neuer Seed). Optional werden auch
Basis-Form und Noise-Typ gewuerfelt. Werte werden auf ihre Grenzen geklemmt.
- Skalierung streut jetzt die FORM, nicht die Groesse: nicht-uniform ist Default,
und "Gesamtgroesse konstant halten" normiert das geometrische Mittel auf 1.
Gemessen ueber 6 Rocks: Volumen-Spanne 1.92x -> 1.11x. Wichtig, weil EcoGame
die Groesse zusaetzlich ueber ScaleMin/Max streut.
Tree Generator 1.19.0:
- "Zufaellig"-Button: neuer Seed plus Streuung auf Hoehe, Radius, Biegung,
Ast-Anzahl/-Laenge, Kronenform und Wurzelanlauf. Preset-Charakter bleibt, weil
relativ zu den aktuellen Werten gestreut wird (gemessen: Hoehe 6.65 -> 8.34 m).
- "_Leaf"- und "_Frucht"-Ebenen: leere Objekte mit IDENTISCHEM Ursprung neben dem
Baum (gemessen: Abstand 0.000000), damit die Ebenen in UE deckungsgleich sitzen.
Vier Test-Suiten liegen jetzt unter tests/ statt nur im Scratchpad.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Rock Generator 2.4.0:
- Benennung Fels_<Form>_<Klasse> statt Rock_000 (Praefix/Form/Klasse im Panel,
Klasse S/M/L/XL, optionale Durchnummerierung bei Batches)
- Bake liefert jetzt <name>_albedo und <name>_normal. AO/Cavity wird per Option
MULTIPLIKATIV ins Albedo gebacken (Staerke regelbar) - separate Roughness- und
AO-Paesse sind Default aus, weil Roughness in EcoGame eine Zahl im Master-
Material ist. Gemessen: Albedo-Mittelwert 0.549 -> 0.433 mit AO, Kontrast rauf.
- UV1 Lightmap Default AUS (EcoGame beleuchtet dynamisch)
Tree Generator 1.18.0:
- Benennung <Art>_<Variante>_S<Stufe>, z.B. Birke_01_S1..S4 (statt stage0..3);
Art-Feld und Varianten-Nummer im Panel, Art leer = Preset-Name
- UV1 Lightmap Default AUS
README: Konventionen dokumentiert.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Basisring trifft den TreeIt-Baum jetzt fast exakt (r 0.178 vs 0.179, Unrundheit
1.61 vs 1.60). Lappen zentriert moduliert, damit die Lappentiefe nicht mehr den
mittleren Radius mit anhebt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Zweige waren 70 % so dick wie ihre Aeste (jetzt ~35 %). Eiche und Birke hatten
durch verkettete Replaces vertauschte Ast-Dicken.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aeste waren mit 32 % des Stammradius doppelt zu dick (Referenz: 11-16 %). Das
war die Ursache der groben Astansaetze - nicht fehlende Verschweissung.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Collar-Abfall von Exponent 6 auf 2.5 (bei ~7 Segmenten pro Ast war 6 nur einen
Punkt breit = Widerhaken statt Uebergang). Trunk Radius 0.13 -> 0.085.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Beide Arme laufen flach raus, knicken und steigen parallel zum Stamm, ohne ihn
zu ueberragen (Droop und Hoehe aufeinander abgestimmt). Neu 'Trunk Tip': steuert,
ob der Stamm duenn auslaeuft oder mit stumpfer Kuppe endet.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Crown Taper / Crown Bulge steuern die botanische Huellkurve (kegelfoermig bis
rund) - damit sind Tanne, Eiche, Birke, Weide und toter Baum als Presets
moeglich. Alle neun Presets liegen im Tri-Budget des Projekts.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Stamm rund (8 Seiten), Aeste 4, Zweige 3 - wie im TreeIt-Referenzbaum. Runderer
Stamm bei gleichzeitig ~25% weniger Tris (baum 1368 -> 1032).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 'Detail' skaliert alle Resample-Counts -> zentrale Budget-Stellschraube
- Defaults treffen jetzt das Projekt-Budget (baum 1368, busch 532 Tris)
- 'Root Flare': Wurzelanlauf am Stammfuss, kostet keine Tris
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- 'Branch Collar': Aeste werden an der Basis leicht breiter -> gewachsener
Uebergang zum Stamm, ohne einen einzigen zusaetzlichen Vert
- Stammspitze laeuft duenn aus statt mit flachem Deckel zu enden
- 'Merge'/'Merge Voxel' (Voxel-Remesh) optional, Default AUS: verschmilzt Aeste
organisch, kostet aber die UVs und bis zu 14x Verts (gemessen), duenne Zweige
zerfallen -> fuer Game-Assets nicht empfohlen
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Aeste/Zweige werden per Instanz-Scale an den Radius ihres Elternpunktes gekoppelt
('Input Radius' auf der Punkt-Domain von Instance on Points). Oben am duennen
Stamm sind die Aeste dadurch automatisch kuerzer und duenner statt gleich dick.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sub-Aeste hatten gar keine Biegung -> gerade Staebe. Jetzt nutzen Stamm, Aeste
und Zweige dieselbe Noise-Kruemmung (nach Realize ueber die Weltposition, damit
jeder Zweig anders faellt). Zweige ausserdem duenn + fast gleichmaessig statt
dick-kegelig (das war die eigentliche Dorn-Ursache).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Mindestdicke (Tip Blunt) wirkt jetzt auf Verjuengung*Kuppel statt nur auf die
Kuppel. Duennster Querschnitt 0.8 mm -> 7.5 mm (gemessen).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
- UVMap aus Geometry Nodes (V = Bogenlaenge, U = Umfang*Radius) -> Rinde ueberall
gleich dicht, Regler 'UV Scale'
- 'UV1 Lightmap-UV' beim Modifier-Apply (Parity zum Rock-Generator; aktiver Kanal
wird gesetzt, damit lightmap_pack UV0 nicht ueberschreibt)
- Sub-Aeste enden nicht mehr als Nadeln
- Test prueft jetzt beide UV-Kanaele + world-space-Skalierung
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Ein Extension-Repo kann mehrere Addons ausliefern (server-generate listet jedes
Zip in dist/) -> die bereits eingetragene Blender-URL liefert jetzt Rock UND Tree,
ein 'Check for Updates' aktualisiert beide.
- stylized_tree_generator.py: Panel 'Tree Gen', Presets baum/palme/busch/kaktus,
Wachstums-Stufen (gleicher Seed = dieselbe Baum-Identitaet), Modifier-Apply
- Node-Kern 1:1 aus EcoGame tools/blender_tree_gen.py generiert (keine Abweichung)
- build.ps1 baut jetzt beide Extensions
- Headless getestet: alle 4 Presets, Stufen aufsteigend (504/744/1236/1872), Apply ok
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
