DGL
https://delphigl.com/forum/

Spezifikation für VBO Blenderexporter
https://delphigl.com/forum/viewtopic.php?f=21&t=5629
Seite 1 von 1

Autor:  oc2k1 [ Di Jun 20, 2006 14:42 ]
Betreff des Beitrags:  Spezifikation für VBO Blenderexporter

Erst einmal der aktuelle Stand:

Die Daten sind als Vertexbufferobjekt kompatible Daten aufbereitet. Es sind nur Triangles erlaubt (vieleicht sollten noch Lines und Points erlaubt werden) Die Optimierten versionen wie Fans und Stripes sind zu kompliziert im VBO zu handhaben und die zusätzlichen Funktionsaufrufe Bremsen stärker als die vermehrten Vertices.

Code:
  1.  
  2. <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
  3. <vbo>
  4. <name>Meshname</name>
  5. <triangles>Anzahl der Dreiecke als Int</triangles>
  6.  
  7. <vertices>
  8. 9 Floats pro Triangle in einer Reihe
  9. </vertices>
  10.  
  11. <texturecoords>
  12. 6 Floats pro Triangle in einer Reihe
  13. </texturecoords>
  14.  
  15. <normals>
  16. 9 Floats pro Triangle in einer Reihe
  17. </normals>
  18.  
  19. <verrtexgroups>
  20. <weight>
  21. 3 Vertices pro Triangle, 4 Gewichtungen pro Vertex als Floats in einer Reihe
  22. </weight>
  23. <index>
  24. 3 Vertices pro Triangle, 4 Indezies auf den Namen der Vertxgruppe  pro Vertex als Int in einer Reihe
  25. </index>
  26. </verrtexgroups>
  27.  
  28. </vbo>
  29.  


Diese Format ist schon recht gut zum speicher von Vertexdaten Boneanimierter Modelle zu verwenden. Es ist allerdings noch nicht universell genug um alle VBOs abzuspeichern.

Folgendes würde ich jetzt Vorschlagen:

Mehrere Objekte in einer Datei:

Code:
  1. <objekt>   </object>

welches ein vollständiges Modell kapselt

Verbesserung des VBO Tags:
Erlauben von Points Lines und Triangles: Stat anzahl der Triangles werden die anzahl der Vertices übergeben: Es fürfen bleibieg viele ein einer Zeile aufgelistet werden nur die Anzahl muss stimmen
vertices: 2,3 oder 4 Komponenten erlaube.
Code:
  1. <vertices comp=3></vertices>

texturecoords: 2,3 oder 4 Komponenten erlaube.
Code:
  1. <texturecoords comp=2>  </texturecoords>

normal: kann durch eine TBN matrix ersetz werden (muss dann nicht im shader wieder zusammen gesetzt werden)
zusätzliches custom tag um nicht direkt spezifizierte zusätzlich VBO Daten zu speichern:
Code:
  1. <data name=datenname comp=1...16  type=GLType>  </data>


Erlauben von Level of Detail:
Code:
  1. <vbo name=name lod=lod> </lod>

Dort mach dann auch ein Antipopvektor sinn:
Code:
  1. <antipop comp=3></antipop>

Dieser Vektor wird einfach abhängig vom Abstand zum Vertex dazugerechnet damit das aufpoppen vermieden wird


Nun Sind die VBOs eigendlich vollständig erfasst. Es bleiben jedoch noch zusätzliche Daten:

Bonedaten: Die namen der Vertexgruppen und die Gelenkpositionen müssen gespeichert werden.

Annimationsdaten: Wenn vorhanden sollten sie mitgespeichert werden:

Shadertag: Könnten sinvoll sein, jedoch fällt mir jetzt nicht ein, wie man den Shadercode sinvoll in Blender eingeben könnte. Macht nur sinn bei einem eigenm Modeler

Verwaltungsdaten für einen Octree:

Code:
  1.  
  2. <octree>
  3. <0 start=0 len=1111>   </0>
  4. <1 start=1112 len=547>   </1>
  5. <2 start=1659 len=234>   </2>
  6. <octree>
  7.  


Es sind die Tags von 0 - 7 erlaubt und enthalten eine Start nummer und die Anzahl der Vertices die gerendert werden müssen. Diese Tag können rekrusiv in einander geschachtelt werden (es solltenmaximal 10 Ebenen sein, dann sind aber fast eine Milliarde Tags ineinandergeschachtel)
In verbindung Mit LOD sollten resampelte Daten verwendet werden, die keine Köcherigen übergänge besitzen. Die Implementation dafür kann aber ziehmlich aufwendig sein...


Die Frage ist jetzt was verbessert werden könnte oder was noch fehlt

Autor:  LarsMiddendorf [ Di Jun 20, 2006 17:56 ]
Betreff des Beitrags: 

Am einfachsten wäre es ja wenn es so weit wie möglichlich renderfertig speichert.
Also einen großen Vertex und Indexbuffer als Byte Array der direkt jeweils in ein Buffer Objekt kopiert wird. Dann eine Liste von Parametern für glVertexAttribPointer und glDrawElements.

VertexAttrib = record
Index,Size,Type,Stride,Offset :Integer
Normalized:Boolean;
end;

DrawElements = record
MaterialId:Integer;
Mode, Count, Type, Offset:Integer;
end;

Dann kann man einfach die entsprechenden Aufrufe durchführen ohne sich um das tatsächlichen Daten mit 2 oder 3 Elementen usw.. kümmern zu müssen. Bei den Materialien speichert man dann in einer weiteren Liste die Texturen, Shader oder ähnliches.

Autor:  oc2k1 [ Di Jun 20, 2006 23:45 ]
Betreff des Beitrags: 

Die Interleaved Arrays sind nicht schneller, haben allerdings den Nachteil, das nicht benötigte Daten kaum daraus entfenbar sind (zusätzliche Daten sind als atribute variablen im Vertexshader aufgelistet) und die Listen absolut unübersichtlich werden. So ist es viel einfacher für den Fall, das die Triangles noch mal zusätzlich für eine Pysikengine in den Arbeitsspeicher geladen werden müssen.

Autor:  oc2k1 [ Mi Jun 21, 2006 22:14 ]
Betreff des Beitrags: 

gedankliches Update:

Es wird ein optinales Modeltag eingeführt welche komplette modelle kapseln kann

Die Tags für lod anzahl der Triangles/Vertitices und name entfallen und werden direkt im VBO Tag untergebracht.

LOD: VBOs mit dem gleichem Namen werden gleich behandelt und nur anhand des LOD wertes unterschieden

Die Verwaltungsdaten für einen Octree werden innerhalb des VBO Tags untergebracht



Um das ganze Flexibler zumachen sollte der Loader zwei Files auf einmal parsen können, von de meines ein Binäres sein kann. Dabei können die automatisch exportierten Daten durch die per Hand geschrieben Daten aus dem zweitem File ergänst werden. So kann festgelegt werden welche Shader und Texturen verwendet werden, wenn im Modeler diese Informationen nicht gesetzt werden können

Autor:  LarsMiddendorf [ Mi Jun 21, 2006 22:43 ]
Betreff des Beitrags: 

Zitat:
Die Interleaved Arrays sind nicht schneller, haben allerdings den Nachteil, das nicht benötigte Daten kaum daraus entfenbar sind (zusätzliche Daten sind als atribute variablen im Vertexshader aufgelistet) und die Listen absolut unübersichtlich werden. So ist es viel einfacher für den Fall, das die Triangles noch mal zusätzlich für eine Pysikengine in den Arbeitsspeicher geladen werden müssen.

Welche Komponenten vom Array zusammen und welche als einzelnes Array gespeichert werden, ist dadurch doch gar nicht festgelegt. Die Vertex Attributekönnen auch als einzelne Arrays hintereinander liegen oder Kombinationen davon.
Abgesehen davon wird für die Physik nicht immer auch das Modell genommen das zum Rendern benutzt wird und manchmal ist es tatsächlich übersichtlicher die Attribute nicht als getrennte Arrays sondern als Array von record zu speichern. Das alles interessiert hierbei aber nicht, hauptsache die Parameter für die glVertexAttribPointer Aufrufe sind korrekt.

Seite 1 von 1 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/