3D-Grafikformate (Animationsfähig)

[starcow]

Tach liebe Programmierer Gemeinde! :-)

Zur Zeit stehe ich grad vor dem Problem, 3D-Modelle samt Animationen in ein game-engine-taugliches Format zu bringen.
Bislang hatte ich nur statische Modelle als OBJ-File exportiert. Animationen hatte ich dabei nur Software intern genutzt und dort gerendert.
Da ich aber je länger je mehr Game-Ready-Modells sammt Animationen erstellen werde, muss diese Export Frage mal geklärt werden.

Hat sich heute mittlerweile ein defakto Standard für 3D-Modelle mit Animationen durchsetzen können? Gibt es ein Format das "sinnvoll" organisiert und überschaubar ist?
Am OBJ-Format schätze ich so, dass ich immer den Überblick über die produzierten Daten habe. Da konnte ich sogar teilweise von Hand in einem Editor kontrollieren, ob der Export richtig funktioniert hatte und z.b die Normalen auch mitexportiert wurden.

Beim fbx Export bin ich dagegen ganz dem Willen des Exporters ausgesetzt, und wenn etwas nicht funktioniert, ist es für mich nicht möglich die genaue Ursache zu erkennen.
Vielleicht klingen diese Fragen ja alle bisschen abstrakt. Aber vielleicht könnt ihr mir da eine Art Workflow empfehlen?
Wäre es z.b möglich eine FBX Datei per Skript oder Programm selbst zusammenzusetzen?
-> Ich habe ein OBJ vom Modell
-> Ich exportiere in einem separaten File die Nulls (also Bones) mit den Weights zu den entsprechenden Vertices.
-> Ich exportiere die geplottete Animation der Nulls
-> Dann generiere ich aus diesen Daten das fbx file, so das sichergestellt ist, das auch tatsächlich nur diese Daten im File drin sind und nicht noch unnötiger Balast.

Eine andere Möglichkeit wäre doch, ein OBJ File je Frame zu exportieren und dann diese OBJ-Files in ein fbx File zu konvertieren.

Dazu müsste man natürlich die fbx konventionen kennen (oder zumindest den Teil, den man hier verwendet).
Wie schätzt ihr als Profis die Komplexität eines solchen Programmes oder Skripts ein? Ist sowas möglich oder sinnvoll?

Gruss starcow

[kimmi]

Ich würde eher auf ein Format wie beispielsweise Collada setzen und das Importen via Assimp durchführen. Obj ist für Animationen nicht gedacht gewesen und heutzutage etwas angestaubt.

Gruß Kimmi

[dot]

Ich würde auf FBX setzen, gibt's auch als ASCII Variante... ;)

[Slin]

Als relativ Spieltaugliches Format gibt es das X Format (.x), das unterstützt alle relevanten Features und ist noch einigermaßen übersichtlich aufgebaut, wird aber nicht soo breit unterstützt.
Als offenes und recht gut unterstütztes, aber für Spiele total überdimensioniertes Format gibt es Collada (.dae) und dann gibt es eben noch fbx.

Letztlich nutzt jede Engine ihr eigenes Format, dass sich dann ziemlich schnell laden lässt und dann werden entsprechend möglichst breit Konverter zur Verfügung gestellt. Als Ausgangsformate sind normalerweise Collada und FBX geeignet, da diese zusammen ziemlich weit verbreitet sind, wobei eventuell Collada sogar ausreicht.

obj Dateien für jeden Frame exportieren und dann daraus was anderes zu generieren kann man sicherlich auch irgendwie machen, wenn du aber mit Skelettanimationen angefangen hast, dann nimmt die Dateigröße dabei extrem zu und es geht seht viel an Flexibilität verloren und das willst du definitiv nicht.
Die beste Möglichkeit um zu überprüfen ob alles da ist nach dem Export, ist es das Modell anschließend in irgendeinem Tool zu öffnen und nachzugucken.

[Tiles]

Von X rate ich ab. Wie du richtig bemerkt hast verwendet es kaum noch jemand. Aus gutem Grund. Zu viele inkompatible Derivate und Versionen. Selbst Microsoft, der Erfinder von X schreckt davor zurück es zu verwenden. Das ist ein Auslaufmodell.

Für Animationen bist du im Moment mit Collada oder FBX am besten aufgehoben. Collada hätte den Vorteil dass es frei ist. Ist aber nicht so verbreitet wie FBX. Für FBX gibts übrigens auch ein SDK. Mit entsprechenden Lizenzdingern hinten dran halt.

[Slin]

Von X rate ich ab. Wie du richtig bemerkt hast verwendet es kaum noch jemand. Aus gutem Grund. Zu viele inkompatible Derivate und Versionen. Selbst Microsoft, der Erfinder von X schreckt davor zurück es zu verwenden. Das ist ein Auslaufmodell.

Wenn man sich die Doku so anguckt macht es eher den Eindruck als hätte sich da seit DirectX 3 nichts mehr am Format geändert?
Aber ja, mittlerweile ist die Renderpipeline so anpassbar, dass eigene Formate die direkt dazu passen sinnvoller sind und ich denke auch deshalb wird .x von Microsoft langsam fallen gelassen. Aber ich sehe nicht wie das an Inkompatibilitäten liegen soll?

FBX auf der anderen Seite ist mit den verschiedenen Versionen wirklich mist. Wird aber eben trotzdem insbesondere durch Autodesk Software für die es ja auch entwickelt wurde unterstützt. Das SDK ist übrigens auch nicht wirklich toll zu nutzen. Ich hab auch schonmal einen Collada parser geschrieben, aber bei den Texturkoordinaten bin ich dann verzweifelt weil es irgendwie 10 verschiedene Möglichkeiten gibt wo die sein können und nirgends klar referenziert werden. Okay ist vielleicht nicht so, aber zu dem Zeitpunkt fand ich das ganz schrecklich :P.
Trotzdem ist Collada aus meiner Sicht gut geeignet, da es sowohl von Blender als auch von Assimp gut unterstützt wird und von daher eine gute Basis zum konvertieren in ein eigenes Format bietet.

[Tiles]

Aber ich sehe nicht wie das an Inkompatibilitäten liegen soll?

Inkompatibilität deswegen weil jede Rendersoftware da ihr eigenes Süppchen gekocht hat. Und X war von Anfang an auch eher zum export zur Game Engine gedacht. Nicht zum Austausch. Und dementsprechen grosse Schwierigkeiten bekommst du wenn du ein X zum Beispiel in Blender reinladen willst. Kann funktionieren, wenn du ganz viel Glück hast. Je nachdem wo es herkommt :)

[starcow]

Danke für eure Antworten!
Ich habe jetzt die ganze Import und Export Geschichte mit dem COLLADA Format ausprobiert. Das funktioniert wirklich sehr gut (im gegensatzt zu FBX).
Ich bin ziemlich begeistert von dem Format - es ist ja sogar im Klartext lesbar.
Habt ihr vielleicht eine gute Quelle zu den Spezifikationen?

Gruss starcow

[Schrompf]

https://www.khronos.org/collada/

Erster Treffer bei der Suche nach "Collada Specification" :-) Aber sei gewarnt: das ist kein Format, dass man nach einem Nachmittag Tüfteln lesen kann. Ich habe einige Wochen dafür gebraucht und es werden auch heute noch Fehler und Inkonsistenzen dafür gemeldet.

[starcow]

... und es werden auch heute noch Fehler und Inkonsistenzen dafür gemeldet.

Das ist natürlich weniger erfreulich :-/
Ich hoffe solche Problem lassen sich umschiffen.
Dank dir Schrompf!

[Tiles]

Ich bin ziemlich begeistert von dem Format - es ist ja sogar im Klartext lesbar.

Das geht aber auch bei FBX. Das kannst du sowohl im Binary als auch im Ascii Format speichern.

[Spiele Programmierer]

Ich finde es äußerst fragwürdig, große Mengen Modelldaten in Textform abzulegen.
Nicht bloß, das es die Dateigröße in die Höhe treibt und die Ladezeit erhöht, es ist in der Regel auch noch komplexer ein Textformat zu parsen, als einfach Binärdaten einzulesen. (Bei XML vielleicht nicht unbedingt, dafür sorgt es auch für einen noch größeren Overhead)
Niemand wird heute auf die Idee kommen, Modelldaten in Textform zu bearbeiten. Weshalb also das Ganze?
Von Collada halte ich für Modelle auch nicht wirklich viel. Das Format ist extrem aufgeblasen mit jede Menge für Spielmodelle unnötigen Funktionen.
Insgesamt langfristig das beste Nutzverhältnis sehe ich persönlich immer noch in einen eigenen Binärformat.
Es können alle Daten optimal für die jeweilige Engine gespeichert werden, es gibt keinen Overhead und ein einfaches Binärformat zu entwickeln, ist ein geringerer Aufwand, als so etwas wie Collada umzusetzen. Natürlich braucht man dann aber auch noch irgendein anderes Zwischenformat um die Modelldaten erstmal in das eigene Format zu bekommen.

[Tiles]

Niemand wird heute auf die Idee kommen, Modelldaten in Textform zu bearbeiten.

Du wirst lachen, auch das kommt heutzutage noch vor. Ich selber stocher zum Beispiel für mein Leben gern in der *.mtl Datei eines Obj Modells rum um den Texturpfad oder das Shading anzupassen ohne das Modell laden zu müssen :)

Der Zweck von FBX, Collada und Co liegt aber weniger im internen Benutzen innerhalb einer Spieleengine. Da ist ein Hausformat tatsächlich besser, da gebe ich dir Recht. Sondern im Dateiaustausch zwischen Engine und Grafiksoftware. Die Pipeline. Und weil es da hier und da klemmen kann weil jeder Softwarehersteller das Wörtchen Spezifikation anders definiert ist die Lesbarkeit in einem Textformat manchmal ein echter Pipelineretter.

[starcow]

Da kann ich Tiles nur zustimmen.
Du kannst ja nicht ohne weiteres einfach so ein Plugin für deine 3D-Grafiksoftware schreiben, nur weil jetzt bei einem Projekt mit einem bestimmten Format gearbeitet wird.
Was es halt braucht ist einen gewissen Standard.
Und ich behaupte jetzt einfach mal, das es doch ein deutlich geringerer Auwand ist, ein Programm zu schreiben, das eine COLLADA Datei in ein spezielles Engine-Format transportiert, als ein eigenständiges Plugin für die Software XY.
Und ich persönlich bin ein grosser Fan von Klartext Dateien. Einfach weil ich dort die Möglichkeit habe, zu prüfen ob der Export geklappt hat, und falls nicht, an was es liegt.
Für mich ist es wichtig zu wissen, das meine Modelle keine Fehler aufweisen. Wenn ich z.b die Situation habe, dass ich Modelle für jemanden gestalte und dieser meldet mir dann zurück, das die Modelle "nicht funktionieren", habe ich bei klartext Dateien die Möglichkeit dies zu überprüfen und kann die andere Seite gegebenfalls darauf hinweisen, das die Datei funktionieren muss - und es sonsten ein Problem des Importers ist.

[Spiele Programmierer]

Zum Datenaustauschformat ist wie COLLADA schon geeignet. Aber weniger als Modellformat im Spiel. Ich finde, es ist wichtig, da zu differenzieren.

Zum Überprüfen gibt es auch gute Hex-Editoren, da sehe ich kaum einen großen Nachteil.
Meiner Meinung nach werden Textformate absolut inflationär eingesetzt, weil die Lesbarkeit in der Praxis in vielen Fällen irrelevant ist.

[Schrompf]

Aber es steht doch ganz am Anfang des ersten Beitrags

Zur Zeit stehe ich grad vor dem Problem, 3D-Modelle samt Animationen in ein game-engine-taugliches Format zu bringen.

Das ist doch genau das, wofür Du hier gerade argumentierst, oder? Wir sind also alle der selben Meinung :-)

[starcow]

Zum Datenaustauschformat ist wie COLLADA schon geeignet. Aber weniger als Modellformat im Spiel. Ich finde, es ist wichtig, da zu differenzieren.
Zum Überprüfen gibt es auch gute Hex-Editoren, da sehe ich kaum einen großen Nachteil.
Meiner Meinung nach werden Textformate absolut inflationär eingesetzt, weil die Lesbarkeit in der Praxis in vielen Fällen irrelevant ist.

Aber es steht doch ganz am Anfang des ersten Beitrags

Zur Zeit stehe ich grad vor dem Problem, 3D-Modelle samt Animationen in ein game-engine-taugliches Format zu bringen.

Das ist doch genau das, wofür Du hier gerade argumentierst, oder? Wir sind also alle der selben Meinung :-)

Stimmt schon. Ich habe das Anfangs wohl auch missverständlich ausgedrückt. Es ging mir darum ein 3D-Format zu finden, das für alle lesbar ist, und wo man die Daten auf einfache Weise rausbekommt. :-)

Gruss starcow