Hi,

Ich hätte da mal folgende grundlegende Frage, und zwar habe ich nen Loader für Restless geschrieben, jetzt hab ich das folgendermaßen gemacht:

1. Vertices gelesen
2. UV Koordinaten gelesen
3. Faces zusammengebaut, wobei ein Face aus 3 * (Vertex+UV) besteht

Jetzt bin ich über die Faces iteriert und habe die Daten in ein VBO gepackt, also die 3 Vertices + die UV Koordinaten.

Ich find das allerdings irgendwie suboptimal, besser wäre doch wenn ich die Vertices direkt beim einlesen in ein VBO schreiben könnte, und die Faces nurnoch als Indizes in ein IBO ablegen müsste. Allerdings frag ich mich dann wie ich das mit den UV Koordinaten regeln soll? UV Koordinaten und Vertices sind beim Restless Format ja voneinander getrennt, somit könnte ein Vertex auch unterschiedliche UV Koordinaten bekommen, d.h. ich bräuchte noch einen Index Buffer für die UV Koordinaten, den gibts aber AFAIK nicht.

Was kann ich da machen? Eignet sich das Format einfach nicht für die Ablage mit Inidizes? Oder soll ich gar erst auf CPU Seite sortieren und Indizieren?

Soweit ich weiss, betrifft der Index immer einen kompletten Datensatz für einen Vertex, d.h. Koordinaten und alle Attribute, die über die gl*Pointer-Befehle bzw glInterleavedArrays angegeben wurden.

greetings

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Mein Loader funktioniert so, dass die UVKoordinaten beim Laden wieder den Vektoren zuordne und dann für die genauso das IBO in Form der Faces nutze. Andernfalls müsstest du dir halt für das UVCoordinatenVBO irgendwie ein eigenes IBO basteln. Ich fand das zu umständlich, deswegen lass ich das manuell zuordnen.

Dann hast du aber einige Arbeit auf der CPU zu bewältigen oder? Also Vektoren Lesen, UV Lesen, mithilfe der Faces Vektoren und UV zusammenlegen und dabei dubletten verhindern (sonst würde Indizes ja wenig Sinn machen) und dann erst in VBO und IBO laden, klingt mir etwas Aufwändig, wäre es nicht Sinnvoller die Daten direkt schon "Indiziert" abzuspeichern bzw. zu exportieren?

Wo steckt denn dann der Sinn an der Trennung von Vektoren und UV Koordinaten? Wieso macht man das?

@Lord Horazont:
Richtig, so hatte ich das auch in Erinnerung , und eben weil das so ist, will ich wissen wie ich die Daten vernünftig auslesen/verarbeiten kann, oder ob sich das bei dem Format nicht lohnt, weil es nicht dafür geschaffen ist .

Grüße & Danke euch!

Also:
Sinn liegt darin, dass die UVKoordinaten ja meistens nur zwischen 0 und 1 liegen. Und es kann durchaus sein, dass unterschiedliche Vektoren gleiche UVKoordinaten nutzen. Das ist, soweit ich weiß, der Grund.

Deinen Einwand wegen CPU Last verstehe ich nicht ganz. Es ist definitiv etwas arbeit am Anfang das ganze durchzuschauen. Aber zuerst werden alle Vektoren in ein Array gepackt. Dann werden die UVKoordinaten ausgelesen und statt in ein eigenes Array gespeichert zu werden, direkt den korrekten Vektoren zugewiesen. Bis auf den Verlust des womöglich existierenden Speichervorteils durch doppelte UVKoordinaten (siehe meine Vermutung, warum die getrennt liegen), ist das ganze genau eine Zuweisung mehr pro Vektor und das ganze auch nur am Anfang beim Laden.

Ich finde das Handhaben der UVKoordinaten als Bestandteil der Vektoren erheblich einfacher und im Programm logischer als die Trennung. Letztlich müsste man auch, wenn man die beiden voneinander trennt, bei jedem Vektor mindestens einen Index mit einbauen (der dann eben das separate Texuren IBO darstellen würde) mitspeichern, um für jeden Vektor eindeutig die UVCoordinate zu identifizieren. Man kann sich also potentiell einige Floatwerte im UVArray sparen, aber speichert dafür für alle x-Tausend Vektoren einen zusätzlichen Integerwert. Ich stelle mal diese potentielle Speichersparung in Frage.

Klingt logisch und würde Speicher im Model File auf der Platte sparen, stimmt.




Okay, vielleicht drück ich mich zu unklar aus, ich finds ehrlichgesagt auch ein bisschen schwer darzustellen, was ich überhaupt möchte .

Also die Daten liegen im Model File ja so ab, als gäbe es einen Index Buffer für die Vektoren und einen für die Texture Koordinaten, denn die Faces nutzen ja nurnoch Indizes. Dies gibt es in OpenGL aber nicht, denn ein "Vertex" besteht aus Vektor, Textur Koordinaten, ... Also kann ich mir die Vertices die ich in den Vertex Buffer lade ja erst dannzusammensetzen, wenn ich bei den Faces bin, denn erst da werden Vektoren und UV Koordinaten zusammengebracht.

Genau bei diesem Schritt muss man dann ja zwei Dinge beachten:
1. Doppelte Vertizes vermeiden, also muss ich den aktuell zusammengesetzen Vertex immer mit den bereits vorhanden vergleichen, sonst habe ich womöglich zwei gleiche Vertizes im VertexBuffer liegen, es kann (und wird) ja durchaus häufig der Fall sein, dass ein Vektor mit ein und der selben Texturkoordinate mehrfach genutzt wird - Kostet vermutlich recht viel Rechenzeit.
2. "Vektoren" verfielfältigen, falls an einem Vektor unterschiedliche Textur Koordinaten hängen (Beispiel: Würfel) muss ich den Vektor ja mit immer anderen Textur Koordinaten hochladen - kostet ein bisschen Rechenzeit.
3. Ich kann das VBO erst dann erstellen wenn die oberen beiden Schritte abgeschlossen hab, da ich vorher nicht weis, wieviele Vertizes ich am Ende haben werde, d.h. ich kann das VBO nicht "On-The-Fly" beschreiben - Außer ich verzichte auf die Indizierung und damit auf das entfernen von Doppelten Vertizes.

Das heißt doch, es wäre vermutlich Sinnvoller wenn die Daten nicht so im Model File liegen:

v 0 1 0
uv 0 1
...
f 1/0 0/1 2/1
...

Sondern direkt so:

vx 0 1 0 0 1
....
f 1 0 2

Wobei "vx" für "Vertex" steht, und nicht nur den Vektor sondern direkt auch die UV Koords beinhaltet, dadurch habe ich zwar evtl. etwas mehr speicher bedarf auf der Platte, krieg das Model aber deutlich schneller ins VBO, da ich direkt einlesen/reinschreiben kann, ohne vorher dubletten rauszufischen und die richtigen Indizes auchschon bei den Faces stehen hab.

Oder seh ich das falsch? Wäre der Speicherbedarf soviel größer? Ich meine man könnte die Model mit sicherheit deutlich schneller laden.



Genau das will ich ja auch garnicht, aber rein logisch betrachtet liegt es so im Model File OpenGL unterstützt das aber AFAIK nicht, ein IndexBuffer geht nur auf einen VertexBuffer, und darin muss nunmal der Vertex liegen, in welcher Form ist ja uninteressant, aber die UV Koords gehören fest dazu, und nicht in nen anderen Buffer (außer ich arbeite mit VertexPointern und VertexAttributen, aber auch dann zeigt der Index immer in beiden Buffern auf die selbe stelle, was nichts ändern würde).

Hoffe das war verständlicher .

Grüße!

Also warum ich auf doppelte Vertices prüfen muss, erschließt sich mir nicht. Wenn das exportierte Modell tatsächlich erlaubt, dass Vertices exportiert werden, die anderen vollkommen identisch sind, liegt der Fehler beim Exportert und nicht beim Importer. Ohne genau zu wissen, ob nun der Exporter sowas berücksichtigt (da müsste sich der Schreiber mal zu wort melden ^^), nehme ich an, dass er es tut Ich nehme also an, dass alle Vertices nur einmal vorkommen. Damit entfällt dieser Punkt.


Wenn du beim Exportieren "Minimize UV" ausstellst, werden die Koordinaten genau so exportiert, dass diese doppelten Vektoren erstellt werden. Ich exportiere nur so, weil fast jeder Vektor Teil mehrere UVKoordinaten ist.


In Anbetracht der Tatsache, dass Punkt 1 und 2 entfallen, wird das VBO erstellt, sobald alle Vektoren in einem Array vorliegen. Ob du das Array dann löschst oder nicht, ist deine Sache, ich lade zuerst alles, erstell es dann und behalte die Daten, die ich wirklich oft verwende, noch im Array vorliegen, und die, die ich selten oder gar nicht verändere, bleiben nur als VBO liegen. Auch hier sehe ich kein Problem


DIe UVKoordinaten gehören zwar in OGL fest zu den Vektoren, aber den Gedanken hinter der Trennung kann man ja schon nachvollziehen. Wie gesagt, es ginge rein theoretisch, die Vertices genau so, wie sie sind in ein VBO zu speichern, die Texturkoordinaten auch genau so in ein VBO zu packen und aus den Faces zwei IBOs einmal für die Vertices und einmal für die Texturkoordinaten zu machen. Dann nutzt du Vertexpointer und Texturpointer (aber soweit ich bisher gelesen habe, sollte man InterleavedArrays eh nicht verwenden) und sprichst die Buffer an. Ich mache es wie gesagt anders, ich weis die UVKoordinaten direkt den Vertices zu, das funkt auch gut. Ich glaube auch dass eine nachträgliche Änderung des Dateiformates ziemlich problematisch ist, für alle, die es schon verwenden.

Okay, einfaches Beispiel, nehmen wir mal das Beispiel Objekt "door.rlsobj":

f 40/0 24/1 25/2 f
f 40/0 25/2 26/3 f
f 40/0 26/3 27/4 f
f 40/0 27/5 28/6 f
f 40/0 28/6 29/7 f
f 40/0 29/7 30/8 f
f 40/0 30/8 31/9 f
f 40/0 31/9 24/1 f

Wir haben hier 8 Faces, diese setzen sich aus je 3 Vertizes zusammen, macht faktisch 24 Vertizes, wir haben aber augenscheinlich 8 mal das gleiche, ein typischer Fall für ein Index.

Es kann nun aber auch durchaus sein, dass irgendwo der Vertex "40/1" drankommt, gleicher Vektor andere Textur Koordinaten, also würde sich an dieser Stelle die Zahl meiner Vertizes im ggs. zu der Zahl der Vektoren um eins erhöhen, und genau deshalb kann ich doch erst rausfinden wieviele Vertizes mein Modell hat, wenn ich alle Faces abgearbeitet hab.



Wenn das so ist, habe ich zwar von Anfang an die richtige Anzahl an Vektoren, allerdings kann ich mich darauf ja nicht verlassen, wenn ich mich an die Specs halten will . Deshalb kommt mir das Restless Format wie ein nicht/nur mit Aufwand indizierbares Format vor. Wenn ich durch den Delphi Code von restless richtig durchsteige wird hier auch nur ein VBO und kein IBO erstellt, undzwar durch Iterieren über die Faces, also ist die größe des VBOs dort: Anzahl Faces * 3 Vertizes. Da liegt dann eben ne Menge doppelt drin, wie man an dem "door.rlsobj" Beispiel sieht.


Wenn ich es so mache wie von dir oben genannt, also ohne Minimize UV ist das Okay, dann dürfte bei den Faces zu jedem Vektor auch nur eine Textur Koordinate existieren, und wenn es mehrere gibt ist der Vektor eben dupliziert im File, dann ist das Indizieren wirklich simpel, aber wenn es minimiert ist, muss ich es erst auf CPU Seite wieder "normalisieren"/maximieren.

Grüße!

PS. Ich wollte mit dem Beitrag hier ja garnicht auf eine Änderung des restless Formats zielen, sondern eher in Erfahrung bringen warum die Daten so abgelegt werden, wenn man direkt Vertizes ablegt, also Vektoren mit UV Koords wäre es deutlich leichter zu handeln, es wäre höchstens das Model File etwas größer.