Ich will Quake3 Maps rendern.

Ein Level wird in konvexe Leafs eingeteilt.

Ein Leaf
- besteht aus rund 10 Triangles
- ist statisch(Geometrie muss nicht verändert werden)
- besitzt eine feste Textur und eine feste Lightmap
- benötigt keine eigene Transformationsmatrix

Ein Level besteht aus ca. 2000 bis 4000 Leafs davon werden pro Frame ca. 30 gerendert.

So, wie ich das verstanden habe, sind DisplayListen vom Rendercontext abhängig, werden also im Arbeitsspeicher gelagert. VBOs dagegen werden im Videospeicher gelagert. Dennoch würden sicher viele Buffers gewechselt werden pro Renderpass.

Deswegen hier die Frage, DisplayListen hier besser?

Habe vorher noch nicht mit so wenigen Triangles gearbeitet.

Ich bräuchte ja rund 2000 bis 4000 DisplayListen, und ich habe gehört, dass sie sehr speicherintensiv sind. Spricht vllt. hier gegen DisplayListen.

mfg olli

_________________
Programmieren beginnt im Kopf und endet im Compiler

Hatte doch die Tests schneller programmiert, als ich dachte.

Ergebnis: DL und VBO nehmen sich rein garnix.

Getestet hatte ich 100 Leafs mit 8 Triangles.

1. Variante:
Positionen + Texturkoordinaten in einem GL_ARRAY_BUFFER
Indices für die Triangles in einem GL_ELEMENT_ARRAY_BUFFER

2. Variante:
Positionen in einem GL_ARRAY_BUFFER
Texturkoordinaten in einem GL_ARRAY_BUFFER
Indices für die Triangles in einem GL_ELEMENT_ARRAY_BUFFER

3. Variante
Positionen, Texturkoordinaten und Textur in einer DisplayList

Resultat:
Alle 3 Varianten liefen mit 26 FPS.

Hatte glaube damals mal das ganze mit glDrawRangedElements ausprobiert und somit alle Leafs in einem Buffer gespeichert. War dann aber glaube ich zu viel Daten(fehlerhafte Darstellung von einigen Leafs) und Geschwindigkeitsvorteile zu glDrawElements hats auch nicht gebracht.

Vllt. Hilft es ja jemanden.

mfg olli

_________________
Programmieren beginnt im Kopf und endet im Compiler

Das liegt daran, dass die Treiber intern bei Displaylisten wenn möglich VBOs verwenden Daher gibt es dann keine Performance-Unterschiede. Und sowohl Displaylisten als auch VBOs werden im Videospeicher abgelegt. VertexArrays liegen im Hauptspeicher. Aber nicht VBOs

_________________
"Für kein Tier wird so viel gearbeitet wie für die Katz'."

Danke, gut zu wissen!

Was mich aber noch interessiert:
Wenn ich mit VBOs arbeite, kann ich Indexbuffer verwenden. Sprich, bei einem Quad z. B. brauche ich nur 4 Vertices zu erstellen und gebe dann nur 3 Indices für die 2 Triangles an.

Bei Displaylisten muss ich 6 Vertices hintereinander angeben, also 2 mehr als bei den VBO.

Ist das event. schneller, dafür Speicherfressender? Bzw. für mich wäre es auch einfacher, bei den DisplayListen mit Indices zu arbeiten, da sie gleich so im Format vorliegen. Gibt es da eine Variante? Soetwas wie glIndexi() habe ich jetzt nicht gefunden.

mfg olli

_________________
Programmieren beginnt im Kopf und endet im Compiler

Das mit den Indizes ist auf jeden Fall schneller, weil Punkte die mehrfach benötigt werden dann zwischengespeichert werden können.
Außerdem sollte man bei so wenig Punkten und Indizes pro Leaf die Daten in einem Buffer zusammenfassen, so dass man weniger Buffer Wechsel hat. Die gesammten Vertex Daten des Levels könnten ja problemlos in einen Vertex Buffer.

Muss dich da mal ein bisschen Korrigieren/Erweitern. VBOs liegen nicht zwingend im Speicher der Grafikkarte. VBOs werden teilweise Clientseitig emuliert sollten sie nicht Hardwareseitig unterstützt werden. In diesem Falle geben sich sowohl VertexArrays, DL und VBOs von der Geschwnidigkeit her rein gar nichts. Genau so ist es auch bei den neuen PCIe Karten die keinen eigenen Speicher haben.

Vertex: Was hasten du für Grafikkarte? Ich persönlich finde 26 Frame für einen Level von Q3 doch ziemlich langsam. Das Original läuft mit über 200 und da sind noch Items, Player etc. drine.

Ich kann das nochmal ausprobieren, alles in einem VBO zu pappenn(am besten die Bézierleafs doch in einen sepperaten VBO). Ich hoffe bloß, dass dann glDrawRangeElements mit einem VBO schneller ist, als glDrawElements mit mehreren VBOs. Ist halt immer ein haufen Aufwand das zu testen.

Da kann ich ja gleichmal fragen, warum man bei VBOs glEnableClientState verwenden muss. Ich dachte das immer so, dass die Graka der Server ist, und der PC der Client. Aber VBOs kommen ja in den meisten Fällen in den VRAM sprich in den Server. Verstehe nicht, warum man das dann Clientseitig aktivieren muss. Und warum muss man das überhaupt aktivieren? Reicht denn glBindBufferARB nicht aus?

Habe eine Onboardgraka 915GL von Intel. Naja, UT 04 mit minimalen Einstellungen läuft recht flüssig. Quake3 sicher auch. Habs ja mit 100 Leafs probiert, und 30 eigentlich werden sicher nur gezeichnet.

mfg olli

_________________
Programmieren beginnt im Kopf und endet im Compiler

Achso nen Onboard Chip. Ne dann vergiss das was ich gesagt habe. Der hat sowieso keinen eigenen Speicher. Damit muss eh alles jedes mal über den AGP Bus geschickt werden. Ja auch selbst wenns Shared Mem ist. Der Chip ist für 3D Leistungen nicht aussagekräftg und wenn du in etwa 3 Mal so viel dargestellt hast wie sonst gemacht werden würde dann passt das schon. Brauchste also nichts testen.

Warum das ClientState heißt kann ich mir nur deshalb vorstellen, da VBOs nun mal auf Vertex Arrays aufbauen und die nun mal vollständig Clientseitig stattfinden. Also altertümliches Relikt.

Aktivieren musst du sie deswegen, damit OpenGL weiß welche Daten er auszuwerten hat. Und wenn dann auch wie viele. Also X TexturKoordinaten, Normalen, Farben, Nebelkoordinaten etc. Also musst du ihm genau sagen was du haben willst. Ist ja sonst auch so.

Zu VBOs kann ich dir folgendes Dokument von NVidia ans Herz legen. Darin sind einige praktische Tipps enthalten wie man seine Ausgabe noch beschleunigen kann. Das dürfte sich bei dir kaum bemerkbar machen daber dafür bei den anderen.

Perfekt, danke!

Das PDF werde ich mir jetzt mal zu Gemüte führen.

mfg olli

_________________
Programmieren beginnt im Kopf und endet im Compiler

Das mit den 26FPS ist völlig in ordnung so lange du noch nicht gecullt hast.
Ich hatte bei meinem Viewer auch so um die 30FPS, als ich die Szene ohne irgendwelche überprüfungen auf sichtbarkeit gerendert habe.
Wenn dies dann der fall ist gehts ab und man sollte auch beachten das die Quake3 levels viel mit Subsurfaces arbeitet und bei zu hoher einstellung geht die performance baden. Die "Shader" was ja nur Texturscripts sind nehmen so gut wie keine renderpower im vergleich mit dem rendern der geometrie.
So zumindestens war es bei meinem Viewer. Am ende hatte ich aber dann auch >300FPS mit einer 9800SE und 1024x768 Auflösung.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Na ja. Ist ja OnBoard Chip. Also da solltest du definitiv einen unterschied zwischen nicht texturiert und texturiert haben. Habe hier ne X300 ohne eigenen Speicher und die kotz auch sobald ein bissel mehr Textur dabei ist. Aber bei Karten mit eigenem Speicher (die Regel) ist das natürlich nicht so.