Blenderexporter - Versionsgeschichte

Openglerf: /* Daten für indizierte VBOs exportieren */

2012-03-18T13:21:37Z

‎Daten für indizierte VBOs exportieren

Openglerf: /* Optimierung der Daten */ Rechtschreibung :(

2012-03-18T13:20:43Z

‎Optimierung der Daten: Rechtschreibung :(

Openglerf: /* Exportieren der Daten */ Rechtschreibung :(

2012-03-18T13:14:40Z

‎Exportieren der Daten: Rechtschreibung :(

Änderungen zeigen

Openglerf: /* Vorbereiten der Daten */

2012-03-18T12:58:27Z

‎Vorbereiten der Daten

Openglerf: /* Aufbau eines Exporters */ Rechtschreibung :(

2012-03-18T12:56:43Z

‎Aufbau eines Exporters: Rechtschreibung :(

Openglerf: /* Vorwort */ Rechtschreibung :(

2012-03-18T12:54:58Z

‎Vorwort: Rechtschreibung :(

D.l.i.w: Verbesserte Grammatik

2012-02-09T08:27:07Z

Verbesserte Grammatik

Änderungen zeigen

Flash: /* Tangenvektor / TBN Matrix */

2009-03-22T11:01:03Z

‎Tangenvektor / TBN Matrix

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

2009-03-11T12:34:37Z

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

Änderungen zeigen

Flo: Offline in Bearbeitungs-Hinweis entfernt, da der Artikel seit langem nicht mehr bearbeitet wurde.

2009-03-11T12:33:29Z

Offline in Bearbeitungs-Hinweis entfernt, da der Artikel seit langem nicht mehr bearbeitet wurde.

@@ Zeile 409: / Zeile 409: @@
 ==Daten für indizierte VBOs exportieren==
-Lange Zeit hab ich dieses Thema umgangen, da der Export relativ komplex ist. Alle Daten aus Blender müssen komplett neu umgeordnet und neu indiziert werden, da Blender die Texturkoordinaten nicht per Vertex, sondern per Face abspeichert. Als Beispiel wird diesmal ein vereinfachter OBJ-Exporter dienen, der allerdings um Tangentvektoren ergänzt wird.
+Lange Zeit hab ich dieses Thema umgangen, da der Export relativ komplex ist. Alle Daten aus Blender müssen komplett neu umgeordnet und neu indiziert werden, da Blender die Texturkoordinaten nicht per Vertex, sondern per Face abspeichert. Als Beispiel wird diesmal ein vereinfachter OBJ-Exporter dienen, der allerdings um Tangentenvektoren ergänzt wird.
 <source lang="python">

@@ Zeile 338: / Zeile 338: @@
 ==Optimierung der Daten==
-Bisher haben wir uns hauptsachlich damit beschäftig, wie wir die Daten aus der Blenderstruktur auslesen und in VBO-kompatible Daten umformen. Wenn die Modelle größer werden oder komplette Level in Blender realisiert werden sollen macht es Sinn die Daten so umzusortieren, das Triangles mit ähnlichen Eigenschaften wie Ort oder Ausrichtung nah im Vertexbufferobjekt beieinander liegen.
+Bisher haben wir uns hauptsächlich damit beschäftig, wie wir die Daten aus der Blenderstruktur auslesen und in VBO-kompatible Daten umformen. Wenn die Modelle größer werden oder komplette Level in Blender realisiert werden sollen macht es Sinn die Daten so umzusortieren, das Triangles mit ähnlichen Eigenschaften wie Ort oder Ausrichtung nah im Vertexbufferobjekt beieinander liegen.
 ===Octree===
-Beim Octree werden nur die Teile gerender, bei denen voher bekannt ist, dass sie sichtbar sind, leider ist die Baumstruktur eines Octrees auf dem erstem Blick völlig inkompatibel zu dem linearen Verlauf des Vertexbuffersobjektes.
+Beim Octree werden nur die Teile gerendert, bei denen voher bekannt ist, dass sie sichtbar sind, leider ist die Baumstruktur eines Octrees auf dem erstem Blick völlig inkompatibel zu dem linearen Verlauf des Vertexbuffersobjektes.
-Um die Faces in den Octree einzusortieren, muss von jedem der Schwerpunkt berechnet werden. Die Position im Octree wird mit einer art Hashfunktion berechnet, die erst aus den X Y und Z Koordinaten Integerwerte von 0 bis 1023 bildet und deren Bits so zusammensortiert, dass ein einziger Wert von 0 bis 2^30-1 ensteht, nach dem die Faces sortiert werden:
+Um die Faces in den Octree einzusortieren, muss von jedem der Schwerpunkt berechnet werden. Die Position im Octree wird mit einer Art Hashfunktion berechnet, die erst aus den X Y und Z Koordinaten Integerwerte von 0 bis 1023 bildet und deren Bits so zusammensortiert, dass ein einziger Wert von 0 bis 2^30-1 entsteht, nach dem die Faces sortiert werden:
 <source lang="python">
@@ Zeile 392: / Zeile 392: @@
    return msh
 </source>
-Diese Funktion sollte direkt nach dem Umwandeln der Quads in Triangles aufgerufen werden, da die Reihenfolge der Triangles geändert wird.
+Diese Funktion sollte direkt nach dem Umwandeln der Quads in Triangles aufgerufen werden, da die Reihenfolge der Dreiecke geändert wird.
 Prinzipiell gibt es für jedes würfelförmige Volumen nur eine Start und Stopindexnummer die beim Rendern übergeben werden muss:
@@ Zeile 398: / Zeile 398: @@
 glDrawArrays( GL_TRIANGLES, start, stop - start);
 </source>
-Grundsätzlich sollte beachtet werden, dass es bei der Verwendung von VBOs möglichst viele Triangles auf einmal gerendert werden sollen.  Wo die Untergrenze pro volumen liegt, lässt sich schwer sagen, es ist aber sinnvoll, diese jenseits der 1000-10000 anzusetzten.
+Grundsätzlich sollte beachtet werden, dass es bei der Verwendung von VBOs möglichst viele Triangles auf einmal gerendert werden sollten. Wo die Untergrenze pro Volumen liegt, lässt sich schwer sagen, es ist aber sinnvoll, diese jenseits der 1000-10000 anzusetzten.
 ===Vorsortierung nach Vertexgruppen/Bones===

@@ Zeile 39: / Zeile 39: @@
 ==Vorbereiten der Daten==
-Da OpenGL nicht gut auf die gemischten Quads und Triangles klar kommt ist es sehr Sinnvoll sie gleich am Anfang vor dem Exportieren umzuwandeln:
+Da OpenGL nicht gut auf die gemischten Quads und Triangles klar kommt ist es sehr sinnvoll sie gleich am Anfang vor dem Exportieren umzuwandeln:
 <source lang="python">
 def quad2tri(msh):
@@ Zeile 77: / Zeile 77: @@
 </source>
-Das Prinzip ist relativ leicht zu verstehen. "flist" ist eine Liste in der die neuen Dreiecke zwischengespeichert werden. Dreiecke werden einfach kopiert. Bei Quads wird die kürzere Diagonale zum Teilen gesucht und aus den Daten des Quads zwei neue Triangles erzeugt. Zum Schluss wird  noch die temporäre Liste im Mesh gespeichert und das ganze zurückgegeben.
+Das Prinzip ist relativ leicht zu verstehen. "flist" ist eine Liste in der die neuen Dreiecke zwischengespeichert werden. Dreiecke werden einfach kopiert. Bei Quads wird die kürzere Diagonale zum Teilen gesucht und aus den Daten des Quads zwei neue Triangles erzeugt. Zum Schluss wird noch die temporäre Liste im [[Mesh]] gespeichert und das ganze zurückgegeben.
 ==Exportieren der Daten==

@@ Zeile 9: / Zeile 9: @@
 ==Aufbau eines Exporters==
-Jeder Blenderexporter verfügt über einen Header, in dem Daten stehen, wie er in die Menüstruktur eingefügt wird. Anschließen folgt der Python code. Näheres dazu steht in den Wikibooks.
+Jeder Blenderexporter verfügt über einen Header, in dem Daten stehen, wie er in die Menüstruktur eingefügt wird. Anschließend folgt der Pythoncode. Näheres dazu steht in den Wikibooks.
 <source lang="python">
 #!BPY
@@ Zeile 34: / Zeile 34: @@
 code getestet
-Wichtig ist, das man bei Python die Einrückungen beachtet. Als erstes wird eine Funktion definiert, die vom Fileexportdialog aus aufgerufen wird. Dabei wird der Filename als Argument übergeben. Die folgenden Zeilen öffnen ein File zum schreiben und hohlen sich die [[Mesh]]daten des erstem selektiertem Objektes.
+Wichtig ist, das man bei Python die Einrückungen beachtet. Als erstes wird eine Funktion definiert, die vom Fileexportdialog aus aufgerufen wird. Dabei wird der Filename als Argument übergeben. Die folgenden Zeilen öffnen eine Datei zum schreiben und holen sich die [[Mesh]]daten des ersten selektierten Objektes.
 Starten tut das Script eigendlich erst in der letzten Zeile, die den Exportdialog aufruft.

@@ Zeile 1: / Zeile 1: @@
 ==Vorwort==
-Hier werde ich einige Codeschnipsel zeigen, mit denen man sich einen eigenen Blenderexporter bauen kann. Der Schwerpunkt liegt dabei darauf, die Daten so vorzubereiten, dass sie direkt als VertexBufferObjekt in die Grafikkarte hochgeladen werden können.
+Hier werde ich einige Codeschnipsel zeigen, mit denen man sich einen eigenen Blenderexporter bauen kann. Der Schwerpunkt liegt dabei darauf, die Daten so vorzubereiten, dass sie direkt als Vertexbufferobjekt in die Grafikkarte hochgeladen werden können.
-Dieses Tutorial, soll kein festes Format beschreiben. Es ist sowohl möglich die Daten sauber in XML zu kapseln, als auch ganz dirty mal eben ein includierbares C oder Pascalfile zu erzeugen. Der Compiler wird einen dafür aber mit erheblich längeren Compelierungszeiten bestrafen.
+Dieses Tutorial, soll kein festes Format beschreiben. Es ist sowohl möglich die Daten sauber in XML zu kapseln, als auch ganz dreckig mal eben ein includierbares C oder Pascalfile zu erzeugen. Der Compiler wird einen dafür aber mit erheblich längeren Zeiten fürs kompilieren bestrafen.
-Prinzipell bin ich der Meinung, das eine eigene Engine nicht zwangshaft mit einem Universalformat wie Collada verwendet werden muss. Auch beliebte Formate wie 3DS haben gewaltige Nachteile, da sie nicht alle Daten speichern können, die beim Arbeiten mit Shadern benötigt werden. 3DS ist eine gute Wahl, solang man nicht viel mehr als Vertices, Normals und UV Coordinaten benötigt. Sobald Bones Vertexgruppen, TBN Matrizen und möglicherweise weitere eigene Daten gespeichert werden müssen gibt es große Probleme.
+Prinzipiell bin ich der Meinung, das eine eigene Engine nicht Zwangshaft mit einem Universalformat wie Collada verwendet werden muss. Auch beliebte Formate wie 3DS haben gewaltige Nachteile, da sie nicht alle Daten speichern können, die beim Arbeiten mit Shadern benötigt werden. 3DS ist eine gute Wahl, solang man nicht viel mehr als Vertices, Normals und UV Koordinaten benötigt. Sobald Bones Vertexgruppen, TBN Matrizen und möglicherweise weitere eigene Daten gespeichert werden müssen gibt es große Probleme.
 ==Aufbau eines Exporters==

@@ Zeile 289: / Zeile 289: @@
    out.write('</tbn>\n')
 </source>
-Warnung: Die Vektoren scheinen alle Senkrecht zu einander zu stehen, jedoch ist noch nicht überprüft ob die Matrizen wirklich brauchbar sind. Es wäre durchaus möglich, dass noch komponenten verdreht oder gespiegelt sind.
+{{Warnung| Die Vektoren scheinen alle Senkrecht zu einander zu stehen, jedoch ist noch nicht überprüft ob die Matrizen wirklich brauchbar sind. Es wäre durchaus möglich, dass noch komponenten verdreht oder gespiegelt sind.}}
 Aufgrund des Mangels an Atributevariablen, ist es nicht sehr Sinvoll die volle TBN Matrix zu übergeben. Sinvoller ist es nur den Tangendvektor (Bitangent kann durch ein Kreutzprodukt neu berechnet werden) oder den Tangentvektor zumammen mit dem Bitangentvektor als Atribute zu übergeben.

← Nächstältere Version		Version vom 11. März 2009, 12:33 Uhr
Zeile 1:		Zeile 1:
−	~~{{Offline}}~~
−
	==Vorwort==		==Vorwort==