Ich nutze bei mir für mehrere Dinge Displaylisten. Rendern lassen tue ich über Vertex Arrays doch vorhin bin ich über folgende Aussage gestoßen:


Auch auf einer anderen Seite wurde etwas ähnliches berichtet. Aber warum ist das so? Ich meine die Befehle funktionieren ja in einer Displaylist?!

Iirc ist es dann so, dass die Vertices aus den Arrays in die Liste „kopiert“ werden.


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

Okay.

Könntest du mir vllt. auch noch erklären wie ein "optimaler" Renderdurchgang aussieht (oder auch zeigen wo ich das durchlesen kann)? (Bei OpenGL <= 3.0).
Bisher hab ich halt die Vertices von einem Objekt eingelesen, diese Sortiert und dann in ein dynamisches Array bei mir gepackt.
Danach wird noch eine jeweilige Texture zugewiesen mit glBindTexture und es folgt das Rendern:


Damit ich nicht zu viele Calls habe, lasse ich das Texturweise abarbeiten. Heißt also wenn ich 5 Texturen habe, dann wird Texture 1 geladen, alle Polygone die diese Texture nutzen werden in das jeweilige Array gepackt (also Vertices, Normals, Texture) und es wird gerendert. So habe ich also bei 5 Texturen auch nur 5 glDrawArrays Aufrufe.
Das kommt halt noch alles in eine Displaylist und so hielt ich es eigentlich für einen guten Durchgang. Zumal die Displaylist ja auch nur die OpenGL Befehle enthalten hat und nicht den anderen "Kram" wie das sortieren etc.
Nur wenn ich mir die Performance anschaue, kann das nicht das Wahre sein. 10.000 Polys bringen 1500 Frames, 20.000 Polys nur noch ~700-800 usw. das geht ziemlich schnell bergab. Und mit einem 2500k + HD 5870 sollte doch etwas mehr drin sein.

Ich hatte mir dazu auch schon folgendes durchgelesen:
http://wiki.delphigl.com/index.php/Performance

Wirklich viel optimieren konnte ich jedoch trotzdem nicht :/

Hm, wenn du deine Daten sowieso in einem Array schon vorgegeben hast, warum benutzt du dann keine VBOs?

Ansonsten immer noch die Frage, warum du Displaylisten benutzt. Wenn die Daten sich jeden Frame ändern (wegen Sortierung oder sonstwas) kann man entweder direkt Rendern oder nen GL_STREAM_DRAW-VBO erzeugen. Wenn nicht ist ein VBO mit GL_DYNAMIC_DRAW / GL_STATIC_DRAW vermutlich angebrachter. Ich weiß nicht, inwiefern Displaylisten auf VBOs optimieren können.

Wegen der Frameraten kann es gut sein, dass das zu beginn stark fällt, aber wie sieht das denn für 100k oder 1M Triangles aus?

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

Da ist was dran aber da ich dort nur statische Sache rendere, dachte ich es tut auch eine Displaylist. Zumal ich hier im Forum auch schon öfter gelesen habe, dass bei aktueller Hardware eine Displaylist intern sowieso als VBO behandelt wird.

Habe mal gemessen:
16.000 Polys: 1700 fps
32.000 Polys: 1400 fps
64.000 Polys: 800 fps
128.000 Polys: 400 fps
256.000 Polys: 250 fps
512.000 Polys: 140 fps
1 Mio. Polys: 70 fps
2 Mio. Polys: 35 fps

Sieht zumindest noch besser aus als ich es erwartet hätte.

Konnte sogar noch bisschen optimieren!
Bei 2 Mio. Polys läuft es jetzt mit ca. 55 fps und bei 4 Mio. Polys immerhin noch mit knapp 30 fps.
Mir ist vorallem aufgefallen, dass das Push und Pop einer Matrix auch eine echt böse Sache ist! Das zieht die Frames echt in den Keller wenn es davon zu viele Calls gibt.
Ohne es erstmal probierz zu haben: Wäre es schneller, wenn ich mir die enthaltenen Werte einfach selber sichere und dann nur noch mit glLoadMatrix() lade?

Ja. => z.B. CoolMathLibrary benutzen.

_________________
Yeah!

Okay
Ich werds dann erstmal selber probieren über Inline-ASM. Da lässt sich bestimmt was rausholen
Die Lib schau ich mir aber trotzdem mal an

Edit// Bringt wirklich sehr viel

Mit ASM-Zeugs kannst du natürlich noch mehr rausholen. Meine CoolMathLibrary ist einfach nur normaler Code, allerdings mit Templates so dass der Compiler etwas optimieren kann. Für mich ist das wichtigste Argument aber das es deutlich handlicher beim rechnen ist, wenn man Matrix und Vektorklassen benutzt. Vorzugsweise mit überladenen Operatoren. Sollte man dann irgendwo an einer bestimmten Stelle mehr Speed benötigen (*) kann man diese dann gezielt optimieren. Insbesondere wenn man Vektor-Erweiterungen einer CPU benutzt (**) lässt sich massiv Speed rausholen.


(*) mit einem Profiler findet man solche Stelle recht leicht.
(**) Beispielsweise 2 oder 4 Zahlen gleichzeitig addieren. So was ist in der Hardware implementiert und geht genauso schnell wie eine einzelne Zahl zu behandeln. Dummerweise funktioniert der Code dann natürlich nur noch auf CPUs die eben diese Erweiterung unterstützen.

_________________
Yeah!