main
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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
|
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
|
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>
|