Konverter: blend2gwn

Hallo,
ich wollte mal fragen, ob bei euch noch das Problem beim Laden von .blend Dateien, bzw. das konvertieren einer solchen Datei zu einer anderen besteht. Ihr benötigt ja irgendein Format, das Informationen zu den Bones beinhaltet. Ich selbst arbeite mit Cinema4d und habe kaum Erfahrungen mit Blender, bin aber auf dieses interessante Projekt gestoßen und habe gesehen, dass ihr keinen Exporter für Blender habt, der Bones in ein vernünftiges Format exportiert.
Ich selbst arbeite gerade an einer kleinen Engine, die die Modeldaten vom Cinema4D XML Format bezieht. Als ich auf dieses Projekt gestoßen bin habe ich auch angefangen ".blend"-Dateien zu laden. Bis jetzt sind es nur Triangles und Vertices, die ich aus dem Format lesen kann. Allerdings plane ich Texturen sowie Bones laden zu können.
Wenn Interesse an einem Konverter besteht, dann könnte ich in den nächsten Tagen versuchen ein Programm zu schreiben, das ".blend" Dateien in ein leichter lesbares und auch kleineres Format konvertiert. Leider kann ich kein Pascal, sodass ich nicht aktiv an gwX programmieren kann, aber wenn ich kann, dann versuche ich euch und gwX zu unterstützen. Eventuell mit einem Konverter, aber sicher auch noch auf anderen Weisen.

nyon

sehr schöne idee..aber im endeffekt muss du wohl noch auf carli wardn

ein konverter hmm , jo das hatten wir ja gesucht , wäre super , wenn du sowas hinbekommen würdest, wegen dem loader müsste man aber wirklich noch auf carli warten

das würde sicher sehr viel bringen, wenn das so mit den bones funktionieren würden , weil dann weniger
leistung gefressen wurde-> mehr polys für die modelle & mehr modelle ingame ohne , dass es beginnt zu ruckeln

Wie macht ihr das denn im Moment? Interpoliert ihr zwischen zwei Models, um eine Gehbewegung zu bekommen?

nyon

jo glaube so läufts im mom

genau so läufts.

Erstmal danke, dass du dich hier zur Verfügung stellst.
Dass du kein pascal kannst, kannst du damit rausbügeln, dass du z.B. ne DLL schreibst, die dann eingebunden wird.
Ein Konverter vom .blend-Format zu schreiben ist eigentlich ungewöhnlich, da das .blend-Format durch Phyton entziffert wird und somit es einfacher ist direkt einen Exporter in Phyton zu schreiben. Aber wenn du meinst, du machst es auf die ArtUndWeise, OK.
Ich werd dir mal die Spezifikation des GWN-bzw. GWM-Formats geben, damit wir das 3ds-Format als Zwischending rausschmeißen können.
Lesbares Format::im Prinzip ist für den Computer jedes Format lesbar, ein Zwischenschritt wäre auch nix andres, als 3ds zu benutzen.

jo, 3ds würde ich auch gerne noch behalten, weil ich mit blender einfach nich klarkam/komme und c4d und der ganz nette 3ds-exportierer meiner meinung nach n schönes format is

unterstützt 3ds bones?

nur die allerneuste Version, die aber von meinem Converter nicht unterstützt wird

Carli schrieb:genau so läufts.

Erstmal danke, dass du dich hier zur Verfügung stellst.
Dass du kein pascal kannst, kannst du damit rausbügeln, dass du z.B. ne DLL schreibst, die dann eingebunden wird.
Ein Konverter vom .blend-Format zu schreiben ist eigentlich ungewöhnlich, da das .blend-Format durch Phyton entziffert wird und somit es einfacher ist direkt einen Exporter in Phyton zu schreiben. Aber wenn du meinst, du machst es auf die ArtUndWeise, OK.
Ich werd dir mal die Spezifikation des GWN-bzw. GWM-Formats geben, damit wir das 3ds-Format als Zwischending rausschmeißen können.
Lesbares Format::im Prinzip ist für den Computer jedes Format lesbar, ein Zwischenschritt wäre auch nix andres, als 3ds zu benutzen.

Für die DLL müsste dann ja aber allerdings auch eine Header-Datei geschrieben werden... allerdings würde diese leichter zu bewerkstelligen sein.
Lesbar sind alle, nur 3ds ist wohl leichter lesbar, bzw. leichter zu implementieren als c4dxml oder blend und Konsorten. Dafür unterstützt 3DS, aufjedenfall in den meisten Exportern, keine Bones und auch nur rudimentär Keyframes.
Ich werde in nächster Zeit mal am Loader weiterschreiben.
Das Format hatte ich mir so vorgestellt, dass es neben den Standardsachen wie Vertices und Triangles auch noch Materialien(mit optionalen integrierten Texturen, d.h. die Bilddateien sind direkt im Modelformat drin), Keyframes für Bones und das Model selber, Vertexmaps für die Bones(mein Format hat bisher leider nur eine Vertexmap pro Bone) und auch schon vorberechnete Normalen. Mich würde interessieren, wie du so ein Format aufbaust.

Für Cinema4d habe ich quasi schon einen Konverter, also vom Cinema4D XMLv9 *.xml nach *.nym.

Gruß, nyon

Also wenn ich mir ein format ausdenke, dann überleg ich mir, dass es folgende voraussetzungen erfüllt:
- einfache Struktur
- mit einem Satz (one pass) einlesbar
- muss alle benötigten Daten enthalten
- möglichst die Dateigröße klein halten (binär, keine 3*32bit für einen simplen Normalenvektor)

Vorteil eines eignen Formats:
- man hat das Urheberecht
- man weiß wie es eingelesden wird/hat schon einen Loader

Nachteile:
- man muss erst nen Konverter schreiben dafür


Jetzt noch das GWM-Format:
- 1 Integer n (4 bytes): Anzahl der Materialien
Anschließend werden n Datensätze der Materialien ausgelesen:
- 1 Integer nn (4 bytes): Anzahl der Zeichen im Materialnamen
- nn Characters (nn bytes): Name des Materials
- 1 integer m Anzahl der Meshes
Für jedes Mesh (gesamt m meshes) werden 3 Vertices angegeben (gesamt 3*m Datensätze):
- Texturkoordinate UV als 2 shortint (2*2 bytes sind 4 bytes; UV wird um 1000 skaliert; 1000 als shortint sind also 1 als float)
- Normale als 3 smallint (3*1 byte mit vorzeichen, jeweils normalisiert von -128..127 und mit 127 multipliziert)
- Vertex als 3 floats (3*4 bytes, frisst den meisten Speicherplatz)

Natürlich ist das nicht das alleroptimalste Format, da man Vertices theoretisch auch noch einen Index geben könnte, um so doppelte Ecken vom Speicher her einzusparen. Jedoch müsste man sich eine Extra-Vertex-Tabelle anlegen, jedoch wird GWM fließend eingelesen, d.H. ohne RAM zu verschwenden wird das Model von der Feltplatte heraus direkt in eine Displayliste im VRAM geladen.

Zum Thema Format. Ich habe mir mal folgendes Format erdacht. Es ist in einem Lesevorgang ladbar, hat eine einfache strikte Struktur, ist begrenzt erweiterbar und ist ziemlich klein.
Die Materialien sind so aufgebaut, dass sie Shader- oder Texturendaten direkt beinhalten können.
Kleine Legende:
float: wie ein single in Pascal, soweit ich das richtig in Erinnerung habe(4 Byte Fließkommazahl)
string: null terminierter Ansi String

Code:


Der Header:

4 char magic: GWM\0
int version: 1
string name
int materials
int vertices
int faces
int vertexmaps
int bones
int keyframes
4 int dump

Datenteil des Formates:

n materials:
  string name
  string tex
  if(tex=="dataPNG" or tex=="dataBMP" ...)
    int lengthOfFile
    * filedata/shaderdata
  color diffuse
  color ambient
  color specular
  96 char dump
 

n vertices // n * 18 bytes
  float x, float y, float z
  short nx, short ny, short nz

n faces // n * 12 bytes
  int a, b, c // die frage ist hier, ob die indices shorts oder ints (also 2 byte oder 4 byte groß sein sollen)
  short ua,va,ub,vb,uc,vc

n vertexmaps // n * (4 + m * 8)  bytes
  int entries
  m times:
    int vertex, float strength // short oder int?


n bones, // n * 32 bytes
  int boneID
  int parentID
  int vmapID
  float length
  16 bytes dump


n keyframes // n * 13 bytes
  char affector; // enum { POS_X, POS_Y ...}
  int ID // atm only boneID
  int frame
  float parameter




Wenn noch etwas fehlt, dann ergänze ich es. Müsste aber eigentlich alles drin sein. Für spätere Änderungen am Dateiformat sind die Dumpsektionen eingebaut. Sie dienen als Platzhalter, wenn noch Daten nachträglich hinzugefügt werden sollen. Man kann sie natürlich auch als Copyright oder ähnlichem missbrauchen.
Für größere Änderungen ist die Versionsnummer zuständig.

Ich habe mich für die Darstellung der Vertices über Indices entschieden, weil es sonst Probleme geben bei den Vertexmaps bzw. bei den Bones wird.

nyon

Erstmal zu den Materialien/Texturen/Shadern:
Es ist schon besser, wenn die per Script zugewiesen werden, bestes Beispiel: Die Fundament-Textur findet man in mehreren Gebäuden, die muss aber nur einmal geladen werden.


Zu deinem Bone-System fehlt noch ein Algorithmus, der die Models rendert, denn ohne den nützt das beste Dateiformat nix.

is das nich nur der header...?

schon, aber der Algorithmus fehlt eben auch dazu, bevor man das Format so einführen kann.
Mal sehn, was nyon dazu sagt

Carli schrieb:Erstmal zu den Materialien/Texturen/Shadern:
Es ist schon besser, wenn die per Script zugewiesen werden, bestes Beispiel: Die Fundament-Textur findet man in mehreren Gebäuden, die muss aber nur einmal geladen werden.


Zu deinem Bone-System fehlt noch ein Algorithmus, der die Models rendert, denn ohne den nützt das beste Dateiformat nix.

Ich habe auch erstmal versucht eine Spezifikation zu schreiben. Die Materialien sind also nicht notwendig. Gut, dann schmeiss ich sie raus. Den Algorithmus versuche ich gleich mal zu verschriftlichen, weil ich den bisher nur in C mühselig implementiert habe... Cinema4D ist in dieser Hinsicht wohl nicht so freundlich gewesen...

Edit:
Also die Rotationen beziehen sich auf ein HPB-System, d.h. es gibt keine festen Achsen XYZ sondern sich mit der Rotation drehenden Achsen. HPB steht dabei für Hue Pitch und Bank. Dazu morgen mehr.
Um Bones darzustellen müssen die Vertices wie auch oben schon genannt mit Indices gespeichert sein. Die Vertexmaps zeigen dann jeweils, welche und wie stark die Vertices bewegt werden müssen. Die Bones geben dann die Richtung an.
Es existiert dazu noch eine Hierarchie aus Bones, d.h. der Fuß-Bone steht unterhalb des Bein-Bones. Rotiert sich der Bein-Bone, so rotiert sich gleichermaßen der Fuß-Bone mit(hier fällt mir ein, dass die Bones noch eine Anpassung benötigen).
Vor dem Rendern müssen die Vertices dupliziert werden, damit sie durch die Änderung nicht permanent verändert werden und beim nächsten Rendervorgang noch im Original sind.
Zudem existiert ein Root-Bone in jedem Model, dass jeweils mehrere Children haben kann. Jeder Bone hat eine Inverse Start-Matrix, damit die Startrotation des Bones keine Veränderung am Model hervorruft, sowie eine aktuelle Matrix die durch die einzelnen Keyframes berechnet wird(wieder mit dem HPB System).
Nun wird eine Resultierende Matrix aus der Inversen Start-Matrix und der aktuellen Matrix gebildet und mit jedem einzelnen zugehörigen Vertex multipliziert. Das Resultat ist der gewünschte Vertex. Am Ende wird der selbe Algorithmus für die Children aufgerufen.
Eventuell werde ich morgen mal ein paar Codeschnipsel hier reinschieben.

Bis dahin, guten Abend.

Die Materialien haben zwar Namen, aber die Texturen werden extern übers Script gebunden, d.H. es müssen alle Meshes vom gleichen Material in eine Displayliste gespeichert werden. Diese Listen werden dann nacheinander aufgerufen mit der jeweils richtigen Textur.

Displaylisten sind bei Bones natürlich nicht möglich. Eher VBOs.

Also zum "normal"-animieren haben wir ja schon das GWN-Format (wenns auch nicht das Beste ist)
Jetzt wäre es an der Zeit, ne neue Animation einzuführen, die mit der Landschaft interagiert, ich denke da an sowas:
http://dan-ball.jp/en/javagame/ranger/

Das, was da gemacht wird, nennt sich Inverse Kinematik. Man berechnet da mithilfe von festgelegten Positionen, wie z.B. die Position der Beine, in welcher Rotation sich der Bone befindet. Darüber habe ich allerdings noch nicht so viele Artikel gelesen und ich glaube auch, dass die Implementierung dieser Technik in 3D relativ schwer werden würde. Aufjedenfall benötigt man für solch eine Technik ein Bone Hierarchie System. Ohne mich festzulegen oder Tests gemacht zu haben denke ich, dass ein Algorithmus dafür in etwa so aussehen würde:

Model befindet sich in seinem Anfangszustand.
Keyframes werden auf festgelegte Punkte übertragen und somit zu ihren Bestimmungsort bewegt.
Jeder Punkt kann das Ende eines Bones repräsentieren.
Verschiebt sich ein Punkt, so wird erst versucht den Bone in Richtung des Punktes zu rotieren, und anschließend in die Richtung des Punktes so translatiert, dass das Ende des Bones wieder auf diesen Punkt liegt.
Findet eine solche Translation statt, müssen die Eltern-Bones ebenfalls neu berechnet werden, sodass deren Enden auf dem Anfang ihres Child-Bones liegen.

Ich weiß jedoch nicht, ob das da oben auch praktisch funktioniert.
Ich denke man sollte erst die "normale" Bone-Animation, die Forward Kinematik, in gwX einbauen. Auch wenn dann die Füße des Clonks in den Boden versinken, ist das sicherlich schon mal besser und auch schneller als die Interpolation zweier Models... und auch speicherfreundlicher.


Zum Anderen sollten wir uns mal eine Art Schnittstelle überlegen, um die von mir in C++ programmierten Teile in gwX zu integrieren. Damit meine ich den ungefähren Aufbau von Funktionen. Vielleicht kann ich mich ja auch mal in Pascal versuchen, ich denke das wär einfacher. Mal sehen.

Zum Thema Forward Kinematik:

Du benötigst erstmal eine Funktion die einen Vektor um eine Achse rotiert. Ich denke mal, ohne auf deine Quelltexte genauer geschaut zu haben, dass du eine Vektorklasse oder ein Vektorobjekt hast und das auch Funktionen mitliefert um einfache Rotationen um X-,Y- und Z-Achse zu bewerkstelligen.
Ich versuch mal in eine Art Pseudocode die "freie Rotation" darzustellen:

Code:


function rotate(vector vec,vector axis,single angle)
{
  if(angle <> 0)
  {
    // calculate angle to make the axis XZ conform
    vector temp = axis;
    single a = -atan2(temp.x,temp.z);
    rotateY(temp,a);
    rotateY(vec,a);
    single b = -atan2(temp.y,temp.z);
    rotateX(temp,b);
    rotateX(vec,b);
    rotateZ(vec,angle);
    rotateX(vec,-b);
    rotateY(vec,-a);
  }
}



Die Funktion wird benötigt, um HPB-Rotationen durchzuführen. Für HPB-Rotationen eignen sich wiederrum Matrizen. Ich denke mal, solch ein Objekt oder solch eine Klasse hast du auch schon bereits in gwX implementiert.

Pseudocode:

Code:


function rotateHPB(matrix mat,single heading,single pitch, single bank)
{
  vector right(mat[0],mat[4],mat[8]);
  vector up(mat[1],mat[5],mat[9]);
  vector view(mat[2],mat[6],mat[10]);

 
  rotate(right,view,bank);
  rotate(up,view,bank);

  rotate(view,right,pitch);
  rotate(up,right,pitch);

  rotate(view,up,heading);
  rotate(right,up,heading);

  mat[0] = right.x;
  mat[4] = right.y;
  mat[8] = right.z;

  mat[1] = up.x;
  mat[5] = up.y;
  mat[9] = up.z;

  mat[2] = view.x;
  mat[6] = view.y;
  mat[10] = view.z;
}


Hiermit lassen sich alle Rotationen, die in Cinema4D XML gespeichert sind und somit auch für die Bone Animation gebraucht werden, beschreiben.

Morgen schreibe ich dann, wie die einzelnen Matrizen für die Bones berechnet werden können... das lässt sich gut mithilfe der von OpenGL mitgelieferten Funktion glPushMatrix und glMultMatrix machen.

nyon

Da kommt mir eine Idee:
gwX sollte von der Engine her aufgeteilt werden, die Module möglichst in DLLs auslagern.
Dabei soll es vorerst nur eine Delphi- und eine C++-DLL geben. (um in beiden Sprachen Funktionen einbauen zu können), sowie die Scriptengine gesondert.

Derzeit arbeite ich an einer eigenen Programmiersprache, die bereits soweit ist, dass sie eine importierte DLL-Funktion aufrufen kann (die gwX-Exe wäre dann sage und schreibe 3KB groß).

Sinn des ganzen: Man kann die Engine in jeder beliebigen Sprache schreiben, das Ziel soll aber sein, alles in FastCode da zu haben (weil diese Sprache vom Konzept her sehr modern ist)

die gwX-Exe wäre dann sage und schreibe 3KB groß

zOMG
Würde ich sehr begrüßen von wegen modulares System. Zum Beispiel die Scriptlib könnte dann wohl auch mit dem FPC compiliert werden (der hat seine Probleme eher bei dem OGL-Zeug)

bin grad dabei, eine einheitliche, abstrakte Dateizugriffsklasse zu schreiben (für SDL-RWOPS). Ich könnte dir wenn's dann klappt ansagen, was für Funktionen genau diese DLL benötigt. (Datei angeben, etc., Speicher freigeben)

Problem für die Verzögerung ist der Ansatz von gwGroups, aus denen man auch direkt laden soll.