na denn,trozdem muss ich das rumgewrikle in nif nicht mehr haben.denn du musst ja boxen erstellen oder?und jene auch den model zuweissen oder?Das muss ich alles wie gesagt nicht machen aber ist wie ich auch schon sagte egal solange das ganze passt und was ordentliches bei rauskommt.
Also:
Der erste Versuch war, die Höhle mit ihren 7400 Triangles komplett als ein Objekt ins Spiel zu bringen. Von vornherein in kleinen Blöcken wie Bethesda zu modellieren war Unsinn, da jedes Teil maximal 2 mal verwendet werden würde. Daher wurde es ein riesen Objekt. Da die Höhle im CS dekoriert wird, hab ich bewusst drauf geachtet so wenig wie Möglich Polygone zu verwenden. Und 7400 ist nicht viel. Das schafft Oblivion auch auf einem schwachen PC locker. Also hab ich das komplette Mesh als Wavefront Object exportiert. Dann meine vorbereitete nif-Datei mit der Grundstruktur für die Kollision geöffnet und das .obj importiert. Face Normals, strippify, update Tangent Space, Texturpfad angegeben. Das NiTriStrips dem richtigen NiNode zugeordnet, das überflüssige NiNode entfernt. NiTriStrips kopiert, wieder eingefügt und als Kollisionsobjekt verwendet. Nun noch gepackt und hatte damit meine hkPackedNiTriStripsData. Klingt länger als es dauert.
Rein ins CS und ab in die Interiorzelle. Gespeichert. Aktiviert und mich im Spiel über die misserable Framerate geärgert wenn der Ava durch die Höhle lief.
Also zurück ins 3D-Programm und das Ganze in 10 Teile zerlegt (nicht in 8 wie ich vorher schrieb). Dieselbe Prozedur wie oben. Alle 10 Objekte haben denselben Ursprung, so dass es kein Aufwand war sie im CS nahtlos passend zu machen. Dann war ich auf den Test gespannt: und siehe da, deutlich mehr Frames. Das Kollisionsobjekt war dadurch deutlich kleiner geworden und das Spiel musste bei weitem nicht mehr so viel berechnen. Offensichtlich wird bei der Kollisionsberechnung die gesamte Kollisionsbox einbezogen, und nicht nur der relevante Teil.
Dieses oben verlinkte Tut beim CS Wiki brauch ich nicht jedes mal abzuarbeiten oder da drin nachzuschauen. Das war mein Ausgangspunkt. Davon ausgehend hab ich dann den Workflow für mich optimiert. Das ganze gelösche muss ich nicht jedesmal machen, bzw. eigentlich gar nicht mehr.
Eigentlich hab ich es auch nur verlinkt, weil da drin steht, wie man vom NiTriStripsData in der Kollisionsbox zum hkPackedNiTriStripsData kommt. Weil, die Umwandlung ist ja nur ein kleiner Schritt. Steht ja aber in meinem Post mit dem Link.
Ergänzung:
Ich modelle nicht in Blender. Das nehm ich lediglich für UV-Unwrap falls nötig, oder um noch eine kleine Nachbearbeitung des Meshes zu machen, welche im Wavefront Objekt-Format nicht gespeichert würde. Deshalb muss ich dann dafür die Nifscripts nehmen.
Wenn ich jetzt ein Modell mit deutlich mehr Polygonen hätte, kann ich das natürlich nicht mehr als Kollisionsbox verwenden, sondern erstelle dann eine mit weit weniger Polygonen. allerdings werd ich grundsätzlich Objekte so in mehrere Nifs zerlegen, dass z.B. Boden eines Raumes von der Decke getrennt ist, sofern nicht nur eine simple Box als Kollisionsbox genügt.
Ergänzung 2:
Tutorials sollten schon recht ausführlich sein, und ggf. auch einen längeren, aber nachvollziehbaren Weg aufzeigen. Denn sie dienen eigentlich nur als Anhaltspunkt, und man sollte nicht ausschließlich auf Basis von Tuts arbeiten, sondern daraus lernen und sich seinen eigenen Weg suchen. Wenn man begriffen hat, wie etwas funktioniert, dann kann man mit dem Optimieren des Workflows beginnen, und Sachen, die man sonst ständig wiederholen müsste, bereits als Template (oder als Script/Macro im 2D-Prog) ablegen. Gerade bei der Methode wo die Statue als Ausgangspunkt für die Kollision verwendet wird, ist das gut möglich. Einmal bereinigen und ggf. einige Einstellungen anpassen, als extra Objekt speichern und dann einfach diese Datei als Ausgangspunkt verwenden. Auch für Waffen kann man sich gut so einen "Rohling" anlegen.
