[George]

Das Programm CSMeshCooker kann .x Meshes ins NXS-Format, proprietäres Format von PhysX, umwandeln.
Des weiteren ist die Umwandlung eines NXS-Meshes ins .obj Format möglich

Gothic 3 Collision Shapes werden in Dateien mit der Endung *.xnvmsh gespeichert.
xnvmsh Dateien enthalten eines, oder mehrere dieser NXS-Meshes, je nachdem aus wie viele SubMeshes die zugehörige xcmsh Datei besteht.

Anleitung zur Erstellung eines Collision Shapes

1. Collision Shape erstellen in (Blender, Gmax etc.)
2. Auf ein 100. der Größe, welches es ingame haben soll, skalieren.
3. Als DirectX-Datei (.x) exportieren.
-> Convex Collision Meshes: Wenn die Verbindungsstrecke 2er beliebiger Vertices immer innerhalb des Meshes liegt.
-> Triangle Collision Meshes: Alle anderen Fälle
4. DirectX-Mesh mit CSMeshCooker in NXS-Mesh umwandeln.
5. Den Inhalt der NXS-Mesh in eine xnvmsh Datei einbauen.
6. Die xnvmsh einem Mesh zuordnen und testen.

Anleitung für CSMeshCooker

CSMeshCooker.exe mode type input output

mode: conversion direction (cook or uncook)
type: type of the mesh (triangle or convex)
input: file which contains the source mesh
output: file to store the converted mesh

Ich werde die einzelnen Parameter im folgenden erläutern und beispielhaft die Erstellung eines Convex-Collision Shapes erläutern.

Ganz am Anfang steht der Name der exe Datei des Programms, also CSMeshCooker.exe.
Nun folgen, jeweils durch ein Leerzeichen getrennt die 4 Parameter.

mode
Hier setzt man entweder cook, d.h. NXS-Mesh aus .x-Datei erstellen, oder uncook, d.h. .obj Datei aus NXS-Mesh erstellen, um ein Collision Mesh bearbeiten zu können.
Da wir ein NXS-Mesh erstellen wollen, setzen wir hier cook ein.

Aktuelle Kommandozeile

CSMeshCooker.exe cook

---

type
Hier setzt man entweder triangle, falls das Mesh ein Triangle Mesh ist, oder convex, falls das Mesh ein Convex Mesh ist.
Für unser Beispiel wählen wir convex.

Aktuelle Kommandozeile

CSMeshCooker.exe cook convex

---

input
Hier kommt der Pfad zum Eingabe Mesh hin, je nachdem welchen Mode man gewählt hat, ist das entweder eine .x-Datei oder ein NXS-Mesh
Wir setzen in unserem Beispiel Beispiel.x ein. Der Name des Meshes reicht nur, wenn die Datei im gleichen Ordner wie die exe liegt, sonst müsste man noch zusätzlich den Pfad angeben.

Aktuelle Kommandozeile

CSMeshCooker.exe cook convex Beispiel.x

---

output
Hier kommt der Pfad zum Ausgabe Mesh hin, je nachdem welchen Mode man gewählt hat, ist das entweder das erstellte NXS-Mesh oder eine .obj-Datei.
Als Ausgabenamen für unsere Datei verwenden wir Beispiel.nxs.

Aktuelle Kommandozeile

CSMeshCooker.exe cook convex Beispiel.x Beispiel.nxs

[|Lorn|]

Ich bekomme leider einen "Input file is not a valid Direct X Mesh"-Error. Gibt es etwas bestimmtes beim Export aus Blender zu beachten?

[George]

Bei mir klappt es, im Anhang habe ich eine Datei mit einem Screenshot meiner Export Einstellungen und zwei Beispielmeshes.

[|Lorn|]

Hm, lag wohl an meiner Blender-Version (2.49). Mit der neuesten (2.70a) funktioniert es einwandfrei. Hat sich wohl etwas am .x-Export geändert.

[George]

Diese offiziele DirectX Funktion wird verwendet, um das Mesh zu laden. Daher kann ich dir nicht sagen, warum es mit dem alten Exporter nicht geht.

[|Lorn|]

Mir ist leider immer noch nicht ganz klar wo genau der NXS-Teil in einer xnvmsh enden soll. Am DEADBEEF? Oder schon vorher?

[George]

Kann man .xnvmsh Dateien mit dem Tiny Hexer öffnen? Damit sollte ersichtlich sein, welcher Teil der NXS-Teil ist.

[|Lorn|]

Ja darin hab ichs geöffnet. Deswegen frag ich ja. Für mich ergibt sich da kein eindeutiges Muster. Der Anfang ist klar, aber das Ende nicjt. Den DEADBEEF erkenne ich. Die Frage ist nur ob davor noch ein Teil der xnvmsh steht oder die NXS bis da geht.

[George]

[Bild: attachment.php?s=015ed76b0d3d145d12aecf796eccd384&attachmentid=43852&d=1450282834&thumb=1]

Ich haue einfach mal ein Beispiel raus. Der NXS-Teil geht von 0x00000048 (START OF NXS-Mesh No. 1 + 0x08) bis 0x00000CD1 (END OF NXS-Mesh No. 1). Wenn du den NXS-Teil austauschst, musst du natürlich auch 'Size until end of NXS Mesh' anpassen.

[|Lorn|]

Ach Gott ans Script hab ich gar nicht mehr gedacht Danke für den Hinweis, George!

Edit: Ich hab mich wohl geirrt. Dachte das wäre lichtwichts Script aber das kann wohl gar keine xnvmsh.

[tombom81]

Tut mir leid, dass ich den thread hier wieder ausgrabe, aber mir fehlt ein wenig die "abschließende Klarheit", wie denn nun ein "Header" und ein "Tail" um den nxs-Part herum aussehen müssen. Ich habe die Kollisionsdateien für G3_Object_Table_01 angeguckt, von denen es seltsamerweise zwei zu geben scheint: eine (TriMesh?) xnvmsh
und eine _CV.xnvmsh (convex?):

[Bild: CollisionMesh_Header_Tail.JPG]
Was mir fehlt, ist der Wert an der Adresse 0x29 bei beiden Dateien; wie berechne ich den?
0x1809 = 0x1766 + 0xA3 (0x1766 ist Länge der nxs-Datei + 4 (Nullbytes))
Aber der Offset zum Start von NXS ist 0x91, nicht 0xA3.

Bei der _CV-Datei ist es ähnlich:
0xBD8 = 0xB61 + 0x77 (Länge nxs-Datei: 0xB5E)
Der Offset zum String "NXS CVXM" ist aber 0x69.

(Muss ich mich um die (float) Werte für ResourcePriority (grau gerahmt) kümmern, oder ist das relativ egal?)

Die tails scheinen bei 0x17F3 bzw. 0xBC6 zu starten. Ist das richtig?

Für eine Aufklärung wäre ich sehr verbunden, danke!

edit: ok, der offset an 0x29 (+0x2D) zeigt auf das Ende der Datei.
Es spricht etwas dafür, dass der "tail" erst bei 1E 00 anfängt. (Außerdem sieht das nach bounding box-Werten aus im tail, aber die Anzahl der floats ist bei verschiedenen Kollisionsdateien unterschiedlich;
eine Bounding Box besteht doch normalerweise aus 6 floats?)

Bei G3_Object_Varant_Table_01.xnvmsh steht an 0x90 0x6DC, während am Ende (hinter 1E 00)
0x370E steht. Sollten die Werte nicht identisch sein? Das verwirrt mich doch ein wenig.

[George]

Ich sehe gerade, dass nur die angepasste Version des Tiny Hexer Scripts .xnvmsh Dateien auflösen kann. Ich habe sie soeben veröffentlicht. Damit sollte es um einiges einfacher werden.

eine (TriMesh?) xnvmsh
und eine _CV.xnvmsh (convex?):

Korrekt.

(Muss ich mich um die (float) Werte für ResourcePriority (grau gerahmt) kümmern, oder ist das relativ egal?)

Die ResourcePriority ist egal.

[tombom81]

Ich sehe gerade, dass nur die angepasste Version des Tiny Hexer Scripts .xnvmsh Dateien auflösen kann. Ich habe sie soeben veröffentlicht. Damit sollte es um einiges einfacher werden.

Vielen Dank, George! Du hängst dich ja echt rein!

Ich guck mir das morgen (heute) genauer an. Dann werde ich bestimmt auch sehen, wo mein Fehler beim Zusammenbauen der Kollisionsdatei ist, bisher habe ich nämlich leider keine funktionierende erstellen können.

[Askanius]

Alternativ, falls du nicht weiter kommst:

Hier mal zwei Beiträge aus unserem Forum zum Thema CollisionShapes. Hervorhebungen von mir. Ich glaube, diese Methode müsste auch bei dir funktionieren. Ist etwas umständlich, aber MadFaTals Beitrag liefert eigentlich ein gutes Kurztutorial, wie du auch ohne den MeshCooker an ein CS kommst.

Mir ist jetzt beim draufgucken auf gefallen, dass die BoundingBox nicht stimmt. Liegt es daran?
Bild

Außerdem kannst du nicht einfach ein ConvexHull CollisionShape durch ein Triangle ersetzen, ohne den ShapeType in der Template anzupassen. Warum allerdings dein erster Versuch mit einer ConvexHull nicht funktioniert hat, kann ich so nicht sagen. Falls es nicht an der BoundingBox liegt, kannst du ja mal deinen ConvexHull Versuch hochladen.


Ich habe mal gerade die Read/Write Funktionen der eCResourceCollisionMesh_PS Klasse analysiert und festgestellt, dass die Dateien noch weitere Eigenschaften als das pure NXS-Mesh und die BoundingBoxes haben können: HasConvexResource (muss auf true gesetzt werden wenn es sich um ein Convex CollisionShape handelt), VertexPosition (???), IndexArray (???), IndexedMaterial (???), IndexedBoundary (das sind die BoundingBoxes).

Wenn man den im Tiny Hexer als '???Identifier???' bezeichneten Wert, die Version der eCResourceCollisionMesh_PS Klasse, auf einen Wert kleiner als 0x40 setzt berechnet Gothic 3 die .xnvmsh beim Laden, mit der Begründung "collisionmesh for resource %s must be recreated, old fileversion is not compatible with current physics version", neu. Der Name der zughörigen .xcmsh wird dabei aus dem Namen der .xnvmsh abgeleitet. Als Ausgangspunkt würde ich ein CollisionShape mit der Version 0x40 verwenden und diese durch 0x39 ersetzen, dann sollte G3 keine Probleme beim einlesen und neu erstellen des CollisionShapes haben. (So zumindest die Theorie, in einem ersten Test hat Gothic 3 das CollisionShape nicht neu berechnet...)

EDIT: Es liegt am Namen des CollisionShapes, es heißt G3_Armor_Helm_Myrtana_01_CV.xnvmsh, also sucht Gothic 3 nach dem Mesh G3_Armor_Helm_Myrtana_01_CV.xcmsh und findet dieses natürlich nicht.

EDIT2: Das CollisionShape wird erst geladen, wenn ein Objekt angezeigt wird, dass es verwendet.

EDIT3: Nachdem ich das originale CollisionShape umbenannt (und beschädigt) und die Version auf 0x39 geändert habe, hat mir Gothic 3 als ich die zugehörige Template gespawnt habe, ein neues CollisionShape generiert und meine 'alte' Version überschrieben.
Ich denke das ist wirklich der eleganteste Weg, möglicherweise lässt sich das Laden der .xnvmsh Datei über eine DLL Änderung automatisieren, so dass es direkt passiert, wenn man im Hauptmenü landet und nicht erst ein neues Spiel starten muss.

@Askanius:
Ich habe eins für Table_Heavy_01 mit scale 0.8 auf den SVN #6853 gelegt.
Durch den Tisch in Geldern kann der Held nun nicht mehr durchlaufen.

Ich bin hier nach der alten Methode mit zu alter Versionsnummer im .xnvmsh vorgegangen:

1.)
Wie Chris geschrieben hat, muss Mesh Name und Collision Shape Name gleich sein.
Dazu habe ich temporär den Namen G3_Object_Table_Heavy_01.xnvmsh in der G3_World_01_x-55000y0z45000_CStat.node eingetragen.

2.)
Mit G3MC habe ich ein schlechtes G3_Object_Table_Heavy_01_SC_0_8000.xnvmsh erzeugt.
Im Menü: Create -> Create bad collision file (du musst vorher irgendein Mesh laden)
Und das unter Data\_compiledPhysic ablegen.

3.)
Gothic3 starten und dorthin gehen, wo du das Objekt siehst.
Neues CollisionMesh wurde von Gothic3 erstellt.

4.)
Namen korrigieren und die temporäre Umbenennung rückgängig machen.
G3_Object_Table_Heavy_01_CV_SC_0_8000.xnvmsh


@All:
Wie Chris geschrieben hat, ist es für TriMesh CollisionShapes einfacher. Das ist mir auch bei dem Sonnensegel für Tefiks Lager_02 aufgefallen. Das ist auf 0.6 skaliert. Gothic3 erzeugt da direkt ein neues CollisionShape. Es wird nicht mal ein schlechtes benötigt.

@All2:
Beim Erstellen der CollisionShapes für die Helme ist mir aufgefallen, das Gothic3 nicht für jedes Mesh ein ConvexHull CollisionShape erzeugt. Das war bei den komplexeren, die Hörnern und Pferdeschwanz hatten, so. Da bin ich bei der Box geblieben.
Achtung: Ich hatte dazu auch ein wenig in dem PhysX Zeug gelesen. Da habe ich erfahren, das Kollisionsabfragen zwischen TriMeshes nicht unterstützt werden. Deshalb sollten wir für Dinge die der Held anziehen und benutzen kann, wohl besser keine TriMesh CollisionShapes verwenden.
Bei den Helmen bin ich deswegen bei der Box geblieben.

@George: Kannst du das rote in der Beschreibung für den Konsolenbefehl ergänzen.

[tombom81]

besten Dank, Askanius!
Das sind geschmeidige Tipps, besonders der mit 0x39!
Ja, bei mir hat G3 ein Kollisionsmesh erzeugt, hat aber nicht kollidiert.
Das lag wohl daran, dass ich ein TriMesh brauche, und das erzeugte ein convex Hull war.

(Auch für die Esmeralda hatte G3 ein neues CS (viel kleiner als das Original) erzeugt.
Hatte mich erst gewundert, und dachte das wär ein bug. Jetzt, nachdem du hier den 0x39-Trick enthüllst,
sehe ich, dass in der Original-GoldenHind xnvmsh auch 0x39 drinstand; bingo!)

Gut, bzw. schlecht, das neuerzeugte GH-CS kollidiert bei mir leider nicht; vielleicht weil ich die Esmeralda per script spawne.

Brauche ich aber auch nicht, sondern ein TriMesh für eine Lagerhalle am Hafen.
Im folgenden Bild eine Ardea_Palisaden_04 mit original-CS. Rechts unten kein CS nach 0x39-Trick (es wurde auch keine neue TriMesh-CS-Datei erzeugt!)
[Bild: Ardea_Palisaden_04.TriMeshCol.JPG]

Doch, tada, dann hat es (prinzipiell) schon mal geklappt:

[Bild: Juchhee_diePlankmachtDenTriMesh.JPG]
Und zwar habe ich das mit Georges MeshCooker erzeugte Plank_03-TriMesh (nach Umbenennung) an die Ardea_Palisaden_04 gebunden.

Dass es vorher mit derselben Datei nicht funktioniert hat, muss daran liegen dass man eine TriMesh-Entity in der CStat benötigt. (Umstellen von Box auf TriMesh und Eintragen von G3_Object_Wood_Plank_03.xnvmsh in eine Plank_03-Entity kollidierte jedenfalls bei mir nicht).

Toll, toll, toll! Wenn es keine unangenehmen Überraschungen gibt, könnte ich im neuen Jahr ein bisschen Hafenmoddeln probieren! Vielen Dank nochmal!