Hallo!
Nach langer Zeit habe ich mich mal wieder dazu entschlossen meine OpenGL- und Programmierkenntnisse zu erweitern.
Ich arbeite im Moment an einer "3D-Grafikengine" zur Darstellung und Organisation texturierter, teilw. beweglicher Objekte.
Einen Heightmap-Terrainrenderer hab ich auch eingebaut.
Bisher läuft meine Organisation beim Rendern der Objekte so:
- Das Terrain und alle anderen statischen Objekte render ich über Displaylisten, die beim Laden des der Umgebung erstellt werden.
- Dynamische Objekte render ich so, dass ich jedesmal glBegin... glEnd-Schleifen aufrufe, vorher die jeweilige Textur binde, GL_Lighting ein-/ oder ausschalte usw.

Ich bin mir ziemlich sicher, dass zumindest das Rendern der dynamischen Objekte um einiges performancesparender gehen sollte. Ich hab mir mal Vertex-Arrays angeguckt, bin mir aber nicht sicher, ob das so viel schneller ist. Ich weiß auch nicht, wie ich DAS organisieren soll :) Deshalb meine Frage:

Wie organisiere ich das Rendern einer komplexen Scene mit unterschiedlich texturierten und beweglichen und statischen Objekten? Welche Techniken verwendet man?

Vielen Dank :)



(Sollte ich irgendeine wichtige Angabe vergessen haben, sagt Bescheid)

Hallo Rüdiger,

eines vorweg. Was "engines" angeht bin ich nicht der Crack hier im Forum. Ich würde dir aber empfehlen VertexBufferObjects zu benutzen. Die klassischen VertexArray liegen nur im Speicher der Anwendung weswegen es kaum wirklich viele Vorteile mit sich bringt. VBOs hingegen liegen im Speicher der Grafikkarte wodurch auf diese mit wesentlich größerer Geschwindigkeit zugreifen werden kann. Dazu solltest dur dir mal unser VBO Tutorial anschauen.

Bei VBOs solltest darauf achten, dass du diese Buffer nicht zu klein machst, denn das aktivieren dieser Buffer kostet auch etwas Zeit. Es besteht auch die Möglichkeit mehrere von deinen Objekten in einen Buffer zu packen und dann beim Rendern mal kurz die Textur zu wechseln und dann weiter zu rendern. Da wirst du auch nicht drumherum kommen.

Bei einem VBO kannst du angeben wie du es verwenden möchtest. Also Ob du es gar nicht mehr veränderst oder ob du es häufig verändern möchtest. Das ermöglicht dem Treiber intern etwas besser optimieren zu können. Du solltest von daher deinen Heightmap und deine dynamischen Objekte in unterschiedliche Buffer packen.

Mit VBOs kannst du auch LOD und ähnliches realisieren. Das liegt darin begründet, da du sowohl einen Vertexdatenbuffer als auch einen Indexbuffer haben kannst. Du kannst zum Beispiel die Daten deines Objektes komplett hochladen und erstellst 2-3 unterschiedliche Indexbuffer je nach LOD. Dadurch kann man unter anderem das mehrfache Halten von Daten vermeiden. Oder für die dynamischen Objekte ist es auch möglich, dass du nur die Vertexdaten ersetzt und der Rest absolut gleich bleibt. Dadurch musst du nicht alles zur Karte schicken sondern nur kleine Bröckchen.

Deiner Phantasie sind dabei keine Grenzen gesetzt.

Danke für die schnelle Antwort!

Ja, ich hab mir das Tutorial auch schon mal durchgelesen. Ich verstehe nur nicht, wie das mit Objekten funktioniert, die unterschiedliche Texturen haben.
Angenommen wir haben 10 Quadrate und 10 Dreiecke im Raum mit jeweils 10 unterschiedlichen Texturen. Ich würde dann alle Vertexdaten in einem Array in das VBO packen und beim Rendern folgendes tun:
- Textur binden
- glDrawArrays ausführen
Diese beiden Schritte müsste ich dann aber für alle Objekte erledigen, oder? Schließlich haben ja hier alle Objekte eine andere Textur. Und selbst, wenn sie alle die selbe Textur hätten, müsste ich glDrawArrays mindestens zweimal ausführen, weil wir ja einmal GL_Quads und GL_Triangles rendern müssen. Seh ich das richtig, oder mache ich irgendwo nen Denkfehler? Ist das dann denn trotzdem noch schneller?

In den VBOs liegen nur Daten über die Vertices. Also wo sie sich befinden (Vertex) und welche Stelle der Textur sie benutzen (TexturKoordinaten) uvm. Du bindest eine Textur und anschließend zeichnest du 200 Vertices aus einem VBO. Dann bindest du einen andere Textur und zeichnest die nächsten 200 Vertices aus dem selben VBO usw. Oder noch mal die Ersten, wenn sich nur die Textur geändert hat. Das hast du so schon vollkommen richtig erkannt.

Wenn es anstelle von 200 Vertices nur 4 oder 6 sind und es nicht anders geht (weil sie alle eine eigene Textur habe), dann ist es halt so. Du solltest nur darauf achten, dass du nicht wegen jeder kleinen Fläche das VBO wechseln musst. Denn zu extreme Wechseleien sollte man vermeiden, denn das Aktivieren eines VBOs kostet nun mal auch ein bisschen Zeit. Genau das Gleiche trifft normal auch für Texturen zu. Also zu extrem häufiges Wechseln sollte vermieden werden. Wenn es denn Möglich ist.

Zur Geschwindigkeit. Bei 10 Quads und 10 Dreiecken würde ich mir darum keine Gedanken machen, denn das sind keine Größenordnungen bei denen es Kritisch wird. Aber VBOs entfalten normal erst bei etwas größeren Datenmengen ihr wahre Geschwindigkeit. Bei den 20 Primitiven wirst du wahrscheinlich keinen Unterschied feststellen können. Und wenn doch dann würde dieser wohl recht gering ausfallen.

GL_QUAD vs GL_TRIANGLE: Ich würde versuchen einheitlich Dreiecke zu benutzen, da hast du zwar ein paar Daten mehr aber kannst so an einem Stück rendern. Bzw mit weniger OpenGL Aufrufen. Auch wenn ich nicht denke, dass es bei der Anzahl an Objekten sonderlich ins Gewicht fallen würde.

Gut, danke :) Dann werde ich das jetzt mal implementieren.

Eine letzte Frage hab ich noch: Macht die Methode mit den VBOs denn - performancebetrachtet - immernoch Sinn, wenn man auf jedem Objekt eine andere Textur hat(ich denke da z.B. an Lightmaps), oder benutzt man in dem Fall eine andere Methode?

Also Lightmaps gehören normal via Multitexturing auf deine Objekte gepackt. Du hast in OpenGL, auf neueren Karten mit Shadern, bis zu 16 Textureinheiten. Und bei einer Lightmap (wie sie in Spielen benutzt werden) steckt normal in einer einzigen Textur auch die Lightmap für einen ganzen Level. Oder für einen Großteil davon.

Die Frage ist bei 10 Flächen natürlich durchaus berechtigt. Da macht es eher kaum Sinn auf so etwas wie VBOs zu setzen. Aber du hast in deinem ersten Post von so etwas wie einer Engine und einer Landschaft geredet. Und dafür macht es schon wieder mehr Sinn. Zu mal die DLs intern ja auch wieder nur VBOs (sofern vorhanden) benutzen. Aber DLs sind extrem unflexibel. Und mit VBOs wäre es zum Beispiel auch möglich, dass unterschiedliche Objekte sich die gleichen Texturkoordinaten teilen (Speicherersparnis) etc.

Die genau Antwort auf diese Frage kannst allerdings nur du dir selber geben. Und zwar in dem du dir überlegst was du eigentlich vor hast. Wir wissen das ja nicht.

So.
Mühevoll hab ich jetzt das Rendern über VBO's implementiert.

Falls es wen interessiert:

Meine Rendermaschinerie läuft jetzt so:

Einmalig:
- Es wird eine Displayliste für statische Objekte erstellt. Diese rendert sich aus den Vertexdaten, die einem VBO vorher übergeben werden. (Ich glaube, das ginge auch nur mit Vertexarrays, oder? Hat das einen Sinn, die Daten aus einem VBO zu übergeben?)
Hier werden die Objekte nach Texturzugehörigkeit sortiert.

- Momentan wird die Heightmap noch aus "glBegin...glEnd"-Primitiven in eine Displayliste gerendert. Obige Methode ist jedoch auch hierfür geplant.

- Die dynamischen Objekte werden mit ihren Vertices in ein VBO im Grafikkartenspeicher geladen. Dabei sortiere ich die Primitiven wieder nach Texturzugehörigkeit.


Bei jedem Rendern:
- Die Modelview-Matrix wird so eingestellt, dass man die gewünschte Perspektive/Position hat.
- Die Displaylisten werden aufgerufen.
- Die dynamischen Objekte werden über glDrawArrays gerendert.

Also wenn du deine Daten bereits in einem VBO hast dann macht die Benutzung einer Displayliste eigentlich keinen wirklichen Sinn mehr. Je nach konstellation kann es sogar nachteilig sein. Denn wenn du in dem VBO Daten übergibst würden die dann bei jedem Aufruf der Displayliste auch übergeben werden. Was ja eigentlich quatsch ist, da sich die Daten nie ändern werden. Und wenn du das VBO aufrufst spart du so eigentlich keine Zeit. Und selbst wenn wäre das nicht messbar.