Wie lädt man Animationen in Blender?

[HerrNamenlos123]

Hi, Vielen vielen Dank fürs Veröffentlichen!

Der Grund warum ich es brauchte, war, dass ich selbst einen Fehler habe und es helfen würde, wenn dein Importer funktionieren würde, damit ich meinen Fehler finde. Aber leider schaffe ich es nicht, eine Animation zu importieren...

Es ist Blender 3.6, richtig? Hab ich.
Beispiel: Ich importiere G3_Hero_Body_Player.xact als modell.
Danach importiere ich eine Animation. Zb: Hero_Stand_None_Tool_P0_SawLog_Loop_N_Fwd_00_%_00_P0_0.xmot
Also die Animation, wie er am Baumstamm sägt.

Blender.mp4

Es sieht so aus, wie wenn die Startposition der Animation nicht geladen wird und die Keyframes der Bones nicht auf die Startposition, sondern auf die normale Resting pose gelegt werden.

Hat das schonmal funktioniert?
Hast du Animationen getestet, die richtig geladen wurden? Wenn ja, welche?

Vielen Dank nochmal, LG Flo

[georgeto]

Hi Flo, benutzt du die aktuellste Version 0.0.3 des Addons (wurde gestern veröffentlicht)?
Damit sieht die Animation bei mir in Blender 3.6 korrekt aus und nicht so kaputt wie in deinem Video.

SawLog.mp4

[HerrNamenlos123]

Ah, ja jetzt lädt die Animation richtig. Danke.
Zwar habe ich meinen Fehler noch immer nicht, aber an der Stelle muss ich wohl mein Ego zurückschrauben und zugeben, dass es wahrscheinlich sinnvoller ist, deinen Importer weiterzuentwickeln, statt meinen, auch wenn meiner im Moment noch besser aussieht.

Einige Dinge nur, die ich gerne hätte bzw. hinzufügen würde falls ich es schaffe: Bis jetzt habe ich Rimy3D verwendet, um ein .3db (Baltram) Dateiformat zu exportieren, und dann den .3db importer, um die Baltram-Datei zu importieren. Das hatte die Vorteile, dass das Modell komplett texturiert war und die Bones richtig dargestellt werden.
Hier ein Bild:

Wie schwierig ist es, Texturen zu laden bzw. die Bones mit der richtigen Länge darzustellen?

Und ein weiteres Feature, das ich gerne einbauen würde, wären der Kopf, dass man den Kopf (oder zb. Waffen) separat importieren kann, und der auf den bestehenden Körper drauf verbunden wird.

[georgeto]

Wie schwierig ist es, Texturen zu laden bzw. die Bones mit der richtigen Länge darzustellen?

Das sollte beides eine lösbare Aufgabe darstellen. Für Bones mit der richtigen Länge und Ausrichtung muss man hier im xact-Importer die Länge berechnen und eventuell auch eine Korrekturtransformation zur korrekten Ausrichtung draufrechnen. Also eventuell mit etwas rumprobieren verbunden, aber sollte machbar sein.

Um die Texturen zu ermitteln, muss man die Materials parsen auf die die xact verweist. Das Gothic 3 Materialformat xshmat ist verstanden (g3dit kann es beispielsweise laden) und ich habe in xshmat.ksy mit einer Strukturdefinition dafür begonnen.
Auch das für Texturen verwendete ximg-Format sollte keine Probleme machen.

Und ein weiteres Feature, das ich gerne einbauen würde, wären der Kopf, dass man den Kopf (oder zb. Waffen) separat importieren kann, und der auf den bestehenden Körper drauf verbunden wird.

Sehe nicht was dagegen spräche. Die Slots für Waffen und den Kopf(?) sind ja auch im xact definiert und werden aktuell mit als Bones importiert. Die kann man sicherlich auch besonders behandeln und da dann Objekte dranhängen (sowie ich das mitbekommen kann unterstützt Blender ja Bone-Parented-Objects).

Würde mich auf jeden Fall über Mitentwickler freuen! Auch wenn du Ideen/Vorstellungen hast was man an dem Addon anders machen/strukturieren bin ich offen dafür, es ist mein erstes Blender-Addon, nichts ist in Stein gemeißelt ;)

[HerrNamenlos123]

Noch was, wie ich Baltrams Addon von Blender 2.70 auf 3.6 porten wollte (bin auch neu zu blender addons) habe ich erst realisiert, dass Blender 4.0 schon draußen ist. Ist fast wie 3.6. Seitdem arbeite ich mit 4.0, da es einfach zukunftssicherer ist. Macht also am meisten Sinn, das Addon gleich für die neueste Version zu machen.

Es gibt zwar noch keine LTS-Version, die wird aber bald kommen, da 3.6 LTS auch nur bis 2025 maintained wird.

[georgeto]

@HerrNamenlos123 Bones werden mit g3blend 0.0.6 nun in korrekter Länge und Orientierung dargestellt.

[HerrNamenlos123]

Fantastisch!

Mit der Hilfe von Baltram hab ich endlich den Fehler in meinem eigenen Importer gefunden und kann jetzt auch die Animationen importieren. Es ist zwar noch nicht so weit, dass es exportieren kann oder praxistauglich ist, aber es gibt jetzt 2 funktionierende Implementierungen für xmot-Dateien.

[georgeto]

Mit der Hilfe von Baltram hab ich endlich den Fehler in meinem eigenen Importer gefunden und kann jetzt auch die Animationen importieren. Es ist zwar noch nicht so weit, dass es exportieren kann oder praxistauglich ist, aber es gibt jetzt 2 funktionierende Implementierungen für xmot-Dateien.

Cool, sowohl dein Importer als auch das Lebenszeichen von Baltram!
Jetzt würde mich schon interessieren was das Problem war, zufällig eine fehlende Bone-Correction-Matrix?
Denn du nutzt doch die von Rimy3D erzeugten korrekt ausgerichteten Bones und kombinierst diese mit den "inkorrekt" ausgerichteten Animationsdaten aus der xmot.
Ich hatte diesen Zwischenzustand gestern und es sah nicht schön aus... 😱

[HerrNamenlos123]

Ja, ich habe Baltram schon vor über einem Jahr angeschrieben weil ich dachte, dass er einfach gigantisches Wissen hat über alle Piranha Bytes Dateiformate, da er ja Rimy3D geschrieben hat und bis auf xmot fast alle Dateiformate konvertiert werden können.

Am Anfang hatte ich nur das Parsing der Datei und wusste nicht was ich mit den Rohdaten machen soll. (Und ja, mein Held ist über einen Zeitraum von 2 Jahren auf alle möglichen Arten explodiert und deformiert worden). Baltram hat mich dann auf seine mimicry codebase verwiesen, bzw beschrieben was man alles transformieren muss. Hat bei mir aber nicht viel besser gemacht.

Viel später habe ich es wieder aufgegriffen und ihn nochmal gefragt weil ich einfach nicht wusste, wie dieses ganze Koordinatenzeug in Blender funktioniert, bzw. wie es anders ist in Bezug auf Genome. Er hat mir dann Pseudocode gegeben, der mit Matrizen die global und local bone location umrechnet und damit hatte mein Modell erstmalig die richtige Pose, nur komplett falsch ausgerichtet. Aber prinzipiell richtig.

Und dann hatte ich noch mein letztes Problem, wo ich auch nach deinem Importer gefragt hab (durch einen Reddit Post und Auronen, weil ich jemanden an Boot holen wollte damit mein Aufwand nicht umsonst ist). Und zwar hatten die Bones die richtige Pose, aber das Mesh war mehrere male in sich selbst verdreht.

Nach einiger Zeit hat Baltram geantwortet und gemeint, er ist endlich draufgekommen. Er meint, sein Verständnis vom Koordinatensystem war all die Jahre falsch und jetzt ist er draufgekommen wie die Orientation tatsächlich ist, was dazu führt, dass zusätzlich zu allen anderen Transformationen jeder Bone 270 Grad um sich selbst gedreht werden muss.

Zusätzliche Bone correction matrix eingeführt und der Held wird inkl. Mesh richtig dargestellt.

[HerrNamenlos123]

Das komplizierteste war die Umrechnung, da in xmot alle locations und rotations global sein dürften, aber in Blender muss man die animierte Pose relativ zur Resting pose machen, d.h. man muss vorher einige male umrechnen bzw. Matrizen voneinander abziehen.

[HerrNamenlos123]

Ich habe auch probiert, mal normale Meshes zu verändern und den ersten Schritt zu gehen in Richtung Mini-Total conversion mod (z.b. alternative Ankunft in Myrtana nach Gothic 2, aber nur innerhalb einer einzigen Stadt). Ich habe es aber nicht geschafft, Modelle fehlerfrei in Blender zu Im-/Exportieren.

Ich hatte so ein separates Mesh conversion programm (https://www.worldofgothic.de/dl/download_531.htm) und ich habe es auch mit Rimy3D probiert, aber in allen Fällen war das Mesh zwar verändert, aber das Lighting war falsch (Hauswände sehr dunkel, fast schwarz). Muss man extra was machen für das Lighting? Oder was ist der aktuell beste Weg, um Meshes wie zb. Häuser zu verändern?

[georgeto]

Ich hatte so ein separates Mesh conversion programm (https://www.worldofgothic.de/dl/download_531.htm) und ich habe es auch mit Rimy3D probiert, aber in allen Fällen war das Mesh zwar verändert, aber das Lighting war falsch (Hauswände sehr dunkel, fast schwarz). Muss man extra was machen für das Lighting? Oder was ist der aktuell beste Weg, um Meshes wie zb. Häuser zu verändern?

Ja, die (statische) Beleuchtung, das ist so eine Sache in Gothic 3. Die bestehenden Tools berechnen da Teile in .xcmsh (statische Meshes) und .xact (animierte Meshes) nicht korrekt. Glücklicherweise enthält Gothic 3 aber alle Logik, um diese für die Beleuchtung relevanten Information zu errechnen.

Habe vor ein paar Jahren mit Script_ModMe eine kleine Sammlung von Utilities für Modder in Gothic 3 eingebaut. Für statische Meshes kann man damit die "spatial hierarchy" und die "lightmap UV groups" berechnen lassen. Für animierte Meshes kann man damit die AmbientOcclusion berechnen lassen.

Für die statische Beleuchtung der Welt benutzt Gothic 3 Lightmaps, welche man neu berechnen lassen muss wenn man neue statische Objekte oder Lichtquellen in die Welt einbaut, ansonsten hat man eine kaputte Beleuchtung so wie etwa die schwarzen Hauswände von denen zu berichtest. Auch dafür bringt Script_ModMe etwas mit, nämlich den CompileLightmaps Konsolenbefehl.

Auch der Quellcode zu Script_ModMe ist einsehbar, es ist eines der gothic3sdk Beispiele.

[HerrNamenlos123]

(Du könntest in den Repo Einstellungen Discussions aktivieren, das finde ich recht angenehm zum Schreiben)

Und noch was:
Ich bin kein Fan davon, wie aktuell Modpacks gehandlet werden. Es gibt nur gigantische Mods mit Installer und 5000 mini-patches, aber keine Möglichkeit sich bestimmte Patches rauszupicken, außer im Modpack Installer. Man muss aber mit vielen vielen anderen Änderungen leben, die man nicht einstellen kann.

Viel lieber hätte ich ein System, wo man ein Modkit hat und in Unterordnern einzelne Mods schreibt, die jeweils nur eine Sache verändern. Dann kann man sich beliebige Mods aussuchen, bzw einen Modpack installer machen, der x viele davon installiert, indem er Ordner reinkopiert. Ich glaube in Gothic 2 geht das so ähnlich mit VDF Dateien, da hab ich aber keine Ahnung davon. Es müsste nur so sein, dass man innerhalb davon wirklich alles ändern kann, sonst gibt es wieder 50 verschiedene Arten, Mods zu installieren.

Ich habe ein System entwickelt für Lua-Skripting:
Ich nenne es GenomeScript: https://github.com/HerrNamenlos123/GenomeScript
Es ist aktuell nur ein Experiment. Es ist ein System, wo mittels der Detours Library und sehr wenig code Hooks injected werden. Im GenomeScript Ordner macht man Unterordner und darin main.lua. Diese "Mods" werden in alphabetischer Reihenfolge geladen. D.h. man kann die Priorität der Mods mit 01_... bestimmen. Jedes mal wenn eine Hook aufgerufen wird, geht das System durch alle Mods in alphabetischer Reihenfolge und in denen, in denen die Funktion global definiert ist, wird sie aufgerufen.

Standardmäßig wird nur die Hook ausgeführt und dann trotzdem die originale Funktion. D.h. solange alle Mods kein PreventDefault machen, sollten in der Theorie alle Mods kompatibel sein.

Will man den Default ändern, kann eine Funktion in Lua PreventDefaultAsSuccess(), PreventDefaultAsFailure() oder PreventDefaultWithValue(returnvalue) aufrufen. Das geht trotzdem durch alle Mods durch und der Stand der nach der letzten Mod erreicht ist, wird gemacht (Also early-return mit true oder false, ohne die originale Funktion auszuführen). Man kann auch die originale Funktion in Lua aufrufen, und auch andere. z.B. man kann in Lua auch die Fight Music durch die Victory Music ersetzen, indem man am selben Music-Objekt die andere Funktion aufruft und den default prevented.

Das macht z.B die DisableCombatMusic Mod im examples Folder. Andere Mods können trotzdem denselben Trigger verwenden, obwohl diese Mod ihn "deaktiviert".

Aktuell wird immer gescannt ob die Funktion die man aufrufen will, existiert. Wenn man den dev-mode deaktiviert könnte man in Zukunft auch nur einmal die Funktionen scannen und cachen, und es damit nochmal um einiges schneller machen. Gerade wenn der Lua-Code nur selten läuft und nicht jedes Frame, sollte man kaum etwas merken.

Außerdem wird Hot-reload unterstützt. Jede "Mod" hat einen separaten Lua Kontext, d.h keinen gemeinsamen Speicher. Wenn das Spiel läuft und main.lua verändert wird, wird die Datei sofort neu geladen. D.h. man kann in Echtzeit Mods entwickeln. Man sollte beachten, dass Funktionen ihre älteren Versionen überschreiben, d.h man kann Funktionen live ändern. Löscht man sie, sind sie aber noch immer aufrufbar, weil der Kontext erhalten bleibt bis man das Spiel neu startet.

Die Frage ist jetzt, welche Features man alle braucht, um viele Mods so entwickeln zu können. Idealerweise wären auch Meshes, Animations, Sounds, etc. im gleichen Ordner mit der gleichen Hierarchie. Am liebsten hätte ich dann eine Mod die die Combat Music verhindert, eine Mod die das Kampfsystem verbessert, eine Mod die neue Sounds hinzufügt, etc. und man kann sie sich selbst zusammenbauen indem einfach die Ordner existieren. Ich hatte auch für jede Mod z.B eine toml-config-datei geplant, mit der man in einem einheitlichen System jede Mod konfigurieren kann und vom Modder vorgegebene Parameter ändern kann (oder die Mod komplett deaktivieren).

Das Ziel des gesamten Systems ist, ein extensible Modkit zu haben, wo man beliebig viele Mods installieren kann, die sich nicht überschneiden, und das mit nur einer Hook für alle Mods, und nicht 5 Hooks pro Modpack.

Test1->gCScriptProcessingUnit_sAICombatMoveInstr verändert die Geschwindigkeit von Animationen per Animation. So hab ich z.B die normale Schwertanimation und die PierceAttack schneller gemacht, aber die Rechtsklick-Animation gleich gelassen. Wahrscheinlich nicht der beste Weg zum Ziel, aber soll zeigen was alles möglich ist. Du kannst dich mal spielen damit, ich finde es cool wenn man einfach den Lua-Code ändert und die Änderung live übernommen wird ins Spiel. Bei manchen Live-Änderungen muss man allerdings vorsichtig sein, damit es nicht crasht.

[georgeto]

(Du könntest in den Repo Einstellungen Discussions aktivieren, das finde ich recht angenehm zum Schreiben)

Guter Vorschlag, habe Discussions aktiviert und das Issue in eine Discussion konvertiert.

[HerrNamenlos123]

Und eine Mod, die ich so gerne implementieren würde, wäre die Better Combat mod, ich weiß nur noch nicht genau wie. Die würde bestimmte Hooks verwenden und komplett in Lua einen Counter haben oder so ähnlich, und durch andere Hooks herausfinden ob und wann man bestimmte Skills gelernt hat. Und je nachdem welche Skills man hat wird die Kampfanimation auf eine andere xmot-Datei umgeleitet. Ich will das Kampfsystem-Leveling von Gothic 1 und 2 recreaten, optimalerweise in Lua und einem asset Ordner mit xmot-Dateien, und einer Toml-Datei wo man das System (ebenfalls live) parametrisieren kann.

EDIT:
Durch das GenomeScript System wäre sie mit allen anderen GenomeScript Mods kompatibel, sogar wenn diese die gleichen Hooks verwenden

[HerrNamenlos123]

Ich habe gerade g3blend 0.0.6 getestet und die bones sind alle richtig. Aber mir ist aufgefallen, dass das Modell jetzt 180 Grad gedreht ist. Vorher war Y+ vorne, das war bei mir und bei Rimy3D so und ich glaube bei dir auch. Jetzt ist aber Y- vorne, wenn ich .xact importiere. Ist das beabsichtigt? (Kann aber auch sein dass es vorher so war und Baltram und ich einfach anders haben als du...)

[georgeto]

War auch schon mit 0.0.5 so. Wenn man möchte kann man es beim Import umstellen (bei Forward -Z anstatt Z auswählen).
Ob jetzt Y+ oder Y- zu bevorzugen ist, d.h. ich den Standardwert änern sollte, kann ich gar nicht sagen. Weißt du ob es in Blender eine Konvention hinsichtlich der Ausrichtung von Charakter-Modeelen gibt?

[HerrNamenlos123]

Dann ists eh egal. Nein, ich hab keine wirkliche Vorerfahrung mit Blender. EDIT: vergiss den letzten Teil :)

[georgeto]

Habe nun inzwischen zufällig herausgefunden dass Y- die Konventation für vorne in Blender ist.
Denn wenn ich View->Viewpoint->Front (Keypad 1) auswähle schaut die Kamera aus Y- Richtung.