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>
This commit is contained in:
@@ -563,6 +563,36 @@ Der Kaktus erzeugt regulaer **0 Cards** — kein Ast ist duenner als `Max Radius
|
||||
und das ist botanisch richtig. Vorher lief das still durch und man stand vor
|
||||
einer leeren `_Leaf`-Ebene; jetzt sagt der Operator es und nennt den Regler.
|
||||
|
||||
### UCX bei LOD-Gruppen: der Name muss auf den MESH-Node zeigen
|
||||
|
||||
Der Legacy-Importer von Unreal matcht `UCX_<Mesh-Node>` - **nicht** gegen das
|
||||
LodGroup-Empty. Eine Huelle mit dem Gruppennamen liegt zwar in der Datei und ein
|
||||
Reimport nach Blender zeigt sie brav an, aber Unreal verwirft sie STILL:
|
||||
gemeldet von der Spielseite mit `convex = 0` an 108 Stand-Baeumen und 57
|
||||
Fels-Meshes. Beweis von dort: dieselbe Datei, Huelle umbenannt auf den
|
||||
LOD0-Node, liefert `convex = 1`.
|
||||
|
||||
`UCX_<Basisname>` ist nur OHNE LOD-Kette richtig, weil der Mesh-Node dann genau
|
||||
so heisst. Deshalb funktionierten die Faell-Teile und `_Pieces_All.fbx` die
|
||||
ganze Zeit - die haben keine LODs.
|
||||
|
||||
**Wie das durchrutschen konnte, ist die eigentliche Lehre.** Fuer 1.42 habe ich
|
||||
die Konvention nicht geraten, sondern am Fels-Export nachgemessen: exportieren,
|
||||
reimportieren, Namen und Hierarchie pruefen. Das war richtig - und hat trotzdem
|
||||
nichts bewiesen, weil der Fels-Export denselben Fehler hatte. Gemessen wurde die
|
||||
STRUKTUR ("liegt die Huelle in der Datei, heisst sie wie erwartet, haengt sie
|
||||
richtig?"), nicht die WIRKUNG ("nimmt Unreal sie an?"). Eine abgeschaute
|
||||
Konvention ist nur so gut wie die Quelle, von der sie stammt.
|
||||
|
||||
Die Tests pruefen deshalb jetzt die REGEL statt des Namens: hinter `UCX_` muss
|
||||
ein Mesh-Node aus derselben Datei stehen, und zwar LOD0. Das haette den Fehler
|
||||
in beiden Addons gefunden, ohne dass jemand die Antwort vorher kennt.
|
||||
Gegenproben: Baum 9 Fehler, Fels 1 Fehler.
|
||||
|
||||
Was nur die Engine beantworten kann - ob `convex` nach dem Import wirklich
|
||||
groesser 0 ist - bleibt bei der Spielseite. Der Test kann nur sicherstellen,
|
||||
dass die Datei die Bedingung erfuellt, an der es lag.
|
||||
|
||||
### Die Gesamtdatei steht jetzt auch auf der Stammbasis
|
||||
|
||||
`_Pieces_All.fbx` trug den SZENEN-Nullpunkt mit: ein Baum bei x = 18 m
|
||||
|
||||
Reference in New Issue
Block a user