stylized-rock-generator

73 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
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>	2026-08-07 12:22:35 +02:00
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>	2026-08-07 06:18:29 +02:00
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>	2026-08-06 06:42:59 +02:00

Author

SHA1

Message

Date

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>

2026-08-07 12:22:35 +02:00

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>

2026-08-07 06:18:29 +02:00

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>

2026-08-06 06:42:59 +02:00