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>
