Am effektivsten nutz man ein ik system also eine Bone struktur welche dann animiert wird.
Also speichert man die matrix(4x4float array)und ein passenden timestamp von jeder änderung.
Die Daten werden dann interpoliert um flüssige animationen zu realisieren.
Normalerweise kann man noch sogenannte Weights für die einzelnen Vertice in bezug zu einen Bone setzten.
Dies erlaubt ünterschiedlich starke transformierungen von vertice, wenn ein bone bewegt wird.
Der Vortteil ist man kann dies über ein vertex program und displaylist oder vbo überdimensional schnell verwirklichen.

Also z.B.

Bonesetting=record
wheight:single;
boneid:cardinal;
end;

Vertice=record
...
Bonecount:cardinal;
Bonesettings:array of Bonesetting;
end;

Bone=record
id:cardinal;
parent:Bone;
child:Bone;
Matrix:TGLMatrixf;
end;

Animationsstep=record
boneid:cardinal;
matrix:TGLMatrixf;
time:cardinal;
end;

Es gibt natürlich noch mehr Möglichkeiten wie z.B. das speichern jedes frames(mdl format macht das) der animation und deren interpolation ist aber speicherintensive, wenn man mehere animationen hat.
Bones ist aber der beste Weg.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Irgendwas stimmt an deiner Erklärung nicht( Vom Quelltext her ).
Das man jeden Frame einzelln Speichern kann wusste ich, das andere Prinzip habe ich noch nicht ganz verstanden!
Bisher dachte ich man hat Knochen( Bone oder? ), die eine bestimmte länge haben. Jeder dieser Knochen hat Flächen( Das Modell ), was in einem bestimmten Verhältniss zu dem Knochen steht( Mit einem freiraum ). Nun wird bei einer Bewegung der Knochen verschoben, und die Flächen, je nach Bewegung verändert.

Ich weiss nicht ob das richtig ist, von daher bitte ich nochmal um Erklärung!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Also ganz grob gesagt:

Man hat seinen Mesh (Das Model) und man hat seine Bones. Zusammen ergebn die beiden den sog. Flesh.

Jedem Bone werden einige Vertices zugeordnet, so dass jeder Bone mehere Vertices oder auch gar keinen hat und jeder Vertex genau einen Bone. Wenn man jetzt einen bone mit Vertices dran dreht, dann drehen sich die, dem Bone zugewiesenen Vertices um den Ursprung des Bones mit. Daher bleiben die Vertices eigentlich immer um den Bone angeordnet.

Wenn man zusätzlich Weight mit ins Spiel bringt, dann hat nicht jeder Vertex genau einen Bone, sondern mehrere (2?). Daher wirkt sich die Transformation eines Bones nur etwas auf einen solchen Vertex aus. Sagen wir mal zu 50%. Ein anderer Bone hat auf diesen Vertex auch 50% Einfluss. Somit werden die Bewegungen ... flüssiger...

Ist in den Tutorials von 3ds Max ganz gut beschrieben

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Ich hab erstmal meine erste Variante ins wiki gestellt.
Beim schreiben

@SpeedMaster
Du Hast ein Skelet bestehend aus Bones, jeden Bone werden Vertice zugewiesen mit einem Wert Wheight legt man fest wiestark die bewegung das Vertice beeinflusst. Je nach bonesystem sind Bones in ihrer Länge festgelegt und können auch childs beeinflusse. Animationkeys sind dann der 2. Part hier kann man veränderungen jedes Vertice, Bones festhalten oder einfach jeden Frame festhalten. Die beste variante ist das festhalten von verändrungen der Bones.
Dies kann man am schnellsten und leichtesten über ne matrix da da alles drin ist und opengl nun mal mit matrizen arbeitet.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Habe meine Idee mal überarbeitet und das Ergebniss findet ihr hier: http://wishlist.delphigl.com/index.php/ ... KMF-Format

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Ich weis ja nicht wer von euch schonmal Modelle animiert hat. Ich habe bisher nur mit Keyframes unter Blender gearbeitet.(Sprich man legt Eigenschaften von Objekten zu bestimmten Zeitpunkten fest. Und editiert dann die daraus enstehende Kurve)

Ich habe mir schwer getan was vernünftiges zu finden. Dahe poste ich mal hier einen Link zu einen "Workshop" den ich gerade entdeckt habe und sehr vielversprechend aussieht.

http://www.elysiun.com/forum/viewtopic.php?t=33060

Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Habe mein Format heute nochmal etwas genauer beschrieben, ich bitte euch mal euere Meinung dazu abzugeben!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Warum nicht einfach das .x Format verwenden. Da gibt es Exporter für alle Modeller. Das Format ist selbstbeschreibend, universell und es gibt sowohl eine Text als auch eine binäre Version.

Warum es sich leicht machen wenn es schwer geht? oO

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Wieso hat dann noch nie hier einer einen x Loader geschrieben?
oder falls es jemand gemacht hat wieso wird der dann hier nicht öffentlich genutzt?
Und wieso entwerfen so viele Spielefirmen ihr eigenes Format?

Wollen wir überhaupt dieses Format verwenden?

Ich hab mal auf die Projektseite geschrieben was als nächstes geplant ist.
http://wishlist.delphigl.com/index.php/ ... Fileformat

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut

Ich denke mal, dass es ziemlich schwierig sein dürfte ein so universelles Format zu schreiben mit dem alle spezial sonder Fälle abgefertig werden können und ohne, dass es zu überfrachtet ist. Wenn es um ein Format für Modelle geht dürfte jeder seine eigenen speziellen Vorstellungen haben. Sicherlich können viele Formate das auch abdecken aber entweder fallen dann Lizensgebühren an oder man hätte noch 20 nicht genutzte Funktionalitäten die man mit rumschleppen müsste. Außerdem macht es bei sehr großen Projekten (Spielen) auch schon Sinn, wenn man ein wenig auf die Größe der Dateien achtet. Außerdem kann ein "offener Standard" sehr schnell zur Verfremdung des Spieles führen. Und das liegt sicherlich nicht im Sinne des Herstellers. Das sollte man auch nicht außer acht lassen.

Da das Thema doch schon ziemlich weit vom eigentlich Newsbeitrag entfernt ist, sollte es geteilt und ein Communityprojekt draus gemacht werden. Sollte jemand etwas dagegen haben so soll er jetzt sprechen oder für immer schweigen.

Also zur größe muss ich sagen, das das eigentlich heute kein Problem mehr darstellen sollte. Größe mag ja schön und gut sein, aber IMHO sollte die lesbarkeit, und die Möglichkeiten vor der Größe stehen.

Edit:
Habe mein Format atm noch falsch eingeordnet, vielleicht könnte jemand die Vor- und Nachteile zu meinem Vorschlag noch dazuschreiben, dann kopiere ich die Informationen über das eigentliche Format in den anderen Part!

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Ja, viel wichtiger ist die Flexibilität. Die Daten sollen auch noch in Zukunft gut lesbar sein. Bei einem Text Format wie XML kann man das ganze immer auslesen, bei einem binären Format ist man dann an die Spezifikation bzw, den DGL Format Loader gebunden. Da denke ich sollte man das bißchen Geschwindigkeit und den Platz ruhig für ein Text basiertes Format opfern. Die Doom3 Levels und Modelle sind ja auch alle als Text gespeichert.
Auf Gamedev.net ist ein Tutorial zum Laden von .x Dateien. Der Vorteil ist eben dass es so allgemein ist. Zum Beispiel hat ja auch nicht jeder die gleichen Vertex Attribute. Es gibt bei Developia (ja seltsamerweise dort) eine .x Exporter für Cinema4D, auch für die kostenlose Version die mal beim PC Maganzin war.
http://www.gamedev.net/reference/progra ... s/xfilepc/

Mein Vorschlag ist entweder ein eigenes XML Format. Ob im Zip oder nicht kann ja jeder selbst entscheiden. Dank der zlib Unit kann man zip's leicht lesen/schreiben. Oder das ganz normale .X Format eben.

Meiner meinung nach sollte unser Format auch Animationen beinhalten. Weils einfach keine Offenen Formate gibt, die man zu sowas benutzen kann. Ich weiß nicht ob das *.x Format das kann... Wenn nein, könnte man ja das als ausgangsbasis für das DGLFormat machen. (*.dgl )

Auf alle Fälle hätte man mit so einem Format einen guten ansatzpunkt um für Projekte hier auf der Page, Mesh zu erstellen. Außerdem kann dann hier an zentraler stelle ein Loader gebaut werden der kostenlos verteilt wird, und somit hoffentlich auch zur verbreitung unseres Formates beiträgt. Wenn wirs schaffen die "eierlegende Wollsau" (auf die Milch wird man wohl verzichten müssen) zu erschaffen ... kann nur gut sein für DGL.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich denke, dass es am Sinnvollsten wäre, eine Binärdatei zu nehmen, da diese einfach schneller zu laden sind,
was das Argument mit Doom3 angeht, so denke ich, dass es bei Doom3 auf die paar Sekunden längere Ladezeit nicht ankommt, aber was ist mit Outdoor-szenen, bei denen Modelle je nach Bedarf in Echtzeit gestreamt werden müssen ? Die würden bei einem Textformat oder einem gezippten Modell ziemlich schnell in die Knie gehen.

_________________
Bevor du definierst, was etwas ist, versichere dich seiner Existenz.