b1fdad81067c89783d2d2df106d9283ea801b562
13
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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
|
46b4e9ee34 |
Tree Gen 1.26.0: spielfertiger Stand-Baum + Kugel-Normalen (Punkt 1 + 2)
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> |
||
|
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
|
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>
|