Modelformat - Versionsgeschichte

DGLBot: Der Ausdruck ''(.*?)'' wurde ersetzt mit ''$1''.

2009-03-10T18:44:32Z

Der Ausdruck ''<cpp>(.*?)</cpp>'' wurde ersetzt mit ''<source lang="cpp">$1</source>''.

Sascha Willems: Bruteforce durch Immediate (korrektere Bezeichnung ersetzt), Statement zu Displaliste vs. VBO angepasst, siehe u.a. Dokumente von NVidia und ATI

2008-05-15T13:56:14Z

Bruteforce durch Immediate (korrektere Bezeichnung ersetzt), Statement zu Displaliste vs. VBO angepasst, siehe u.a. Dokumente von NVidia und ATI

Flash am 14. Mai 2008 um 08:52 Uhr

2008-05-14T08:52:06Z

Flash: Etwas umformatiert

2008-05-14T08:51:49Z

Etwas umformatiert

Traude: Korrekturgelesen, kleine Grammatikfehler korrigiert

2008-05-14T08:37:40Z

Korrekturgelesen, kleine Grammatikfehler korrigiert

I0n0s am 13. Mai 2008 um 22:30 Uhr

2008-05-13T22:30:43Z

Änderungen zeigen

TAK2004 am 13. Mai 2008 um 18:56 Uhr

2008-05-13T18:56:11Z

TAK2004 am 13. Mai 2008 um 18:54 Uhr

2008-05-13T18:54:33Z

Änderungen zeigen

TAK2004 am 13. Mai 2008 um 18:26 Uhr

2008-05-13T18:26:35Z

TAK2004: Die Seite wurde neu angelegt: Es gibt einige Arten von Modelformaten, Textbasierte, Binäre sogar grafische(siehe parametrisierte Models). Die Formate sind auf bestimmte Ziele ausgerichtet und demen...

2008-05-13T14:40:11Z

Die Seite wurde neu angelegt: Es gibt einige Arten von Modelformaten, Textbasierte, Binäre sogar grafische(siehe parametrisierte Models). Die Formate sind auf bestimmte Ziele ausgerichtet und demen...

Neue Seite

Es gibt einige Arten von Modelformaten, Textbasierte, Binäre sogar grafische(siehe parametrisierte Models).
Die Formate sind auf bestimmte Ziele ausgerichtet und dementsprechend auch im Aufbau unterschiedlich.

In diesem Artikel möchte ich ein für OpenGL optimiertes Format vorstellen, welches als weiteres Kriterium eine sehr geringe CPU und Ladezeit in anspruch nimmt.
Also sollten wir uns erstmal die für OpenGL benötigten Daten angucken.
Vertex=float x,float y,float z
Color=Vertice
Normal=Vertice
Texcoord=float u,float v
Index=int i

OpenGL bietet mehere möglichkeiten diese Daten darzustellen.
-VBO(virtual buffer object)
-Bruteforce(glBegin/glEnd)
-vertexarray
-displaylist(vertexarray oder bruteforce)
Die performantesten Varianten sind Displaylist mit vertexarray und VBO.
Displaylisten haben aber den nachteil, dass sie gering langsamer sind und nicht so flexibel wie VBO sind.
VBO bietet uns 2 möglichkeiten, die Daten in den VRam zu speichern, als einzelne Streams und als ein einziger Stream.
Hier sollte man alle Daten als einzelne Streams behandeln, also Verticelist,Normallist,Colorlist,... .
So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.

Wozu das Index ? Der Index zeigt auf ein Wert in der Vertex-, Color-, Normal-,... strean.
Man kann also bei großen Models viel Platz sparen, wenn man Indices verwendet, da man jedes Datenelement nur einmal ablegt und durch den Index diesen mehrfach verwenden kann.

Model
-Verticelist
-Normallist
-Colorlist
-Texcoordlist
-Indices

Nun brauchen wir auch Texturen und Shader für unsere Models.
Um diese zu verwenden brauchen wir Faces, also müssen Flächen bilden.
Jede Fläche bekommt den Startindex, die Vertexcount und nun noch das Material.
Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
Material
-Start
-Count
-Name

Man könnte z.B. ein Script oder XML Datei erstellen, die alle benötigten Texturen,Flags und Shader enthält. Diese wären dann unsere Materialfiles und werden durch das Model geladen.

Model
-Verticelist
-Normallist
-Colorlist
-Texcoordlist
-Indices
-Faces

Wenn man Shader verwendet, dann könnte man die tangenten mit reinpacken.

Okey Nun müssen wird die Daten auch noch speichern und das möglichst schnell Ladbar.
Hier kann man Serializing aufgreifen und die Daten und den Loader entsprechend anpassen.
Bei diesem Ansatz wird

@@ Zeile 5: / Zeile 5: @@
 In diesem Artikel möchte ich ein für OpenGL optimiertes Format vorstellen, welches als weiteres Kriterium eine sehr geringe CPU und Ladezeit in Anspruch nimmt. Also sollten wir uns erstmal die für OpenGL benötigten Daten angucken.
-<cpp>typedef Vertex   float        x,y,z;
+<source lang="cpp">typedef Vertex   float        x,y,z;
 typedef Color    float        r,g,b;
 typedef Normal   float        x,y,z;
 typedef Texcoord float        u,v;
-typedef Index    unsigned int i;</cpp>
+typedef Index    unsigned int i;</source>
@@ Zeile 21: / Zeile 21: @@
 Wozu der Index? Der Index zeigt auf einen Wert in der Vertex-, Color-, Normal-, ...-Stream. Man kann also bei großen Models viel Platz sparen, wenn man Indices verwendet, da man jedes Datenelement nur einmal ablegt und durch den Index mehrfach verwenden kann.
-<cpp>struct Model
+<source lang="cpp">struct Model
+{
   Vertex   *Verticelist;
@@ Zeile 28: / Zeile 28: @@
   Texcoord *Texcoordlist;
   Index    *Indices;
-};</cpp>
+};</source>
 Nun brauchen wir auch Texturen und Shader für unsere Models. Um diese zu verwenden brauchen wir Faces, also müssen wir Flächen bilden. Jede Fläche bekommt den Startindex, die Vertexanzahl und ein Material zugewiesen. Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
-<cpp>struct Face
+<source lang="cpp">struct Face
+{
    unsigned int Start;
    unsigned int Count;
    string       MaterialName;
-};</cpp>
+};</source>
 <br>
 Der Name ist allerdings ziemlich groß und würde in jeden Face wieder auftreten. Also speichern wir im Format eine Liste von Materialnamen und speichern im Face den Index in der Liste.
-<cpp>struct Face
+<source lang="cpp">struct Face
+{
    unsigned int Start;
@@ Zeile 55: / Zeile 55: @@
   string   *MaterialList[32]; //feste Strings sind besser zu laden
   Face     *Facelist;
-};</cpp>
+};</source>
 <br>
 Für das Material File könnte z.B. ein Script oder eine XML Datei erstellt werden, die alle benötigten Texturen, Flags und Shader enthält. Wenn man Shader verwendet, dann könnte man die Tangenten mit dazu packen.
@@ Zeile 62: / Zeile 62: @@
 Ein Beispiel kann das wohl besser beschreiben:
-<cpp>//eigentliche Struktur
+<source lang="cpp">//eigentliche Struktur
 struct Data
+{
@@ Zeile 88: / Zeile 88: @@
+{
    Data->Vertice=(Vertex*)((char*)Data+(unsigned int)Data->Vertice);
-}</cpp>
+}</source>
 Aktuell hat keine Console oder PC eine größere Speicheradressierung als 64Bit.
 Also werden die dynamischen Elemente mit offsets von 4byte und 4byte ungenutzt besetzt. Wir könnten die Daten nun mit einem read Aufruf laden und das relocate korrigiert den offset zu einem Pointer.

@@ Zeile 14: / Zeile 14: @@
 OpenGL bietet mehrere Möglichkeiten diese Daten darzustellen.
 *[[VBO]] (vertex buffer object)
-*Bruteforce([[glBegin]]/glEnd)
+*Immediate (direkter Modus)([[glBegin]]/glEnd)
 *[[Vertexarray]]
 *[[Displayliste]]
-Die effektivsten Varianten sind Displaylisten mit Vertexarray und VBO. Displaylisten haben aber den Nachteil, dass sie geringfügig langsamer und nicht so flexibel wie VBO sind. VBO bietet uns zwei Möglichkeiten, die Daten in den VRam zu speichern. Entweder in Form mehrer Streams oder als ein einziger Stream. Hier sollte man alle Daten als einzelne Streams behandeln, also Vertexliste, Normalliste, Colorliste,... . So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.
+Die effektivsten Varianten sind Displaylisten mit Vertexarray und VBO. In Sachen Geschwindigkeit sind Displaylisten immer noch die beste Möglichkeit (siehe z.B. [http://ati.amd.com/developer/gdc/2006/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf folgendes Dokument] von ATI für die GDC2006, Seite 14), haben aber in Sachen Flexibilität Nachteile (entweder müssen sie neu erstellt werden, oder im Shader angepasst werden). VBO bietet uns zwei Möglichkeiten, die Daten in den VRam zu speichern. Entweder in Form mehrer Streams oder als ein einziger Stream. Hier sollte man alle Daten als einzelne Streams behandeln, also Vertexliste, Normalliste, Colorliste,... . So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.

← Nächstältere Version		Version vom 14. Mai 2008, 08:52 Uhr
Zeile 109:		Zeile 109:


−	Bei Fragen, Verbesserungsvorschlägen oder ähnlichem, mich([[Benutzer:TAK2004\|TAK2004]) einfach per PM im Forum ansprechen.	+	Bei Fragen, Verbesserungsvorschlägen oder ähnlichem, mich([[Benutzer:TAK2004\|TAK2004]]) einfach per PM im Forum ansprechen.

@@ Zeile 17: / Zeile 17: @@
 *[[Vertexarray]]
 *[[Displayliste]]
-Die effektivsten Varianten sind Displaylisten mit Vertexarray und VBO. Displaylisten haben aber den Nachteil, dass sie geringfügig langsamer und nicht so flexibel wie VBO sind. VBO bietet uns zwei Möglichkeiten, die Daten in den VRam zu speichern: als einzelne Streams oder als ein einziger Stream. Hier sollte man alle Daten als einzelne Streams behandeln, also Vertexliste, Normalliste, Colorliste,... . So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.
+Die effektivsten Varianten sind Displaylisten mit Vertexarray und VBO. Displaylisten haben aber den Nachteil, dass sie geringfügig langsamer und nicht so flexibel wie VBO sind. VBO bietet uns zwei Möglichkeiten, die Daten in den VRam zu speichern. Entweder in Form mehrer Streams oder als ein einziger Stream. Hier sollte man alle Daten als einzelne Streams behandeln, also Vertexliste, Normalliste, Colorliste,... . So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.
@@ Zeile 30: / Zeile 30: @@
 };</cpp>
-Nun brauchen wir auch Texturen und Shader für unsere Models. Um diese zu verwenden brauchen wir Faces, also müssen wir Flächen bilden. Jede Fläche bekommt den Startindex, die Vertexcount und nun noch das Material. Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
+Nun brauchen wir auch Texturen und Shader für unsere Models. Um diese zu verwenden brauchen wir Faces, also müssen wir Flächen bilden. Jede Fläche bekommt den Startindex, die Vertexanzahl und ein Material zugewiesen. Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
 <cpp>struct Face
+{
@@ Zeile 59: / Zeile 59: @@
 Für das Material File könnte z.B. ein Script oder eine XML Datei erstellt werden, die alle benötigten Texturen, Flags und Shader enthält. Wenn man Shader verwendet, dann könnte man die Tangenten mit dazu packen.
-Okay, nun müssen wir die Daten auch noch speichern und das möglichst in einer schnell ladbaren Form. Hier kann man Serializing aufgreifen und die Daten und den Lader entsprechend anpassen. Bei diesem Ansatz wird jede dynamische Variable (arrays/pointer) überarbeitet. Alle Daten, die gleich bleiben, werden 1 zu 1 geschrieben, für die dynamischen Daten wird ein Bereich am Ende des Formates zur Verfügung gestellt und dorthin verschoben. Die Differenz zwischen Position des Pointers/Array und der Stelle der abgelegten Daten ist der Offset und wird an der Stelle der Liste geschrieben.
+Okay, nun müssen wird die Daten auch noch speichern und das so, dass wir sie möglichst schnell wieder laden können. Hier kann man Serialisierung aufgreifen und die Daten und den Loader entsprechend anpassen. Bei diesem Ansatz wird jede dynamische Variable (arrays/pointer) überarbeitet. Alle Daten, die gleich bleiben, werden 1 zu 1 geschrieben, für die dynamischen Daten wird ein Bereich am Ende des Formates zur Verfügung gestellt und dorthin verschoben. Die Differenz zwischen Position des Pointers/Array und der Stelle der abgelegten Daten nennt man Offset. Dieser wird an der entsprechenden Stelle in die Liste geschrieben.
 Ein Beispiel kann das wohl besser beschreiben:

@@ Zeile 1: / Zeile 1: @@
-Es gibt einige Arten von Modelformate: Textbasierende, binäre, sogar grafische (siehe parametrisierte Geometry Maps).
+Es gibt einige Arten von Modelformaten: Textbasierende, binäre, sogar grafische (siehe parametrisierte Geometry Maps).
 Die Formate sind auf bestimmte Ziele ausgerichtet und dementsprechend auch im Aufbau unterschiedlich.
@@ Zeile 13: / Zeile 13: @@
 OpenGL bietet mehrere Möglichkeiten diese Daten darzustellen.
-*[[VBO]] (virtual buffer object)
+*[[VBO]] (vertex buffer object)
 *Bruteforce([[glBegin]]/glEnd)
 *[[Vertexarray]]
 *[[Displayliste]]
-Die performantesten Varianten sind Displaylisten mit Vertexarray und VBO. Displaylisten haben aber den Nachteil, dass sie geringfügig langsamer und nicht so flexibel wie VBO sind. VBO bietet uns 2 Möglichkeiten, die Daten in den VRam zu speichern, als einzelne Streams oder als ein einziger Stream. Hier sollte man alle Daten als einzelne Streams behandeln, also Verticeliste, Normalliste, Colorliste,... . So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.
+Die effektivsten Varianten sind Displaylisten mit Vertexarray und VBO. Displaylisten haben aber den Nachteil, dass sie geringfügig langsamer und nicht so flexibel wie VBO sind. VBO bietet uns zwei Möglichkeiten, die Daten in den VRam zu speichern: als einzelne Streams oder als ein einziger Stream. Hier sollte man alle Daten als einzelne Streams behandeln, also Vertexliste, Normalliste, Colorliste,... . So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.
-Wozu das Index? Der Index zeigt auf ein Wert in der Vertex-, Color-, Normal-, ...-Stream. Man kann also bei großen Models viel Platz sparen, wenn man Indices verwendet, da man jedes Datenelement nur einmal ablegt und durch den Index diesen mehrfach verwenden kann.
+Wozu der Index? Der Index zeigt auf einen Wert in der Vertex-, Color-, Normal-, ...-Stream. Man kann also bei großen Models viel Platz sparen, wenn man Indices verwendet, da man jedes Datenelement nur einmal ablegt und durch den Index mehrfach verwenden kann.
 <cpp>struct Model
+{
@@ Zeile 30: / Zeile 30: @@
 };</cpp>
-Nun brauchen wir auch Texturen und Shader für unsere Models. Um diese zu verwenden brauchen wir Faces, also müssen Flächen bilden. Jede Fläche bekommt den Startindex, die Vertexcount und nun noch das Material. Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
+Nun brauchen wir auch Texturen und Shader für unsere Models. Um diese zu verwenden brauchen wir Faces, also müssen wir Flächen bilden. Jede Fläche bekommt den Startindex, die Vertexcount und nun noch das Material. Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
 <cpp>struct Face
+{
@@ Zeile 57: / Zeile 57: @@
 };</cpp>
 <br>
-Für die Material File könnte z.B. ein Script oder XML Datei erstellt werden, die alle benötigten Texturen, Flags und Shader enthält. Wenn man Shader verwendet, dann könnte man die Tangenten mit reinpacken.
+Für das Material File könnte z.B. ein Script oder eine XML Datei erstellt werden, die alle benötigten Texturen, Flags und Shader enthält. Wenn man Shader verwendet, dann könnte man die Tangenten mit dazu packen.
-Okay, nun müssen wird die Daten auch noch speichern und das möglichst schnell ladbar. Hier kann man Serializing aufgreifen und die Daten und den Lader entsprechend anpassen. Bei diesem Ansatz wird jede dynamische Variable (arrays/pointer) überarbeitet. Alle Daten, die gleich bleiben, werden 1 zu 1 geschrieben, für die dynamischen Daten wird ein Bereich am Ende des Formates zur Verfügung gestellt und dorthin verschoben. Die Differenz zwischen Position des Pointers/Array und der Stelle der abgelegten Daten ist der Offset und wird an der Stelle der Liste geschrieben.
+Okay, nun müssen wir die Daten auch noch speichern und das möglichst in einer schnell ladbaren Form. Hier kann man Serializing aufgreifen und die Daten und den Lader entsprechend anpassen. Bei diesem Ansatz wird jede dynamische Variable (arrays/pointer) überarbeitet. Alle Daten, die gleich bleiben, werden 1 zu 1 geschrieben, für die dynamischen Daten wird ein Bereich am Ende des Formates zur Verfügung gestellt und dorthin verschoben. Die Differenz zwischen Position des Pointers/Array und der Stelle der abgelegten Daten ist der Offset und wird an der Stelle der Liste geschrieben.
-Ein Beispiel kann dies wohl besser beschreiben:
+Ein Beispiel kann das wohl besser beschreiben:
 <cpp>//eigentliche Struktur
@@ Zeile 89: / Zeile 89: @@
    Data->Vertice=(Vertex*)((char*)Data+(unsigned int)Data->Vertice);
 }</cpp>
-Aktuell hat keine Console oder PC ein größeren Speicheradressierung als 64Bit.
+Aktuell hat keine Console oder PC eine größere Speicheradressierung als 64Bit.
-Also werden die dynamischen Elemente mit offsets von 4byte und 4byte ungenutzt besetzt.Laden könnten wir die Daten nun mit einem read aufruf und das relocate korrigiert den offset zu einem Pointer.
+Also werden die dynamischen Elemente mit offsets von 4byte und 4byte ungenutzt besetzt. Wir könnten die Daten nun mit einem read Aufruf laden und das relocate korrigiert den offset zu einem Pointer.
-Die Probleme der meisten Formate liegen in dem Aufbau, welches oft noch geparsed und in mehreren Etappen geladen werden muss (braucht CPU Zeit und verschwendet Zeit beim Festplattenzugriff) und in den unpassenden Datenbeschaffenheit(eventuell konvertieren oder noch schlimmer, Speicherreservierung und konvertieren). Das oben beschriebene Speicher und Ladesystem braucht nur einen einzigen Read Aufruf und hat danach die Daten komplett im Speicher. Dann noch ein relocate und wir haben die fertigen Daten.
+Die Probleme der meisten Formate liegen im Aufbau, wenn oft noch geparsed und in mehreren Etappen geladen werden muss (braucht CPU Zeit und verschwendet Zeit beim Festplattenzugriff) und in der unpassenden Datenbeschaffenheit (eventuell konvertieren oder noch schlimmer, Speicherreservierung und konvertieren). Das oben beschriebene Speicher- und Ladesystem braucht nur einen einzigen Read Aufruf und hat danach die Daten komplett im Speicher. Dann noch ein relocate und wir haben die fertigen Daten.
-Der Vorteil des relocate ist, dass man lediglich für dynamische Elemente einmal eine Addition ausführt(10 Arrays = 10 Additionen).
+Der Vorteil des relocate ist, dass man lediglich für dynamische Elemente einmal eine Addition ausführt (10 Arrays = 10 Additionen).
-Durch die Anpassung, an das von OpenGL gewollten Datenformat, kann man ganz einfach die Daten in den VRam laden lassen (VBO Streams lassen grüssen) und leiten das Laden des Materials an die entsprechende Stelle weiter.
+Durch die Anpassung an das von OpenGL gewollte Datenformat kann man ganz einfach die Daten in den VRam laden lassen (VBO Streams lassen grüssen) und leitet das Laden des Materials an die entsprechende Stelle weiter.

@@ Zeile 113: / Zeile 113: @@
 *[https://svn.linuxprofessionals.org/filedetails.php?repname=karmarama&path=%2Ftrunk%2Finclude%2Fkar_model.hpp kar_model.hpp]
 *[https://svn.linuxprofessionals.org/filedetails.php?repname=karmarama&path=%2Ftrunk%2Fsrc%2Fkar_model.cpp kar_model.cpp]
 Ein weiterer Vorteil ist der Codeumfang, denn dieser ist in meiner Implementierung gerademal 205Zeilen lang.<br>
 Mein Testmodel hatte ~15k Vertice,Normals,Texcoords,~46k Indices,15k Faces,1Material und keine Properties.<br>
@@ Zeile 118: / Zeile 119: @@
 Das Laden des ganzen Models mit der einer Textur(512x512 dxt5) hat knapp 20ms gedauert.<br>
 [http://karmarama.developer-alliance.org/upload/model.PNG Ein nicht ganz aktuelles Screenshot.]
+<br>
 Bei Fragen, verbesserungsvorschlägen oder ähnlichem, mich(TAK2004) einfach per PM im Forum ansprechen.

@@ Zeile 1: / Zeile 1: @@
-Es gibt einige Arten von Modelformaten, Textbasierte, Binäre sogar grafische(siehe parametrisierte Models).
+Es gibt einige Arten von Modelformaten, Textbasierte, Binäre sogar grafische(siehe parametrisierte geometry Maps).
 Die Formate sind auf bestimmte Ziele ausgerichtet und dementsprechend auch im Aufbau unterschiedlich.
@@ Zeile 5: / Zeile 5: @@
 Also sollten wir uns erstmal die für OpenGL benötigten Daten angucken.
 Vertex=float x,float y,float z
-Color=Vertice
+Color=float r,float g,float b
-Normal=Vertice
+Normal=float x,float y,float z
 Texcoord=float u,float v
 Index=int i
@@ Zeile 21: / Zeile 21: @@
 So können wir später einzelne Streams abschalten und anschalten, wenn wir sie beim Zeichnen benötigen.
-Wozu das Index ? Der Index zeigt auf ein Wert in der Vertex-, Color-, Normal-,... strean.
+Wozu das Index ? Der Index zeigt auf ein Wert in der Vertex-, Color-, Normal-,... stream.
 Man kann also bei großen Models viel Platz sparen, wenn man Indices verwendet, da man jedes Datenelement nur einmal ablegt und durch den Index diesen mehrfach verwenden kann.
@@ Zeile 35: / Zeile 35: @@
 Jede Fläche bekommt den Startindex, die Vertexcount und nun noch das Material.
 Das Material ist ein Name, über den wir auf eine Ressource zugreifen können, die die Texturen und Shader verwalten.
-Material
+Face
 -Start
 -Count
--Name
+-MaterialName
-Man könnte z.B. ein Script oder XML Datei erstellen, die alle benötigten Texturen,Flags und Shader enthält. Diese wären dann unsere Materialfiles und werden durch das Model geladen.
+Der Name ist allerdings ziemlich groß und würde in jeden Face wieder auftreten.
 Model
@@ Zeile 48: / Zeile 54: @@
 -Texcoordlist
 -Indices
--Faces
+-Materiallist
 Wenn man Shader verwendet, dann könnte man die tangenten mit reinpacken.
 Okey Nun müssen wird die Daten auch noch speichern und das möglichst schnell Ladbar.
 Hier kann man Serializing aufgreifen und die Daten und den Loader entsprechend anpassen.
-Bei diesem Ansatz wird
+Bei diesem Ansatz wird jede dynamische variable(arrays/pointer) überarbeitet.