Hallo Leute!
Ich würde gerne wissen, wie man Primitive - oder genauer Vertices - am Besten nach Texturen sortiert.

Angenommen, man hat eine Reihe von Vertices, die später beim Rendern zu Dreiecken zusammengesetzt werden sollen. Dann würde ich ein zweidimensionales Array mit der Dimension 1 - Länge alle benutzten Texturen erstellen.
Alle Vertices, auf denen später Textur 0 abgebildet werden soll, packe ich in das Array der ersten Stelle. Alle Vertices, auf denen später Textur 1 abgebildet werden soll, packe ich in das Array der zweiten Stelle. Und so weiter. Die zweite Dimension hat dann als Länge jeweils die Anzahl der Vertices.
Also :
VertexArray[0] ist das Array aller Vertices, auf denen Textur 0 gebunden werden soll.

Doch irgendwie wird das richtig "doof": Wenn man noch verschiedene Detailsmaps hat, bzw. allgemein Multitexturing mit 2 Texturen ermöglicht, dann ist das Array schon dreidimensional, weil ja dann jedoch nach 2 Texturen sortiert werden muss.

Hat jemand ne Idee, wie man das sonst sortieren sollte?


(Ich hoffe, dass ich mich einigermaßen verständlich ausgedrückt hab ;) )

Hi,
ich würd alle vertices in ein einfaches Array speichern, und jedem Vertex eine TexturID spendieren. Also ein Record TVertex
erstellen:


Dann gehst du das Array so oft durch, wie du Texturen im Einsatz hast.
Bindest die entsprechende Textur, fragst ab, ob der Vertex die aktuelle TexturID hat, und renderst ihn.
Theoretisch könntest du auch ein "Set Of Integer" als "texid" einsetzen, dann kannst du mehrere Texturen einem Vertex zuordnen (für u.a. MultiTexturing).

Gruß,
MatReno

_________________
http://texelviews.delphigl.com

MatReno: Die Idee ist zwar durchaus nett aber Rüdiger hatte sich in einem anderen Thema sehr intensiv mit VBOs beschäftigt. Und damit würde das dann nicht gehen. Wobei es sicherlich auch etwas kompliziert werden dürfte wenn man für jede noch so kleine Textur einmal durch die kompletten Daten gehen müsste. Da es von 2 Faktoren (Vertices * Texturen) abhängt steigt der Aufwand mit zunehmender Größe expotential an.

Rüdiger: Ich würde nicht nur einzelne Vertices betrachten, denn bei Texturen ist die kleinst mögliche Einheit ein Primitiv. Typischerweise ein Drei- oder Viereck.

Ich weiß auch nicht ob ich damit auch nur Ansatzweise richtig liege. Aber ich versuche das mal an einem Beispiel. Nehmen wir mal ein klassisches Spiel. Dort existiert ein Level, verschiedene Objekte wie Gegenstände und Personen. Ich würde da nicht versuchen alle Objekte zu sortieren, weil man sich teilweise die Arbeit erleichtern kann. Bei Objekten wie Tischen/Personen etc. ist es normal so, dass es sich in irgendeiner Art um Modelle handelt. Und diese besitzen normal ja eine eigene Textur. Also die Textur der Person wird eher nicht in dem Level vorkommen. Von daher könnte man den Gegenstand/die Person schon komplett aus der Sortierung rauslassen. Diese würden nur irgendwann die Daten an OpenGL übergeben.

Sortiert werden müsste nur der Level. Und den würde ich dann tatsächlich so sortieren wie du das gesagt hast. Also erst einmal komplett im Speicher der Anwendung sortieren und die sortierten Speicherbereiche dann am Stück hochladen.

Wichtig dabei ist, dass du auch etwas auf deinen Code achtest. Denn wenn du alle Objekte auf einmal sortieren wollen würdest, dann hättest du unter Umständen sehr weit verschlungenen Code. Und das ist dann wiederum nicht so praktisch. Von daher würde ich auch lieber kleinere Redundanzen beim Rendern in kauf nehmen als seine Seele in der Anwendung verkaufen zu müssen. Also unnötige Texturenwechsel sollten natürlich vermieden werden aber wenn eine Textur 3-4 mal an unterschiedlichen Stellen benutzt wird dann ist das auch kaum Messbar. Da musst du für die Anwendungsfälle deiner Anwendung einen "goldenen Mittelweg" finden.

Stimmt, das mit den Primitiven wollte ich auch noch anmerken, hatte es aber vergessen.

Ok, mit VBO's würde die Sache dann net mehr so toll gehen.
Ich dachte nur es wäre ganz nützlich, hab den Bezug zum vorigen Thread nicht gesehen...

@Lossy: Wo ist denn die schöne grüne Maus hin? (avatar)

_________________
http://texelviews.delphigl.com

Danke schon mal für die Antworten!

Ich habe mir jetzt mal Gedanken über ein Konzept gemacht, was ich mit dem Produkt überhaupt machen möchte :) Die 3D-Engine soll Outdoor-Landschaften aus Dateien laden können. Dazu habe ich mir mit Hilfe eurer Kommentare gedacht, dass die Engine jetzt drei Typen von Objekten aus den Dateien laden soll.

Einmal die statische Landschaft aus der Heightmap und einfache Objekte (wie z.b. Vierecke), die aber schon als Vertices in der Datei gespeichert ist. Wenn ich die Daten auf diese Art und Weise lade, dann ist es nicht allzu kompliziert, die Vertices dann auch passend texturiert als Dreiecke in den Framebuffer zu bekommen. Dafür würde ich einfach die Vertices, die zu gleichtexturierten Objekten gehören, in einem Array vorliegen haben, welches ich schon sortiert aus der Datei bekomme.
Die Arrays würde ich dann entweder mit glDrawArrays() in eine Displayliste kompilieren, oder direkt in ein VBO im VRAM laden, und jedesmal beim Rendern glDrawArrays() für alle Arrays aufrufen. Letztere Methode finde ich allerdings noch ein wenig verwirrend.

Der zweite Objekttyp den ich für komplexe statische Objekte laden würde, läge nicht wie oben in Vertices vor, sondern nur mit Angaben, welches Objekt gezeichnet werden soll. Sowas wie "Kugel an Position X mit Eigenschaften..." oder "Model1 aus vorher geladener Modelliste an Position Y". Sonst würde die Dateigröße ja explodieren, wenn ich für solche Objekte (die sich ja wiederholen) immer wieder alle Vertices speichern würde. Diese Objekte würde ich am Anfang genau wie bei der statischen Landschaft laden, also entweder VBO im VRAM oder Displayliste. Hier wird die Arraysortierung nach Texturen schon schwieriger...

Der dritte Typ würde dann dynamische Objekte angeben. Ehrlich gesagt finde ich das sehr schwierig: Zwar würde ich diese Objekte aus den Dateien genauso laden wie den zweiten Objekttyp, allerdings wüsste ich nicht genau, wie ich das organisieren könnte. Folgendes hab ich mir überlegt und teilweise auch implementiert: Erstmal lade ich die Vertices für jedes Objekt in ein VBO im VRAM. Für jedes 3D-Objekt erstelle ich dann ein Objekt einer Delphi-Klasse. Diese Klasse deklariert ihre Eigenschaften, wie ihre Position, die Eigenrotation, ... die Liste lässt sich erweitern.
Das Rendern ist dann aber recht lahm. Dort manipuliere ich die Modelview-Matrix jedesmal so, dass das 3D-Objekt an der richtigen Stelle erscheint, richtig rotiert ist, etc. Dann zeichne ich die Arrays des Objekts. Die Arrays müssen dabei wieder so sortiert sein, dass die Texturen möglichst selten gewechselt werden.

Lossy, du hast ja geschrieben:

Wäre die Betrachtung von Vertices beim ersten Objekttyp denn in Ordnung? Beim zweiten Objekttyp würde ich ja immer das Primitiv betrachten.



Was haltet ihr von diesem Ansatz? Ist das viel zu lahm, unflexibel oder sonst irgendwie nicht passend?

Vielen Dank für die Aufmerksamkeit :)

MatReno: Die Ratte liegt noch auf meinem Server rum. Wurde mal Zeit für was neues. Ich persönlich finde Fallout 1-2 so was von geil und der dritte Teil davon ist gerade sehr in greifbare Nähe gerückt.

Rüdiger: Mit richtigen Engines kenne ich mich nicht aus von daher kann ich dir nicht sagen ob der Ansatz ausreicht oder nicht. Aber hier ein paar Anregungen zu dem von dir erwähnten.

1. Von DisplayListen würde ich in deinem Falle sogar etwas Abstand nehmen. Denn an anderer Stelle benutzt du bereits VBOs (oder musst es später tun) und dann kannst du VBOs auch dort benutzen. Da du die Displayliste ja wahrscheinlich auch schon mit einem VBO befüllst macht das eigentlich kaum noch Sinn weiter auf eine Displayliste zu setzen.

2. Das ist eher eine Beschreibung wie der Level auszusehen hat. Also welches Model sich wo befinden. Das musst du sogar so trennen. Sonst könntest du das ja bereits alles schon so fix in die Landschaft mit einbauen und das würde keinen Sinn machen. Aber um die Festplatte würde ich mir keine Gedanken machen, da das Problem eher die Grafikkarte sein dürfte. Denn die hat nur 128/256 MB Speicher. Abzüglich dessen was die Framebuffer und Windows bereits beschlagen.

Allerdings denke ich, dass du so etwas wie eine Kugel in der Definition eher nicht gebrauchen wirst. Denn dann müsstest du auch Texturierungsinfos mit ablegen und dann lohnt es sich schon eher ein Kugelmodel zu machen und nur auf Modelle zu verweisen.

3. Ja so etwas mit den Objekten ist ein guter Ansatz. Dort solltest du dir aber in jedem Fall eine sinnvolle Objektstruktur überlegen. Und da würde ich lieber ein bisschen mehr Zeit investieren. Denn eine schlechte Struktur kann das ganze unbenutzbar machen. Dann würde ich es wohl auch so machen, dass die Objektinstanzen sich die Daten des Models selber laden und selber komplett verwalten. Die würde ich für den Anfang vielleicht auch so machen, dass die sich jeweils ein eigenes VBO erstellen und verwalten. Denn wenn die sich den Speicher eines VBOs teilen wäre die Verwaltung nicht gerade einfach. Auch wenn es für das Rendern idealer wäre, wenn du nicht so häufig VBOs wechseln müsstet. Aber ich denke das kannst du erst mal raus lassen. Sondern die Anzahl der VBOs/Unterschiedlichen Objekte nicht zu groß ist.

Aber in jedem Falle solltest du in der Zeichenklasse deiner Engine nur mit den Instanzen sprechen. Also ohne, dass du genau weißt worum es sich dabei handelt.

Das Sortieren würde ich evtl per Design der Engine ausschließen. Also wenn du ein Model hast dann besteht dieses aus einzelnen Meshs und die können jeweils eine eigene Textur haben. Aber in der Modeldatei liegen ja einzelne Meshs schon so komplett gruppiert. Und da bräuchtest du eigentlich gar nicht mehr sortieren. Also da denke ich, dass du an einigen Stellen schon perse nicht sortieren müsstest.

Vertex vs. Primitiv: War evtl etwas seltsam von mir ausgedrückt. Aber wenn du Texturen hast dann können diese nur an einem Primitiv hängen. Das die Primitive wieder aus Vertices bestehen und die Vertices im VBO liegen ist klar. Aber da Texturen sich nur an Primitiven befinden können brauchst du ja gar nicht die Vertices zu sortieren sondern nur die Primitive. Bzw bei Modellen ja evtl sogar maximal nur die Meshs. Also wenn das Modelformat nichts anderes unterstützt.