statische Geometrie in OpenGL effizient handlen

[Matti]

Was ist bei statischer Geometrie schneller: Display-Listen oder Vertex-Arrays?? ...oder gibts noch andere Möglichkeiten? ...und ab welcher OpenGL-Version gibts überhaupt Vertex-Arrays?

[Asmodeus]

Original geschrieben von Matti
Was ist bei statischer Geometrie schneller: Display-Listen oder Vertex-Arrays?? ...oder gibts noch andere Möglichkeiten? ...und ab welcher OpenGL-Version gibts überhaupt Vertex-Arrays?

Einfache Vertex-Arrays gibt es glaube ich ab OpenGL 1.1
Bei diesen werden aber sowohl Geometrie- als auch Indexdaten nur im Hauptspeicher abgelegt, was heutzutage wenig performant ist.

Für rein statische Geometrie sind Displaylisten voll ok würde ich sagen. Ansonsten kannst du auch einfach VertexBuffer verwenden, dank einer ARB-Extension laufen die dann auch problemlos sowohl bei Nvidia-, als auch auf Ati-Karten.

Carsten.

[Matti]

eigentlich verwende ich sehr gerne Display-Listen, weil das schön einfach geht, aber oft wird 1 Vertex von 4 Quads genutzt was ja in Display-Listen afaik nicht berücksichtigt wird, da muß man die gleiche Vertex insgesamt 4x setzen, mit Strips immerhin noch 2x.

...ist nur die Frage, ob sich das negativ auf die Performance auswirkt...

[Asmodeus]

Original geschrieben von Matti
eigentlich verwende ich sehr gerne Display-Listen, weil das schön einfach geht, aber oft wird 1 Vertex von 4 Quads genutzt was ja in Display-Listen afaik nicht berücksichtigt wird, da muß man die gleiche Vertex insgesamt 4x setzen, mit Strips immerhin noch 2x.

...ist nur die Frage, ob sich das negativ auf die Performance auswirkt...

Hängt immer auch davon ab, welche Daten du pro Vertex speicherst. Wenn Du z.B. pro Vertex 2 Texturkoordinaten, 3 Normalenkoordinaten und 3 Raumkoordinaten abspeicherst sind es schon mal maximal 8 * 4 Byte = 32 Byte pro Vertex. Angenommen, du speicherst nun 10 Vertices in einer Displayliste jeweils doppelt ab sind das 2 * 10 * 32 Byte = 640 Byte. Würdest du nun stattdessen einen VertexBuffer mit Index verwenden hättest du 10 * 32Byte = 320 Byte Geometriedaten und dazu noch 20 * 4 Byte = 80 Byte Indexdaten, was zusammen nur 400 Byte Daten sind. Wenn deine Objekte dann z.B. nur maximal 65535 Indices benötigen würdest Du sogar nur 2 Byte pro Index benötigen.
Die Ersparnis ist also schon enorm.

Carsten.

[Corrail]

Wie wärs mit VBO Vertex-Arrays? Ist eine Mischung zwischen reinen Vertex-Arrays und Display lists.

[Asmodeus]

Original geschrieben von Corrail
Wie wärs mit VBO Vertex-Arrays? Ist eine Mischung zwischen reinen Vertex-Arrays und Display lists.

Du meinst sicher damit, dass man in einem VBO (VertexBuffer) die Daten ja genauso ablegen kann wie in einem Vertex Array (also Geometriedaten und Indexdaten voneinander getrennt), oder?

Carsten.

[Corrail]

Ja, genau. Aber der Vorteil davon ist, dass die Daten im Server-Memory gespeichert sind, und nicht im Client-Memory. Dadurch ist es theoretisch annähernd so schnell wie die display lists.
In der Realität ist die Performance (was ich so gelesen habe) zwischen echten display lists und normalen vertex arrays. Der riesige Vorteil von VBO vertex arrays ist aber, dass sie um einige flexibler sind.

[zeckensack]

Original geschrieben von Corrail
Ja, genau. Aber der Vorteil davon ist, dass die Daten im Server-Memory gespeichert sind, und nicht im Client-Memory. Dadurch ist es theoretisch annähernd so schnell wie die display lists.
In der Realität ist die Performance (was ich so gelesen habe) zwischen echten display lists und normalen vertex arrays. Der riesige Vorteil von VBO vertex arrays ist aber, dass sie um einige flexibler sind. Würde ich nicht unbedingt unterschreiben wollen.
Das "Problem" bei VBOs ist, dass der Treiber im Gegensatz zu display lists nicht die Möglichkeit hat, Formatumwandlung durchzuführen. Dh wenn du pro-Vertex-Farben mit 3 shorts angibst, wird der display list-compiler dies eliminieren, und ein für die Hardware vernünftiges Format daraus machen. Bei VBOs geht das nicht, weil sie nur ein Haufen von Bytes sind. Das Format der Daten ist nicht fix, und der Treiber muss die Daten so speichern, wie du sie lieferst.

Man muss also viel mehr aufpassen, dass man ein sinnvolles Vertex-Layout benutzt.
Am sichersten sind floats für Position, Normalen und Texturkoordinaten, und 4 unsigned bytes für Farbe.
Wenn man das beachtet, sind VBOs (zumindest mit STATIC_DRAW) kein Stück langsamer als display lists.

VBOs sind auf NVIDIA-Karten mit einigen Treibern der 40er und 50er Serie sogar schneller als display lists. Ist IMO eher ein Treiber-Bug, aber trotzdem eine nette Anekdote.

[Asmodeus]

Original geschrieben von zeckensack

...

Man muss also viel mehr aufpassen, dass man ein sinnvolles Vertex-Layout benutzt.
Am sichersten sind floats für Position, Normalen und Texturkoordinaten, und 4 unsigned bytes für Farbe.
Wenn man das beachtet, sind VBOs (zumindest mit STATIC_DRAW) kein Stück langsamer als display lists.

...



Ich finde es nur schade, dass man bei den VBOs über die Tokens wie STATIC_DRAW usw. nicht wirklich beeinflussen kann, wo die Sachen dann landen (VideoRam, AGPRam oder Hauptspeicher). Denn bindend sind die Sachen ja nicht, der Treiber kann es trotzdem ablegen, wo er es für richtig hält.
Da war mir die volle Kontrolle z.B. bei NV_Vertex_Array_Range lieber.

Carsten.

[Corrail]

Naja, bei Texturen hast du ja auch nicht volle Kontrolle. Ok, da hast du Möglichkeit Prioritäten zu setzen, aber volle Kontrolle hast du trotzdemm nicht.

Original geschrieben von zeckensack
...


Cool, vielen Dank für die Tipps. Hab ich nicht bis jetzt noch nicht so betrachtet. Ich verwende zwar eh immer float, ist aber trotzdem gut zu wissen dass man darauf so viel achten muss.

[Matti]

Original geschrieben von zeckensack
VBOs sind auf NVIDIA-Karten mit einigen Treibern der 40er und 50er Serie sogar schneller als display lists. Ist IMO eher ein Treiber-Bug, aber trotzdem eine nette Anekdote.

heißt das, daß Display-Listen idR aber schneller sind, oder wie?

[marco42]

Original geschrieben von Matti
heißt das, daß Display-Listen idR aber schneller sind, oder wie?

Sollten, aber VA + DL sind die sicherste Option. VBO's sind IMHO bald die Option der Wahl.

[Asmodeus]

Wenn man es sich genau überlegt ist es gar nicht so leicht, ne allgemeingültige Antwort zu finden, da es bei jeder Technik Vor- und Nachteile gibt.

Vielleicht noch mal als kurze Übersicht:

Displaylisten:

+ einfache Handhabung
+ Treiber optimiert die Listen "perfekt"

- keine Trennung zwischen Geometriedaten und Indexdaten


Vertex Arrays nach OpenGL 1.1:

+ Trennung von Geometrie- und Indexdaten möglich

- alle Daten können nur im Hauptspeicher liegen (langsamer)
- Optimierungen der Datenformate muss von Hand erfolgen


Vertex Arrays mit NV_Vertex_Array_Range:

+ Trennung von Geometrie- und Indexdaten möglich
+ Geometriedaten können in Video- oder Agp-Ram geschrieben werden

- Indexdaten liegen weiterhin nur im Hauptspeicher
- Optimierungen der Datenformate muss von Hand erfolgen
- Speicherverwaltung muss von Hand erfolgen
- nur auf Nvidia Karten einsetzbar

VertexBuffer mit ARB_Vertex_Buffer_Object:

+ Trennung von Geometrie- und Indexdaten möglich
+ Geometrie- und Indexdaten müssen nicht mehr im Hauptspeicher liegen
+ Speicherverwaltung übernimmt der Treiber

- Treiberoptimierung kann noch hinter Treiberoptimierung von Displaylisten liegen (da noch relativ neu)


Diese Aussagen treffen natürlich nur auf statische Daten zu, bei dynamischen Daten sieht es schon wieder ganz anders aus.

Carsten.

Edit: Fehler korrigiert.

[zeckensack]

Original geschrieben von Matti
heißt das, daß Display-Listen idR aber schneller sind, oder wie? Schneller nicht. Wenn man bei VBOs alles richtig macht (s.o.), dann gibt es keinen vernünftigen Grund, warum ein mit STATIC_DRAW definiertes (und auch entsprechend genutztes!) VBO eine andere Performance haben sollte, als eine rein Geometrie enthaltende display list.

Man kann auch bei display lists Sachen "falsch" machen.
Am Ende ist's aber garnicht so schwer:
Beide Verfahren führen im Optimalfall dazu, dass ein dichtes Vertex Array mit nativ unterstützem Datenformat im Grafikspeicher liegt.

DL oder STATIC_DRAW-VBO ist nur ein Frage der API, nicht eine Frage des Ergebnisses. Beide nutzen die selben Hardware-Ressourcen und sind IMO defintiv exakt gleich schnell implementierbar.

Jegliche Schwankungen schiebe ich auf die Treiber.
Der 52.16er Deto zB hat display lists im System-Speicher geparkt, und nur mittels PCI66-Transfers an die Karte geschickt (jedenfalls deckt sich diese Theorie ganz ausgezeichnet mit den Zahlen, die ich sah).

[Matti]

hab mir mal die Quellcodes von einem Vertex-Array- & einem VBO-Tutorial angesehen, und beide schreiben die Vertexen für jedes Quad neu in's Array, obwohl 1 Vertex von 4 Quads genutzt wird...
...ich dachte eigentlich daß der Sinn von Vertex-Arrays der ist, daß man 1 Vertex nur 1x an OpenGL übergeben muß, auch wenn sie mehrfach verwendet wird. Hat jemand dazu vielleicht Quellcode?

[Asmodeus]

Original geschrieben von Matti
hab mir mal die Quellcodes von einem Vertex-Array- & einem VBO-Tutorial angesehen, und beide schreiben die Vertexen für jedes Quad neu in's Array, obwohl 1 Vertex von 4 Quads genutzt wird...
...ich dachte eigentlich daß der Sinn von Vertex-Arrays der ist, daß man 1 Vertex nur 1x an OpenGL übergeben muß, auch wenn sie mehrfach verwendet wird. Hat jemand dazu vielleicht Quellcode?

In dem Tutorial wurde dann sicher ohne Indices gearbeitet, nur mit reinen Geometriedaten. Zur Anzeige nimmt man da dann meistens den Befehl glDrawArrays(), der ziemlich ineffizent ist.
Wenn man mit Geometrie- und Indexdaten arbeitet (jeder Vertex also wirklich nur noch einmal abgespeichert wird) verwendet man dann den Befehl glDrawElements() zur Anzeige der Geometrie.

Edit:

Links:

Doku zu Vertex Arrays (http://www.opengl.org/documentation/specs/version1.1/glspec1.1/node21.html)

Delphi Beispiel mit Quellcode (http://www.delphi3d.net/download/vertexstream.zip)

Carsten.

[Matti]

es gibt ja noch eine Extension GL_EXT_compiled_vertex_array. Jedoch blicke ich bei der Bedeutung der Parameter von LockArraysEXT nicht durch...

[Corrail]

AFAIK bringt sich GL_EXT_compiled_vertex_array nur was, wenn du traditionellen Vertex Arrays verwendest (also kein VBO). Wenn du glLockArrays aufrufst, so sperrst du gewisse Teile von den Arrays, die du per glVertexPointer/glColorPointer/... übergeben hast. Du sagt OpenGL damit, dass du diese Teile nicht mehr veränderst. Dadurch kann OpenGL diese Teile vorbearbeiten, z.B. in den Grafikkartenspeicher laden.

[Matti]

wie das prinzipiell funktioniert, war mir klar, aber:

void LockArraysEXT (int first, sizei count)

Wieso ist der 1. Parameter int und kein Pointer? Außerdem hat man ja Index- & Vertex-Array, also müßte man ja 2 Pointer übergeben. Was zählt count: Vertexen, Bytes oder ...?

[Corrail]

Wieso ist der 1. Parameter int und kein Pointer?


Das ist das gleiche wie glDrawArrays. Da hast du auch einen ersten Index und eine Anzahl an Elementen, die gezeichnet werden sollen.


Außerdem hat man ja Index- & Vertex-Array, also müßte man ja 2 Pointer übergeben. Was zählt count: Vertexen, Bytes oder ...?


Er geht auf die Vertex/Color/TexCoord Arrays, die Inidces bleiben unberührt.

[Matti]

Wenn die Indices nicht gelockt werden können, ist es doch (auf T&L-Karten) langsamer, als ne Display-Liste, oder?

[Corrail]

Ja, theoretisch sollte es langsamer sein. Dafür hast du halt mehr Flexibilität.

[hi]

Original geschrieben von Asmodeus
...den Befehl glDrawArrays(), der ziemlich ineffizent ist.

[...]

Wieso das denn?

mfg

[Asmodeus]

Original geschrieben von hi
Wieso das denn?

mfg

Bei glDrawArrays() müssen die Geometriedaten viele redundante Vertices enthalten, da ohne Indexdaten gearbeitet wird. Somit ist in den meisten Fällen der Overhead grösser, als wenn Du mit Geometrie- und Indexdaten arbeitest und glDrawElements() verwendest.

Ist weiter vorn im Topic noch mal genauer erklärt.

Carsten.

[zeckensack]

Original geschrieben von Asmodeus
Bei glDrawArrays() müssen die Geometriedaten viele redundante Vertices enthalten, da ohne Indexdaten gearbeitet wird. Somit ist in den meisten Fällen der Overhead grösser, als wenn Du mit Geometrie- und Indexdaten arbeitest und glDrawElements() verwendest.

Ist weiter vorn im Topic noch mal genauer erklärt.

Carsten. Die Unterscheidung ist irrelevant bei sehr langen strips (Terrain zB).

[hi]

Original geschrieben von zeckensack
Die Unterscheidung ist irrelevant bei sehr langen strips (Terrain zB).

Hierbei dürfte drawarrays() sogar um einiges schneller sein.

[Asmodeus]

Original geschrieben von zeckensack
Die Unterscheidung ist irrelevant bei sehr langen strips (Terrain zB).

Da hast Du zwar recht, aber Terrain ist nun mal eine Art "Sonderfall", denn meist überträgt man da pro Vertex ja nur die Raumkoordinaten. Bei Objekten, bei denen auch Texturkoordinaten und Normalenkoordinaten übertragen werden müssen spart man mit Indices schon enorm.

Carsten.

[zeckensack]

Original geschrieben von Asmodeus
Da hast Du zwar recht, aber Terrain ist nun mal eine Art "Sonderfall", denn meist überträgt man da pro Vertex ja nur die Raumkoordinaten. Bei Objekten, bei denen auch Texturkoordinaten und Normalenkoordinaten übertragen werden müssen spart man mit Indices schon enorm.

Carsten. Verstehe ich jetzt nicht. Das würde Sinn machen, wenn man getrennte Indizes für Position, Texturkoordinaten, etc, hätte. Hat man unter OpenGL bekanntlich nicht.

Ausserdem kann man auch für Terrain-Rendering ganz gut andere Vertex-Attribute brauchen. Nicht jeder kann - oder will - TexGen benutzen.

Es ging mir einfach nur darum, dass GL_TRIANGLE_STRIP von Hause aus vertices wiederverwertet, und man durch explizite Indizes also nichts einspart. Ganz anders wäre es bei GL_TRIANGLES.

Terrain ist nur ein Beispiel für Strips. Man kann ja beliebige geschlossene Körper in Strips zerlegen, gerade bei hohen Polygoncounts ist das recht attraktiv. Gibt ja auch Tools dafür.

[Matti]

auch bei Strips wird doch (fast) jede Vertex 2x benötigt, oder?
...also müßte man mit Indices auch schneller sein...

[Corrail]

Theoretisch schon, aber bei großen Terrains liegen die Vertices die doppelt gebraucht werden meist weit auseinandern (nich im geomatrischen Sinne, sonder in der Bearbeitungsreihenfolge). Somit müssten viele Vertices zwischengespeichert werden. Die Grafikkarten haben aber meist nicht so einen großen Cache für das (ca. 20 Vertices zwischenspeicherbar, bin mir da aber überhaupt nicht sicher).

[marco42]

Original geschrieben von Corrail
Theoretisch schon, aber bei großen Terrains liegen die Vertices die doppelt gebraucht werden meist weit auseinandern (nich im geomatrischen Sinne, sonder in der Bearbeitungsreihenfolge). Somit müssten viele Vertices zwischengespeichert werden. Die Grafikkarten haben aber meist nicht so einen großen Cache für das (ca. 20 Vertices zwischenspeicherbar, bin mir da aber überhaupt nicht sicher).

Dafuer gibt es aber spezielle Algorithmen die die Lokalitaet verbessern, steht zB in Real Time Rendering von Moeller.

[Corrail]

*hm* Mal nachschaun...
Oh, ok. Soweit hab ich noch nicht gelesen! ;D

[Asmodeus]

Original geschrieben von zeckensack
Verstehe ich jetzt nicht. Das würde Sinn machen, wenn man getrennte Indizes für Position, Texturkoordinaten, etc, hätte. Hat man unter OpenGL bekanntlich nicht.

Ausserdem kann man auch für Terrain-Rendering ganz gut andere Vertex-Attribute brauchen. Nicht jeder kann - oder will - TexGen benutzen.

Es ging mir einfach nur darum, dass GL_TRIANGLE_STRIP von Hause aus vertices wiederverwertet, und man durch explizite Indizes also nichts einspart. Ganz anders wäre es bei GL_TRIANGLES.

Terrain ist nur ein Beispiel für Strips. Man kann ja beliebige geschlossene Körper in Strips zerlegen, gerade bei hohen Polygoncounts ist das recht attraktiv. Gibt ja auch Tools dafür.

Da geb ich dir recht, ich hätte genauer formulieren sollen:

Bei Objekten, die auch Textur- und Normalenkoordinaten verwenden, und nicht als Strip vorliegen können, spart man mit Indices enorm. ;)

Wo ist Deiner Meinung nach glTexGen (oder die Generierung der Texturkoordinaten in einem Shader) bei Terrain eher unangebracht?

Carsten.

[Matti]

Original geschrieben von marco42
Sollten, aber VA + DL sind die sicherste Option. VBO's sind IMHO bald die Option der Wahl.

VBO kommt für das Projekt aus Kompatibilitäts-Gründen nicht in Frage.

Ein Vertex-Array in eine Display-Liste reinstecken ist zwar auf nicht-T&L-fähigen Grakas meist optimal, aber bei T&L gibts 2 Möglichkeiten, die beide nicht optimal sind:
-DL führt nur DrawElements aus -> langsam
-Vertex-Array wird in DL reincompiliert -> Daten sind im Haupt- UND Grafikkarten-Speicher -> Speicherverschwendung

[zeckensack]

Original geschrieben von Asmodeus
Da geb ich dir recht, ich hätte genauer formulieren sollen:

Bei Objekten, die auch Textur- und Normalenkoordinaten verwenden, und nicht als Strip vorliegen können, spart man mit Indices enorm. ;)Ich versteh's immer noch nicht :|
Wenn sie nicht als Strips vorliegen können, klar, so weit kann ich folgen.
Was ich nur nicht raffe (und auch beim ersten Mal nicht gerafft habe) ist warum du Texturkoordinaten und Normalen erwähnst. Was macht das für einen Unterschied? ?(
Dadurch werden die einzelnen verts grösser, aber das Einsparpotential (oder auch die Abwesenheit davon) durch Indizes bleibt gleich. Das hängt nur von der Topologie ab.
Wo ist Deiner Meinung nach glTexGen (oder die Generierung der Texturkoordinaten in einem Shader) bei Terrain eher unangebracht?

Carsten. Überall da, wo das Terrain nicht flach ist =)
Wenn man Texturkoordinaten als Funktion der Position auf der x/z-Ebene generiert, verzerren sich die Texturen eben umso mehr, je steiler das Terrain ist. Das Verhältnis zwischen der Fläche eines Terrainstücks und des projizierten Abstands der vertices auf der x/z-Ebene hängt eben mit der Steilheit zusammen. Für ordentliche Resultate will man aber eine möglichst konstante Menge an Texeln pro Flächeninhalt, nicht pro Einheit projizierten Abstands.

IMO ist's besser, wenn man die Künstler da von Hand flicken lässt (=> explizite Texturkoordinaten). Es gibt schlicht keine lineare Funktion, die dieses Problem lösen kann. Dafür muss man schon die Kontinuität unterbrechen können. Am elegantesten löst man das, indem man "oben auf der Alm" einfach ein weiteres Terrain-Mesh einflickt. ZB unten Gras, oben Stein oder sowas.

In Gothic 2 gibt's eine recht markante Stelle, wo das derbe schief gelaufen ist. Ich kann später mal einen Screenshot posten, falls Bedarf besteht.

[zeckensack]

Original geschrieben von Matti
VBO kommt für das Projekt aus Kompatibilitäts-Gründen nicht in Frage.Och, bitte ;(

Zwei Möglichkeiten:

1)Schreib eine Vertex-Array-Klasse, die dir das ganze wegabstrahiert, und dann nutze innerhalb dieser Klasse VBOs falls sie unterstützt werden.
*hust*
class
VertexBuffer
{
<...>
static bool use_vbo;
};

2)Schreib ein paar Funktionen, die dir VBO-Funktionalität (und alle von dir genutzten gl*Pointer-Funktionen) auf "klassische" VAs wrappen.

[Asmodeus]

Original geschrieben von zeckensack
Ich versteh's immer noch nicht :|
Wenn sie nicht als Strips vorliegen können, klar, so weit kann ich folgen.
Was ich nur nicht raffe (und auch beim ersten Mal nicht gerafft habe) ist warum du Texturkoordinaten und Normalen erwähnst. Was macht das für einen Unterschied? ?(
Dadurch werden die einzelnen verts grösser, aber das Einsparpotential (oder auch die Abwesenheit davon) durch Indizes bleibt gleich. Das hängt nur von der Topologie ab.

Ich bin immer vom Datenaufkommen ausgegangen:

Will ich für nicht gestripte Geometrie einen Vertex mit Raum-, Textur- und Normalenkoordinaten zwei Mal übertragen entspricht das einem Datenaufkommen von 2 * 32 Byte. Übertrage ich den Vertex jetzt nur einmal und zusätzlich 2 Indices beträgt das Datenaufkommen nur 1 * 32 Byte + 2 * 2 Byte.

Habe ich nur Raumkoordinaten pro Vertex sieht das Verhältnis für die Variante mit Indices schlechter aus:

(2 * 12 Byte) zu (1 * 12 Byte + 2 * 2 Byte)

Das Einsparpotential ist also mit Textur- und Normalenkoordinaten grösser.


IMO ist's besser, wenn man die Künstler da von Hand flicken lässt (=> explizite Texturkoordinaten). Es gibt schlicht keine lineare Funktion, die dieses Problem lösen kann. Dafür muss man schon die Kontinuität unterbrechen können. Am elegantesten löst man das, indem man "oben auf der Alm" einfach ein weiteres Terrain-Mesh einflickt. ZB unten Gras, oben Stein oder sowas.

Stimmt, aber es gibt nun mal auch Anwendungsgebiete, in denen kein Künstler erst noch handanlegen kann, sondern schnell Ergebnisse erwünscht sind. ;)


In Gothic 2 gibt's eine recht markante Stelle, wo das derbe schief gelaufen ist. Ich kann später mal einen Screenshot posten, falls Bedarf besteht.

Ja, das würde mich interessieren.

Carsten.

[zeckensack]

.

[Asmodeus]

Ups, das sieht wirklich übel aus. Scheint beim Betatesten dann wohl glatt übersehen worden zu sein.

Carsten.

[Matti]

@zeckensack
klar könnte man 2 Pfade schreiben, aber lohnt sich der Aufwand? Also ist ein VBO überhaupt merklich schneller als Strips in einer Display-Liste?

[zeckensack]

Original geschrieben von Matti
@zeckensack
klar könnte man 2 Pfade schreiben, aber lohnt sich der Aufwand? Also ist ein VBO überhaupt merklich schneller als Strips in einer Display-Liste? Falsche Frage ;)
Vom reinen Durchsatz her nein, schon garnicht bei statischer Geometrie. Wie ich bereits früher schrieb, sollte es einen Gleichstand zwischen den beiden Methoden geben.

VBOs sind einfach flexibler. Du kannst sie effizienter wiederverwenden, wenn das nötig sein sollte (eine DL kann man nur komplett löschen und eine neue erstellen; ein VBO kann man einfach neu befüllen). Der Kompiliervorgang für eine DL ist wesentlich teurer als das Füllen eines VBOs, weil DLs einfach viel mehr können müssen als nur Geometrie zu halten.

Es ist für rein statische Geometrie, die komplett in den Grakaspeicher passt und sich zur Laufzeit nie ändert (ala Techdemo in einem zwei Quadratmeter grossen geschlossenem Raum) wirklich Jacke wie Hose.

Du wirst aber in einem realen Projekt nie diese Einschränkungen haben. Für irgendwas wirst du dynamische Geometrie brauchen, und du wirst ab und an länger nicht mehr genutzte Meshes wegschmeissen müssen, weil dir sonst der Speicher ausgeht. Und dann sind VBOs wirklich klar besser, wenn auch nur aus dem Grund, dass du dann für alle Meshes (egal ob statisch oder nicht) das gleiche Interface benutzen kannst.

Preisfrage: ist es möglich, Vertex Array-Funktionalität auf Display Lists zu wrappen? Wenn nein, warum nicht?

[Corrail]

Original geschrieben von zeckensack
Preisfrage: ist es möglich, Vertex Array-Funktionalität auf Display Lists zu wrappen? Wenn nein, warum nicht?

Wenn ich dich richtig verstanden habe ist das gegen das Prinzip der DL. Eine DL soll ja eine statische Folge von Befehlen speichern und soll jederzeit (naja, nicht ganz in jedem Zustand der OpenGL Machine) unabhängig ausführbar sein.

[Matti]

Original geschrieben von zeckensack
Preisfrage: ist es möglich, Vertex Array-Funktionalität auf Display Lists zu wrappen? Wenn nein, warum nicht?

klar isses möglich, man muß nur die DLs jedesmal neu compilieren ;D ;D ;D