4cf7097fa30bd132b0017e5449e8e7839fe18e8a
54
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  D4rkst3randClaude Opus 4.8
|
a718476592 |
Tree Gen 1.48.0: Kronen-Huelle, weniger Blaetter, Formband neu geeicht
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
1a1c3a5c59 |
Tree Gen 1.47.0: Hochstamm auf jeder Wachstums-Stufe
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
9f4aad03ea |
Tree Gen 1.46.1: Kronenzylinder mit p90 statt Maximum
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
6ed2257085 |
Tree Gen 1.46.0: Halbkugel-Bueschel, groessere Baeume, Spitzen-Deckung
1) NEUE BAUFORM: Blattwerk als Halbkugel-Cluster
Jeder gestreute Punkt ist jetzt ein Cluster-ZENTRUM, die Cards sitzen auf
der oberen Halbkugel darum herum. Untere Haelfte weggelassen - von unten
sieht man die Krone gegen den Himmel, das waere Overdraw fuer nichts.
Zwei Annahmen kassiert die Messung: GeometryNodeMeshIcoSphere liefert bei
Subdivisions 0 UND 1 dasselbe Ikosaeder, ein Cluster hat SECHS Cards statt
der angenommenen 26. Und die Stufen-Ziele muessen Cluster-Vielfache sein
(26/78/208/390) - S1 stand auf 10, unter der kleinsten Einheit, die Regelung
waere nie konvergiert. S4 ist seither geregelt statt "volle Dichte":
ungeregelt lieferte die Schale 2706 Cards an der Eiche.
ast_id ueberlebt Instanzieren + Realize, an den Cards nachgewiesen.
2) SPITZEN-DECKUNG: zwei echte Ursachen, beide vorher nur vermutet
- Der Kronenansatz-Filter stand auf 25 % der Baumhoehe, die Tanne setzt ihre
Aeste ab 12 % an: bei 5 von 22 Aesten lag das aeussere Fuenftel KOMPLETT
unter dem Filter. Jetzt auf den Branch Start der Art gedeckelt.
- Haengende Spitzen fielen unter den Filter. Jetzt zaehlt der ANSATZ des
Astes (anchor) mit, nicht nur die Punkthoehe.
Ergebnis: Eiche/Baum 100 %, Weide 100/90, Obstbaum 100/93, Tanne 86/86,
Birke 100/72. Die 85-%-Schwelle der Spielseite ist damit erreicht, ohne dass
die Rinden-Ersparnis noetig war.
Die Metrik war zweimal falsch: der Abstand zur Card-MITTE ist zu streng -
eine 0.85-m-Card deckt die Spitze auch aus 0.45 m Abstand, bei 1.9 m
Astlaenge kamen so 24 % heraus, obwohl das Polster genau auf der Spitze sass.
Jetzt zaehlt Deckung, nicht Abstand.
3) GROESSERE BAEUME, proportional skaliert
Eiche 9.3 m, Birke 11.0, Tanne 13.0, Weide 7.0 - Hoehe, Astlaenge und
Stammradius zusammen, sonst wird der Baum eine Stange mit Minikrone. Alle
unter dem 4300er-Deckel; die Birke brauchte eine Card-Deckelung auf 340.
4) Kugel-Kennwert RELATIV, Bbox-Kriterium ersetzt
Die Schalen schieben jede Card in ALLE Richtungen vom Ast weg: die Krone
gewinnt ringsum Breite, in der Hoehe nur oben. Der Obstbaum fiel dadurch von
1.35-1.47 auf 0.95-1.23, ohne dass an seiner Form etwas falsch war.
Zwei Hypothesen sind an der Messung gescheitert, beide klangen plausibel:
den Kappen-Faktor entkoppeln (0.93-1.14 -> 0.95-1.23) und den Kappen-Radius
vergroessern (59-77 % -> 58-75 %). Der Radius waechst in alle Richtungen und
verschiebt das Verhaeltnis deshalb kaum. Was wirkt, ist die Kronenbreite.
Schranke jetzt relativ: hoechstens 65 % des Eichenwerts aus DEMSELBEN Lauf.
Eine neue Konstante haette bei der naechsten Bauform dasselbe Schicksal.
LEAF_CLUSTER_PRESET bleibt trotzdem eine eigene Tabelle - Card-Grobheit und
Polster-Abstand sind zwei verschiedene Fragen.
"Bbox-Mitte == 0" ist raus. Nachgemessen ueber drei Presets und drei Seeds:
Stammachse 0.0000 m in allen neun Faellen, Bbox-Exzentrik 0.08-0.39 m mit
dem Seed streuend, 3-13 % des Kronenradius. Eine Verschiebung traefe den
Stamm mit und waere ueber die Seeds konstant - es ist Kronen-Schieflage.
An seine Stelle tritt der Bounds-Radius, an dem das Culling haengt, geprueft
gegen die Blender-Messung statt gegen eine Konstante.
27 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
5e6b84369f |
UCX bei LOD-Gruppen nach dem MESH-Node benennen (Tree 1.45.0, Rock 2.20.0)
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> |
||
|
D4rkst3randClaude Opus 4.8
|
b5ec4a4bc0 |
Tree Gen 1.44.0: _Pieces_All.fbx steht auf der Stammbasis
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> |
||
|
D4rkst3randClaude Opus 4.8
|
20e8e24322 |
Tree Gen 1.43.0: UCX in _Pieces_All.fbx - und zwei Fehler, die dabei auffielen
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> |
||
|
D4rkst3randClaude Opus 4.8
|
ae7806e082 |
Tree Gen 1.42.0: UCX-Stammhuelle im Spielfertig-Export
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> |
||
|
D4rkst3randClaude Opus 4.8
|
263b8507d8 |
Tree Gen 1.41.0: Obstbaum-Kugelkrone (Lollipop) ueber den Kronenansatz
Zielbild der Spielseite ist der Lollipop der stilisierten Vektor-Illustration. Der Weg dorthin fuehrt NICHT ueber mehr Baumhoehe (4.9 m sind die Ernte-Reichweite), sondern ueber einen tieferen Kronenansatz: 39 % -> 29 %, Stamm 1.9 -> 1.5 m. Die Krone wird dadurch von selbst hoeher (3.8 -> 4.3 m). Dazu Crown Taper 0.15 -> 0.35, Crown Bulge 1.1 -> 1.5, Branch Droop 0.4 -> 0.25. Gemessen ueber alle neun Produktions-Seeds: Kronenansatz 29 %, unten/mitte 0.86-1.01, oben/mitte 0.63-0.74, Kugel 1.35-1.47, Kronenradius 2.00-2.15 m, Deckung 81-103 % der Eiche, Hoehe 4.90 m. Das Messen war schwieriger als das Einstellen; zwei eigene Fehler, beide vor der Abnahme gefunden: 1) Die Kronenbreite je Drittel als MAXIMUM ueber die Card-Punkte zu messen haengt an EINER Card. Unten/mitte sprang je Seed zwischen 0.89 und 1.00 bei stabilem Mittelwert 0.94 - Rauschen, keine Form. Mit dem 90. PERZENTIL wurde es stabil und zeigte sofort etwas anderes: die Krone war unten tatsaechlich am breitesten (1.04), was das Maximum verdeckt hatte. 2) Der Kugel-Kennwert bekam erst die Schranke 0.88 - eine Zahl aus einem Messskript mit anderer Breitendefinition. Mit der Test-Formel liegen die Werte um 1.4, die Schranke haette alles durchgelassen. Zum zweiten Mal dieselbe Falle nach der Deckungs-Schwelle. Deshalb sind jetzt ALLE Referenzformen mit demselben Mass gemessen und stehen als Tabelle im Test (Eiche, Trichter, Haube, Pilz, Kugel). Die Tabelle zeigt auch, was NICHT trennt: der Kugel-Kennwert unterscheidet Kugel und Haube nicht (1.35-1.47 gegen 1.26-1.44) - das tut der Kronenansatz, und der wird geprueft. Die Kugel-Schranke bleibt als zweites Netz gegen Trichter und Pilz drin, mit genau diesem Vermerk. Das Wunschband der Spielseite (u/m 0.85-0.95) ist schmaler als die Streuung von Seed zu Seed (0.86-1.01). Die Schranken kommen deshalb aus der Messung aller Formen, nicht aus dem Band. Gegenproben: Haube 9 Fehler (Kronenansatz), Trichter 37 (alle vier Kriterien). 26 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
d87450a4b8 |
Obstbaum: B/H-Band gilt fuer dieses Preset nicht mehr (Regel festgehalten)
Nur Doku und Test-Kommentare, keine Geometrie-Aenderung - deshalb kein Versionssprung. Die Spielseite hat den Dauerkonflikt aufgeloest: Kronenradius >= 1.80 schlaegt B/H <= 0.75. Zweimal war die Abwaegung dieselbe (Kronenradius traegt die Frucht-Streuung), beim zweiten Mal wurde daraus eine Regel statt einer Einzelfallentscheidung. Die gemessenen 0.77-0.82 sind der Preis der Frucht-Tragflaeche. Sachlich richtig ist das auch deshalb, weil B/H die Form gar nicht absichert: es haette sowohl den Trichter (oben/mitte 1.07) als auch die Pilzform (unten/mitte 1.17) durchgelassen. Das Breitenprofil trennt beide sauber. Festgehalten in test_obstbaum.py (Kopf + Kommentarblock), im Preset selbst und in der README - damit die Abwaegung nicht ein drittes Mal von vorn gefuehrt wird. Im Preset stehen jetzt die Neun-Seed-Werte statt der alten Drei-Seed-Zahlen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
0b6f0deff9 |
Tree Gen 1.40.0: Obstbaum-Krone schliesst sich oben (Trichter behoben)
Der Baum erfuellte Kronenradius, Deckung, Kronenansatz und Tri-Budget - und sah trotzdem falsch aus. Sichtbar wurde es erst am BREITENPROFIL der Krone in Dritteln (unten/mitte/oben, Messung der Spielseite nachgestellt): Eiche 3.0 / 2.8 / 2.6 oben/mitte 0.90 (liest sich als Baum) Obstbaum 3.3 / 4.5 / 4.7 oben/mitte 1.07 (Trichter) Kein einzelner Regler hat das geloest: Crown Taper (-0.10 bis +0.50), Branch Droop (0.6-1.2), Crown Bulge (1.0-1.8) und Attraction Up einzeln durchgefahren liessen oben/mitte bei rund 1.0 stehen. Der Grund ist strukturell: die Kronenform folgt nicht der Astlaenge je Hoehe, sondern dem WEG DER ASTSPITZEN. Solange die Aeste aufwaerts schwingen, landet das aeusserste Laub oben. Loesung ist eine andere Bauform, kein Feintuning - kurze Aeste an einem hohen Stamm statt langer Aeste an einem kurzen: Height 3.8 -> 4.9, Branch Length 2.55 -> 1.25, Branch Start 0.52 -> 0.40, Attraction Up +0.40 -> -0.05, Crown Taper -0.30 -> +0.15, Crown Bulge 0.60 -> 1.10, Branch Droop 0.35 -> 0.40. Ueber alle neun Produktions-Seeds: oben/mitte 0.63-0.84, Kronenradius 1.88-2.01 m, Deckung 100-134 % der Eiche, 3752-4166 Tris, Ansatz 39 %. Beim Einregeln kippte die Form zwischendurch in eine PILZform (unten am breitesten) - deshalb steht das Profil jetzt als Test da. test_obstbaum prueft oben/mitte <= 0.85. Gegenprobe mit den 1.39er Werten: neun Fehler bei 0.98-1.11. B/H liegt jetzt bei 0.77-0.82 (Band der Spielseite 0.55-0.75). Bleibt bewusst ungeprueft, wie beim Kronenradius entschieden: die Vorgaben Kronenradius >= 1.80 und B/H <= 0.75 sind bei 4-5 m Hoehe nur im Mittel gleichzeitig erfuellbar. 26 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
5a43ead8d1 |
Tree Gen 1.39.0: Kronenfuellung des Obstbaums - Flaeche statt Card-Zahl
Der Obstbaum las sich in der Engine als einzelne belaubte Ast-Schlaeuche mit Himmel dazwischen. Die Card-Zahl erklaert das nicht; die Blattflaeche pro Kronenvolumen tut es: Eiche (schliesst) 444 Cards, Krone 18.9 m3 -> 24.6 m2/m3 Obstbaum vorher 399 Cards, Krone 36.2 m3 -> 11.4 m2/m3 Fast doppeltes Volumen bei gleicher Card-Zahl. Der Vorschlag der Spielseite - mehr und laengere Sub-Aeste als Fuellwerk - wurde durchgemessen und VERWORFEN: Sub Count 5/7, Sub Length 1.0/1.3, Sub Start 0.20/0.30, Branch Count 12/14 bewegten den Fuellgrad um hoechstens 7 Punkte und trieben die Dreiecke auf 4310-5162. Strukturell: neue Zweige wachsen aus denselben wenigen Hauptaesten und vergroessern dabei die Krone, das Volumen waechst also mit. Ebenfalls verworfen: mehr Cards (Ziel 740 = 5426 Tris, 26 % ueber Budget, und der Fuellgrad stieg nur auf 75 %). Und eine kleinere Krone: Branch Length 2.35 sah ueber drei Seeds mit 1.83 m gut aus, im Neun-Seed-Test fielen SECHS Seeds unter die 1.80 m der Frucht-Streuung. Was wirkt, ist die Card-GROESSE (neu: LEAF_SIZE_PRESET, Faktor je Preset). Sie kostet kein Dreieck, weil die Card-Zahl gedeckelt ist - aber OVERDRAW, und der ist bei Bueschel-Cards der eigentliche Engpass. Deshalb der maessige Faktor 1.47: Deckung von 46 auf 87-114 % der Eiche, Card-Flaeche 414 -> 893 m2, bei 3697 statt 3714 Tris. Faktor 1.71 brachte 79 % Fuellgrad bei 2.7-facher Flaeche - das waere eine Overdraw-Entscheidung der Spielseite. test_obstbaum prueft die Deckung jetzt mit, und zwar gegen die im SELBEN Lauf gemessene Eiche statt gegen eine feste Zahl: die Deckung haengt an der Card-Flaeche, eine 6-Tri-Card bringt das Dreifache einer flachen Raute. Der erste Anlauf des Checks ist genau daran gescheitert. Gegenprobe gefahren: mit Faktor 1.0 meldet der Test 9 Fehler bei 42-54 % der Eiche. 26 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
9bcb80765a |
Tree Gen 1.38.0: ein Weg zum Blattwerk, generischer Baum entsaeult
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> |
||
|
D4rkst3randClaude Opus 4.8
|
4aaf3231ef |
Tree Gen 1.37.0: Obstbaum-Preset + Card-Groesse gegen die Baumhoehe
1) Neues Preset "obstbaum" (Apfel/Kirsche/Birne) Eigenes Preset statt Umbau von "baum": der wird anderswo verwendet, und ein Hochstamm ist keine Standard-Silhouette. Der Zweck ist funktional, nicht bloss optisch: die Frucht-Streuung setzt Fruechte auf die AUSSENHAUT der Krone. Am generischen baum war der Kronenradius 0.78 m bei 1.28 m Card-Diagonale - die Cards waren groesser als die Krone, es gab keine Haut. Proportion belegt (Hochstamm): Kronenansatz 180-220 cm, Krone selbst 3-4 m. Ergibt 4.8 m Gesamthoehe und knapp 40 % Ansatz - genau das Band der Spielseite. Gemessen ueber alle NEUN Seeds der Spielseite: Hoehe 4.91-5.12 m, Kronenradius 1.83-2.05 m, Ansatz 38-40 %, Kronenradius/Card 2.15-2.42, 3560-3824 Tris. Deckelung auf 420 Cards ueber LEAF_STUFEN_PRESET, sonst 4304-4400 Tris. Zwei Fallen, gemessen statt vermutet: "Height" ist die STAMMlaenge, nicht die Baumhoehe (Height 4.8 ergab 5.4-6.2 m), und der Kronenansatz zaehlt gegen die GESAMThoehe (Branch Start 0.37 ergab 29 %). test_obstbaum.py prueft die funktionale Bedingung ueber alle neun Seeds. B/H ist BEWUSST nicht hart geprueft: B/H 0.55-0.75 und Kronenradius >= 1.80 bei 4-5 m Hoehe lassen zusammen nur ein 4 % breites Fenster, waehrend die Streuung von Seed zu Seed 12 % betraegt. Vorrang hat der Kronenradius. 2) Card-Groesse misst sich an der BAUMHOEHE Mit 0.45/0.63/0.82/1.00 schrumpfte die Card um Faktor 2.2, der Baum um 6.2. Gemessen an der Birke 27/14/11/9 % der Baumhoehe, an der Eiche 33 gegen 11 - der Setzling trug relativ dreimal so grosses Laub wie der Altbaum. Jetzt 0.24/0.46/0.75/1.00: 14/10/10/9 %. Nicht ganz flach, ein junger Baum traegt seine Bueschel relativ groeber; auf Altbaum-Proportion gezwungen (0.18) wird er kahl. test_blatt_bueschel prueft die Spreizung jetzt direkt und ueber Inseln statt ueber Face-Index-Paare. HINWEIS an die Spielseite: der Addon-Pfad skaliert S1 auf 0.45 der S4-Groesse, auf BEIDEN Wegen nachgemessen (Einzelcard und Sammlung). Die dort gemessenen 0.76 entstehen also erst danach - bitte growth_t am S1-Objekt direkt vor treegen_leaves pruefen, das muss 0.0 sein. 25 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
499d507e28 |
Tree Gen 1.36.0: Ursprung an der Stammbasis, Weide gedeckelt, Birke ueberarbeitet
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> |
||
|
D4rkst3randClaude Opus 4.8
|
fa7067d42e |
Tree Gen 1.35.0: Node-Gruppen-Waechter + Mindestradius fuer Saemlinge
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> |
||
|
D4rkst3randClaude Opus 4.8
|
1b833bf44a |
Tree Gen 1.34.0: Ziel-Cardzahl statt Dichte-Konstanten + Ursprung aus dem Stamm
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
d02562fb53 |
Tree Gen 1.33.0: Hoehen-Filter - der Setzling bekommt einen freien Fuss
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
d170e4067f |
Tree Gen 1.32.0: Deckung pro Stufe, mitwachsender Radius-Filter, LOD als Teilset
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> |
||
|
D4rkst3randClaude Opus 4.8
|
2c339b5d0c |
Tree Gen 1.31.0: LOD1-3 trugen die Standposition mit (aus UE gemeldet)
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> |
||
|
D4rkst3randClaude Opus 4.8
|
b1fdad8106 |
Tree Gen 1.30.0: Bueschel-Defaults, Wachstums-Kopplung, Stufen-Budget
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
914a1af967 |
Tree Gen 1.29.0: LOD-Kette (Punkt 5) + Aufraeumen/Pruefen (Punkt 6)
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
95ddcb40b3 |
Tree Gen 1.28.0: Faell-Teile mit exakter Ast-Zuordnung (Punkt 4)
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> |
||
|
D4rkst3randClaude Opus 4.8
|
29899c0aa0 |
Tree Gen 1.27.0: Blatt-Cards aus einer Collection (Punkt 3)
"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> |
||
|
D4rkst3randClaude Opus 4.8
|
74df6dfa1b |
Rock Gen 2.19.0: Schnellstart-Sorten + Dissolve als Bereich
Weniger einstellen muessen: oben im Panel Sorte waehlen, Haken druecken, erzeugen. Die neun Unter-Panels bleiben fuer den Feinschliff. Findling rund, weiche Kanten ~1160 V / ~2320 Tris Platte flach, liegt satt auf ~670 V / ~1340 Tris Kantig Bevel + Weighted Normal ~350 V / ~690 Tris Erzbrocken dicht genug fuer die Maske ~1280 V / ~2560 Tris, Slot M_Rock_Ore dissolve_angle ist jetzt ein BEREICH statt eines festen Werts - direkt aus der Rueckmeldung "hab ich immer auf 17-25 je nach Stein". Je Stein wird einer gezogen; gemessen an sechs Findlingen bei 17-25 Grad: 1936-2928 Tris. Beide Regler gleich setzen = fester Winkel wie frueher. Zwei Sachen fielen beim Messen auf: 1) Der Dissolve-Winkel frisst deutlich Geometrie. Derselbe dichte Satz liefert bei niedrigem Standardwinkel ~2700 Tris, bei 17-25 Grad nur noch ~1030 und faellt damit unter ORE_MIN_VERTS - das Erz-Set haette seine EIGENE Warnung ausgeloest, sobald vorher eine Sorte mit hohem Winkel gewaehlt war. Der Bereich gehoert deshalb mit in DENSE_PRESET. Ueber vier Seeds und beide Groessenklassen nachgemessen: 0.70/0.92 haelt den Worst Case bei 847 Verts. 2) Erz-Dichte und Tri-Fenster kollidieren. Die Maske braucht ~800 Verts auch beim kleinen S-Brocken, das treibt einen M-Stein auf ~3400 Tris - ueber das Fenster 1500-3000. Deshalb entkoppelt: normale Sorten leichter (0.40/0.80), Erzbrocken knapper (0.45/0.82), das S+M-SET dichter (0.70/0.92), weil dort die kleinen Brocken die Untergrenze setzen. Nebenbei gefunden und behoben: der erzwungene Ursprung wurde aus der GEMEINSAMEN Bbox aller LOD-Stufen berechnet. Eine stark dezimierte Stufe kann tiefer reichen als LOD0 - dann sass LOD0 sieben Zentimeter ueber dem Pivot und der Stein haette in UE geschwebt. Unreal platziert nach LOD0, also gibt LOD0 jetzt den Ursprung vor. Neu: tests/test_schnellstart.py. 18 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
f996832d75 |
Rock Gen 2.18.0: Material-Slots, Praefix Rock, Warnung bei zu grobem Erz-Mesh
Drei Rueckmeldungen von der Spielseite abgearbeitet. 1) Fehlende Material-Slots "Material zuweisen" stand auf Standard AUS, deshalb kamen alle Proben mit mats: [] an - Unreal legt dann nur einen Default-Slot an und die eingefrorene Konvention M_Rock_<Sorte> greift nicht. Jetzt Standard AN. Normale Steine rotieren durch M_Rock_Granite/Basalt/Sandstone/Mossy, das Erzfels-Set bekommt einen NEUTRALEN Slot M_Rock_Ore - ein Set fuer alle Erzsorten, die Sorte macht die Material-Instanz. 2) Namens-Drift Fels_ statt Rock_ War ein Versehen, keine Absicht: der Standard-Praefix stammte noch aus der ersten Fassung, bevor die Konvention Rock_<Set>_<Groesse>_<NN> stand. Der Erz-Set-Knopf setzte "Rock" schon selbst, der allgemeine Standard nicht. Standard ist jetzt "Rock" - keine Asset-Zwillinge, keine Migration noetig. 3) Erzfelsen mit ~870 statt ~2700 Tris Nachgestellt: aus den Werkseinstellungen liefert der Set-Knopf 2590-2690 Tris, die Automatik greift also. ~870 entstehen genau dann, wenn man den Erz-Haken setzt und den NORMALEN Erzeugen-Knopf nimmt - Werkseinstellung ist Decimate 0.20/0.50 statt 0.40/0.80. Das ist eine Bedienluecke, kein Fehler in der Automatik: die Dichte wird bewusst nur ueber den Set-Knopf gesetzt, damit niemandem seine Einstellungen unterm Hintern weggezogen werden. Deshalb warnt der Operator jetzt, wenn mit Erz-Haken ein Mesh unter 800 Verts entsteht, und nennt den Knopf "Smooth & dicht" beim Namen. Sonst faellt das erst in UE auf und sieht dort nach einem Material-Fehler aus. Tests halten den Vertrag jetzt fest: Auslieferungszustand (assign_material an, Praefix Rock), neutraler Erz-Slot, Sorten-Slots bei normalen Steinen. 17 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
a2d46424ec |
Rock Gen 2.17.0: Erz-Maske invertiert - Nuggets laufen auf A = 0 zu
Entscheidung der Spielseite: die A-Semantik bleibt eingefroren (1.0 = kein Erz),
der Master loest es ueber
Erz = (1 - A) * ErzMenge
mit ErzMenge als MI-Regler, Standard 0. Normale Stein-MIs ignorieren den Kanal
damit vollstaendig, nur die Erz-MIs drehen ihn auf. Kein Re-Export des
25er-Sets noetig, keine Fallunterscheidung im Addon.
Dafuer musste die Maske umgedreht werden: bisher lag das Nugget-ZENTRUM auf
A = 1.0 - also auf demselben Wert wie "kein Erz". Unter der Master-Formel waere
das Erz damit unsichtbar gewesen und der ganze RESTLICHE Stein haette als Erz
gegolten. Jetzt laufen die Nuggets auf A = 0 zu.
Gemessen: ohne Erz A 1.00..1.00 und (1-A) max 0.000 - ein normaler Stein zeigt
im Master garantiert nichts. Mit Erz erreicht (1-A) 1.00, Abdeckung unveraendert
4/9/15 % bei Anteil 0.08/0.18/0.35. Die Erzstellen sitzen an denselben Punkten
wie vorher, nur andersherum kodiert.
Die Tests pruefen jetzt direkt gegen die Master-Formel statt gegen den Rohwert -
am Rohkanal ist die Richtung zu leicht zu verwechseln. Panel zeigt bei aktivem
Erz-Bake "A=Erz (0=Erz)" plus den Hinweis auf die Formel, damit das niemand
versehentlich zurueckdreht.
Nugget-Groesse bleibt wie entschieden ABSOLUT (Radius in Metern).
ACHTUNG: Erz-Assets, die mit 2.15/2.16 exportiert wurden, tragen die alte
Richtung und muessen neu exportiert werden. Steine ohne Erz-Bake sind nicht
betroffen - deren A war und ist durchgehend 1.0.
17 Tests bestehen.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
2bf2f907bf |
Rock Gen 2.16.0: Bruchstuecke (Punkt 4) + Erz-Stueck (Punkt 4a)
Kein Laufzeit-Fracturing im Spiel - die Teile werden beim Anschlagen als Physik-Actors gespawnt, entstehen hier also als vollwertige Assets. Knopf "In Bruchstuecke zerlegen" arbeitet auf der Auswahl: <Name>_Piece_01..NN, 2-4 Teile, Bruch-Seed, optional Mutterstein ausblenden. Jedes Teil bekommt Vertex-Layout v2, Ursprung unten-mittig, die gleichen Material-Slots wie der Mutterstein und beim Export eine eigene UCX-Huelle. Punkt 4a: "Ein Stueck mit Erz" benennt ein zufaelliges Teil <Name>_Piece_Erz und schreibt Erz-Adern in dessen A-Kanal. Alle anderen Teile behalten A = 1.0. Ob es gespawnt wird, entscheidet die Loot-Logik im Spiel. Zusammenpassende Bruchkanten ohne Abstimmung: Voronoi ueber Halbraeume. Fuer jedes andere Zentrum wird an der Mittelsenkrechten geschnitten und die abgewandte Seite verworfen - benachbarte Zellen schneiden dadurch an GENAU derselben Ebene. Bewusst ohne das Cell-Fracture-Addon (muesste aktiviert sein, haengt an Operator-Kontext); bmesh laeuft immer. Die Falle, die mich mehrere Anlaeufe gekostet hat: jeder Schnitt muss SOFORT geschlossen werden, und zwar ueber genau die Kanten aus geom_cut. Der naheliegende Weg - am Ende alle Randkanten suchen und fuellen - erzeugte Kanten mit vier Flaechen (hauchduenne Splitter, 0.000007 m2 gegen Median 0.0025); raeumte man die ab, blieben Loecher. dissolve_degenerate half nicht, weil es nach KantenLAENGE geht und ein langer duenner Splitter keine kurze Kante hat. Aufgefallen ist das Ganze am Volumen, nicht am Auge: die Teile kamen zusammen auf 72.7 % des Muttersteins, weil calc_volume bei offenen Meshes Unsinn liefert. Jetzt 100.2 % bei 2, 3 und 4 Teilen, 0 offene und 0 non-manifold Kanten. Genau dieser Vergleich steht im Test - er ist zugleich das Warnsignal fuer kaputte Topologie. Neu: tests/test_bruchstuecke.py. 17 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
f5b528a874 |
Rock Gen 2.15.0: Erzfels-Set (Punkt 5) + Smooth/dicht (Punkt 6)
Punkt 5 - EIN neutrales Erzfels-Set fuer ALLE Erzsorten A-Kanal traegt die Erz-Maske: sie sagt nur WO Erz sitzt. WELCHES Erz (Kupfer/Eisen/Gold = Tint + Gluehen) macht die Material-Instanz in UE. Knopf "Erzfels-Set erzeugen (S + M)" liefert Rock_Ore_S_NN und Rock_Ore_M_NN und setzt alle Einstellungen danach zurueck. Regler: Erz-Anteil, Nugget-Groesse (Radius in m), Erz-Seed. Nuggets statt Noise: gestreute Zentren mit weichem Abfall. Ein Noise-Feld gaebe wolkige Schlieren, Erz sitzt aber in abgegrenzten Einschluessen. Die Zentren bevorzugen Fugen - Adern folgen Rissen, und das Gluehen liest sich in einer Vertiefung besser. Ohne Erz-Bake bleibt A auf 1.0 - wie im eingefrorenen Layout v2 und wie das bestehende 25er-Set es traegt. Punkt 6 vorgezogen, weil Punkt 5 davon abhaengt Die Maskenaufloesung haengt an der Vertex-Dichte. Bei den bisherigen ~150-Vert-Steinen war jedes dritte Vertex ein Nugget-Zentrum: im Render liefen die Nuggets zu grossen Schlieren zusammen statt einzelne Einschluesse zu bleiben. Bei ~1350 Verts liest es sich richtig. Deshalb gibt es jetzt "Smooth & dicht" (Unterteilung 5, Decimate 0.40/0.80, Auto-Smooth) und das Erz-Set stellt selbst darauf um. Gemessen ueber drei Seeds: 2708/2658/2716 Tris - im Zielfenster 1500-3000. Zusaetzlich ist die Nuggetzahl auf ein Zentrum je ~10 Verts gedeckelt. Nebenbei: _asset_name schrieb die Form-Bezeichnung pauschal gross, daraus wurde "Rock_ORE_S_01" statt des vereinbarten "Rock_Ore_S_01". Einzelne Buchstaben (Form A, B, C) werden weiter gross geschrieben, laengere Bezeichner behalten ihre Schreibweise. Gemessen: Erz-Anteil 0.08 -> 4 %, 0.18 -> 9 %, 0.35 -> 15 % der Oberflaeche, A 0.00..1.00, S bis 0.80 m / M ab 1.71 m, Maske ueberlebt den FBX-Roundtrip. Neu: tests/test_erz.py. 16 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
20a751edca |
Rock Gen 2.14.0: Export-Haertung (Wunschliste 1-3) + LOD/Vertex-Farben geklaert
Punkt 1 - Ursprung erzwingen (keine Option mehr) Der Export schrieb die Objekt-Transformation mit ins FBX. Dadurch trug das 25er-Set seine Szenen-Rasterpositionen (bis 20 m) im Asset und die Steine schwebten im Spiel neben ihrem Platzierungspunkt. Jetzt wandert jedes Objekt an den Welt-Ursprung, Origin unten-mittig der Bbox. Am REIMPORTIERTEN FBX gemessen: Bbox-Mitte 0.000/0.000, min.Z 0.000. Punkt 2 - flache Steine hinlegen Kuerzeste Bbox-Achse zeigt nach oben. Gedreht wird nur, wenn es etwas bringt: bei 2.53/1.40/1.54 wuerde Kippen die Form nur willkuerlich drehen. Punkt 3 - UCX-Kollisionshuellen Konvexe Huelle als UCX_<Name> im selben FBX, Budget einstellbar (Default 32 Verts). Gemessen 29-32 Verts, geschlossen, umschliesst den Stein. Alles auf temporaeren KOPIEN - die Szene des Users bleibt unveraendert (Test prueft Namen und Objektzahl vorher/nachher). Offener Punkt der Spielseite beantwortet: LOD-Gruppen + Vertex-Farben gingen NICHT. Der LOD-Zweig in make_one_rock sprang komplett am Cavity-Bake vorbei - gemessen: kein Farbattribut auf einer der vier Stufen, dazu fehlten Origin und Material. Jetzt wird auf LOD0 gebacken, BEVOR dupliziert wird; das Decimate interpoliert mit, damit alle Stufen dieselbe Cavity zeigen und der LOD-Wechsel nicht poppt. Nach Roundtrip: LOD0 40 V R 0.30..1.00, LOD1 21 V, LOD2 11 V, LOD3 6 V - alle mit Farben. Vier Fallen, die der Test aufgedeckt hat: - Blender haengt an Kopien ".001" an; Unreal ordnet UCX ueber den EXAKTEN Mesh-Namen zu -> Original bekommt fuer die Exportdauer einen Hilfsnamen. - bmesh.from_mesh bringt die Originalflaechen mit, convex_hull legt seine Huelle obendrauf -> 16-21 offene Kanten. Nur die PUNKTE einlesen. - Jede Vereinfachung schneidet Ecken ab, die Huelle wird KLEINER als der Stein (der Spieler wuerde einsinken). Jetzt exakt so weit aufgeblasen, dass wieder alles hineinpasst - fuer Kollision ist minimal zu gross unkritisch. - ob.matrix_world = Identity loescht die Transformation NICHT bei geparenteten Objekten; bei einer LOD-Gruppe auf (13/-7.5/2.2) landete das Mesh bei MINUS dieser Position. matrix_basis und matrix_parent_inverse direkt nullen. Neu: tests/test_export_robust.py misst am reimportierten FBX statt an der Szene - nur so faellt eine mitgeschriebene Transformation ueberhaupt auf. 15 Tests bestehen. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
26131f9346 |
Tree Gen 1.25.0: Palme, Busch und Setzlinge nachgemessen und korrigiert
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
47b772d62d |
README: 'zwei Extensions' auf vier korrigiert
Kopfzeile und Abschnitts-Titel stammten noch aus der Zeit mit Rock + Tree. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
71b9982441 |
Panels aufgeraeumt (alle vier Addons) + Test-Suite instandgesetzt
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>
|
||
|
D4rkst3randClaude Opus 4.8
|
ef57050739 |
Neu: Stylized Asset Utils 1.0.0 (viertes Addon)
Fuer handgebaute Assets, die nicht durch einen Generator laufen (Pilze, Baumstumpf, Erzfels, Props). Panel in fuenf einklappbaren Unter-Panels statt einer langen Liste: 1 Vorbereiten - Rotation/Scale anwenden, Ursprung unten-mittig, Normalen 2 Vertex-Farben - R=Cavity / G=Teil-oder-Moos-Maske / B=Hoehe / A=1 3 Benennung - <Basis>_<NN>, Mesh-Daten ziehen mit 4 Pruefen - Asset-Check auf alles, was in UE Aerger macht 5 Export - FBX je Mesh mit colors_type='SRGB' Zwei Bugs beim Bauen gefunden und gefixt: - v.link_faces gibt es nur in bmesh, nicht auf Mesh.vertices -> lose Vertices ueber die tatsaechlich benutzten Indizes zaehlen. - bpy.ops.paint.vertex_color_set braucht den Vertex-Paint-Modus und scheitert im Object-Mode mit "poll() failed". Zusammen mit vertex_color_dirt im selben try wurde dadurch der GANZE Bake stillschweigend uebersprungen (R/G/B blieben 1.0). Initialisierung laeuft jetzt direkt ueber Python. Verifiziert am nachgebauten Pilz: Check meldet vorher Scale/Rotation/Ursprung, nach "Vorbereiten" Scale 1/1/1, Rot 0/0/0, min_z 0.0000 und "ok". Teil-Maske G=1 im Hut, 0 im Stiel. Nach FBX-Roundtrip G-Werte [0.0, 1.0] erhalten. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
512d61e370 |
Rock Generator 2.12.0: Vertex-Cavity auf beliebige Meshes + Teil-Maske
Der User baut Pilze von Hand (Hut und Stiel als getrennte Objekte, mit Strg+J verbunden) und fragte, was er wegen Vertex-Farben beachten muss. Zwei Ergaenzungen: 1) Button "Vertex-Cavity auf Auswahl": backt R=Cavity / G / B=Hoehe auf JEDES markierte Mesh - nicht mehr nur auf generierte Steine. Damit lassen sich handgebaute Assets (Pilze, Baumstumpf, Erzfels) auf dasselbe Layout bringen. 2) Option "G = Teil-Maske (Shells)": statt der Moos-Maske werden getrennte Mesh-Teile markiert. Der oberste/breiteste Teil bekommt G=1, der Rest 0. Bei Strg+J-verbundenen Assets ist die Trennung dadurch EXAKT statt ueber Normalen geschaetzt - beim Pilz also Hut vs Stiel. Ein Material toent beide unterschiedlich, ein zweiter Material-Slot entfaellt. Einteilige Meshes bleiben bewusst unmarkiert (G=0), damit die Maske nichts Falsches behauptet. Am nachgebauten Pilz geprueft: 2 Shells erkannt, G im obersten Teil ausschliess- lich 1.0, im Rest ausschliesslich 0.0, Maske binaer, Einzelteil-Mesh -> nur 0.0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
2882c099b4 |
Rock Generator 2.11.0: Quader-Proportionen auf gleiches Volumen normiert
Beim Export von Form C (flache Platte) fiel auf: Fels_C_S war 1.45 m, waehrend Fels_A_S nur 0.85 m misst - dieselbe Klasse, aber deutlich groesser, nur weil eine Achse gestreckt ist. Damit waere die Groessen-Klasse formabhaengig gewesen. Die Proportionen werden jetzt auf geometrisches Mittel 1.0 normiert. "M" bedeutet bei jeder Form dasselbe Volumen; eine Platte ist dann flacher UND breiter, aber nicht schwerer. Dass ihre laengste Kante groesser ausfaellt, ist geometrisch zwangslaeufig und Absicht. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
c7154ca690 |
Neu: Stylized Grass Generator 1.0.0 (drittes Addon im Repo)
Gras-, Blumen- und Farn-Bueschel. Kern ist die WIND-UV nach Vorgabe des Users:
UV0.V = 0 an der Wurzel, 1 an der Spitze - genau die Maske, die UEs
"SimpleGrassWind" als WindWeight braucht.
Am Zielmaterial geprueft (M_Grass.uasset): es nutzt SimpleGrassWind +
WorldPositionOffset + TextureCoordinate, aber KEINE VertexColor. Die Windmaske
kommt deshalb primaer ueber die UV - die Assets laufen damit ohne
Materialaenderung.
Vertex-Farben zusaetzlich, nicht als einzige Quelle:
R = Kopie der Windmaske (Fallback)
G = Variation je HALM - Ebene unter dem Biom-Tint, den die Engine bereits ueber
PerInstanceCustomData 0/1 pro Instanz setzt; im Material multiplizieren
B = AO (unten dunkel)
Presets gras / gras_hoch / steppengras / farn / blume, Zufalls-Button,
Tri-Budget-Warnung (400 laut ASSETS.md).
Gemessen: UV.V Wurzel 0.000 -> Spitze 1.000, 112 Tris bei 14 Halmen, G hat
exakt 14 verschiedene Werte bei 14 Halmen (also wirklich pro Halm, nicht pro
Vertex), min_z = 0.0000, UV und VCol ueberleben den FBX-Roundtrip.
build.ps1 baut jetzt drei Extensions - dieselbe URL liefert alle.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
b16e5ab75a |
Rock Generator 2.10.0: Quader als Grundform (Platten und Riegel)
Auf Wunsch des Users neben Wuerfel und Ico-Sphere eine Quader-Grundform mit frei einstellbaren Proportionen (X/Y/Z) plus Streuung je Stein. Damit entstehen flache Platten und langgestreckte Riegel - passt besonders zum Plattenlook der Genshin-Referenz, wo Felsen aus flachen Schichten bestehen. Wichtiges Detail: die Proportionen werden auf die MESH-DATEN angewendet (transform_apply), nicht auf das Objekt. Der Displace arbeitet mit globalen Texturkoordinaten - eine Objekt-Skalierung wuerde das Rauschen mitverzerren statt die Form zu aendern. Gemessen bei Proportion (2.0, 1.5, 0.35): 3.43 / 2.56 / 0.79 m (Z = 23 % von X), bei (2.2, 0.8, 0.9): 3.81 / 1.40 / 1.60 m. Der Zufalls-Button kennt die neue Form ebenfalls. Neuer Test tests/test_base_shapes.py. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
9d1660560c |
Rock Generator 2.9.0: Vertex-Farb-Layout v2 (kanal-getrennt)
Nach Wunschliste des Users. Attribut "Cavity" traegt jetzt drei UNABHAENGIGE
Masken statt einer eingebackenen Mischung:
R = Cavity pur 1 = offene Flaeche, 0 = tiefe Fuge - OHNE Hoehen-Verlauf
G = Moos/Schmutz aus Oberseiten-Anteil + Fugennaehe + Noise, mit Reglern
fuer Menge, Aufbruch und Seed
B = Hoehen-Verlauf 0 = Unterseite, 1 = oben, separat
A = 1 (Reserve)
Der Punkt: Boden-Saum und Moosfarbe entscheidet jetzt das MATERIAL pro Instanz,
nicht mehr das Mesh. In v1 steckte der Verlauf fest in R und liess sich nicht
mehr trennen.
Gemessen: R ohne Hoehenabhaengigkeit (unten 0.62 / oben 0.59 - vorher war das
der eingebackene Verlauf), B steigt 0.08 -> 0.92, G oben 0.57 vs unten 0.20,
A konstant 1.00. Moos-Seed aendert die Verteilung. Alle drei Kanaele ueberleben
den FBX-Roundtrip.
tests/test_vertex_cavity.py prueft jeden Kanal einzeln inkl. Roundtrip.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
de2acdd381 |
Rock Generator 2.8.0: Cavity in Vertex-Farben (texturfreier Weg)
Idee kam vom User: die Steine ueber "smart materials" in UE loesen statt ueber gebackene Texturen. Prozedurales Noise/Voronoi im Shader waere zu teuer (laeuft pro Pixel), aber der Kern der Idee traegt - deshalb dieser Weg: Neue Option "Cavity in Vertex-Farben": schreibt Cavity/AO plus optionalen Hoehen-Verlauf in das Farb-Attribut "Cavity" (vertex_color_dirt + eigene Nachbearbeitung fuer Staerke und Verlauf). Das Material braucht damit KEINE Textur: Base Color = Farbton x VertexColor, dazu Kantenlicht und Schattentint. Gegenueber Triplanar sitzen die dunklen Fugen dadurch auf den ECHTEN Kanten des Meshes statt darueberzuschweben - genau das passiert in der Genshin-Referenz. Verifiziert: Attribut wird angelegt, Wertebereich 0.250..0.947 (echter Kontrast), und es ueberlebt den FBX-Roundtrip UNVERAENDERT (gleicher Bereich nach Import). Regler: Cavity-Staerke, Hoehen-Verlauf, Weichzeichnen. Neuer Test tests/test_vertex_cavity.py. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
1df70c9e50 |
Rock Generator 2.7.0: Plattenstil nach Genshin-Referenz
Der User hat Genshin-Screenshots als Stilvorlage geschickt. Auswertung: die
Felsen dort bestehen aus WENIGEN GROSSEN, fast leeren Platten mit SCHMALEN
DUNKLEN FUGEN. Das Detail steckt in der Fuge, nicht in der Flaeche.
Meine Textur machte das Gegenteil - viele kleine Zellen mit breitem Verlauf ueber
die ganze Oberflaeche. Deshalb half weder TexScale noch die Zellgroesse: beide
haben nur am Symptom gedreht, waehrend das Muster grundsaetzlich zu dicht war.
Neue Regler:
- "Fugenbreite" (Default 0.05): Breite des Uebergangs Fuge -> Flaeche. Klein =
harte Fuge und flache Platte. War vorher fest auf 0.32 = weicher Verlauf ueber
die ganze Zelle ("Golfball").
- "Platten flach" (Default 1.0): 1 = Flaeche nahezu einfarbig, Kontrast wandert
komplett in die Fuge.
- "Zellgroesse" heisst jetzt "Plattengroesse" (Default 0.7 statt 2.5) - kleiner
= GROESSERE Platten. Der alte Name war irrefuehrend.
Grundton auf helles warmes Grau, AO-Staerke 1.0 -> 0.55 (weniger Unruhe).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
||
|
D4rkst3randClaude Opus 4.8
|
d58bfe05e8 |
Rock Generator 2.6.0: Groessen-Klassen wirken jetzt + Randomize-Bug gefixt
1) KLASSEN-GROESSE (vom User gemeldet): S und M kamen gleich gross raus. Ursache war eine Luecke im Design, nicht in der Bedienung: "keep_size" normiert die Zufalls-Streuung auf konstantes Volumen - damit wurde alles, was ueber scale_min/max eingestellt war, wieder herausgerechnet. Fuer die Groesse der KLASSE gab es schlicht keinen Regler. Neu: CLASS_SIZES (S=0.45, M=1.0, L=1.9, XL=3.2) plus "Groesse aus Klasse" und eine freie "Basis-Groesse". Die Klassengroesse ist bewusst gesetzt und von der Streuung getrennt; sie greift auch bei abgeschalteter Randomisierung. Gemessen: S 0.85 m | M 1.9 m | L 3.5 m | XL 6.0 m, Volumen-Streuung INNERHALB jeder Klasse bleibt bei 1.11x (nur Form). 2) BUG im Zufalls-Button (kam mit 2.5.0): jitter() schrieb einen float in die int-Property subsurf_levels -> TypeError, der Operator brach komplett ab. jitter() rundet jetzt fuer Int-Properties. Von tests/test_randomize.py gefangen. Neuer Test tests/test_rock_classes.py deckt die Klassengroessen ab. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
833e929f82 |
Tree Generator v1.23.0: Blattwerk auf die Zweige streuen
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> |
||
|
D4rkst3randClaude Opus 4.8
|
1bb547c70c |
Zufalls-Funktion in beiden Addons + Zusatz-Ebenen + Form-statt-Groesse
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> |
||
|
D4rkst3randClaude Opus 4.8
|
f5bbd1bc35 |
Beide Addons auf die EcoGame-Konventionen abgestimmt
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> |
||
|
D4rkst3randClaude Opus 4.8
|
10b27a25a9 |
Tree Generator v1.13.0: Kaktus als echter Saguaro + Trunk Tip
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> |
||
|
D4rkst3randClaude Opus 4.8
|
d9c642fcd2 |
Tree Generator v1.10.0: Kronenform + 5 neue Baum-Varianten
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> |
||
|
D4rkst3randClaude Opus 4.8
|
f9e3fe4223 |
Tree Generator v1.1.0: Aeste folgen der Elternkurve
Kern aus EcoGame tools/blender_tree_gen.py regeneriert. Ast-Richtung jetzt ueber Tangent/Normal von 'Curve to Points' (Goldener Winkel) statt Weltkoordinaten -> Sub-Aeste wachsen entlang ihres Elternastes statt quer dazu. 'Tip Blunt' neu. Headless getestet: alle 4 Presets, Stufen aufsteigend, Modifier-Apply ok. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
9240cc6d80 |
Rock-Generator auf v2.3.0 (Zell-Look-Bake) + Listing neu gebaut
Die Zell-Look-Aenderung am Textur-Bake (Voronoi statt fBm, Grundfarbe/Zellgroesse regelbar) war im vorigen Commit ohne Versions-Bump mitgelaufen -> Blender haette kein Update angeboten. Version nachgezogen, Listing enthaelt jetzt Rock 2.3.0 + Tree 1.0.0. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> |
||
|
D4rkst3randClaude Opus 4.8
|
7406d30d4a |
Tree Generator als zweite Extension im selben Repo
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> |