Geschwindigkeitsoptimierung beim Zeichnen von Displaylisten

Foxx90

Was ich mache: Ich schreibe grade eine 3D-Simulation in OpenGL. Es geht um kollidierende Bälle die dann sich richtig abstoßen, und noch Gravitationskram...
So, für die komplette Berechnung aller Kugeln, wird relativ wenig Zeit gebraucht.
D.H. ich habe (nur im Rechenmodus, ohne Grafikausgabe) ca 900 fps in einer Dauerschleife (40 Kugeln)... so, sobald ich zeichne, singt die Rate auf 200 fps ab, was immer noch viel ist... Aber es sind im Moment auch nur 40 Kugeln im Einsatz, ich würde das ganze gerne mit vlt 100 bis 200 machen.. Rein rechnerisch auch kein Problem... Nur die Visualisierung ist iwie langsam.
So, vorab erstmal: Ich habe nen eigenen Kugelalgorithmus weil ich mit Shadowvolumen Schatten berechne, deshalb keine gluSphere. So da es ziemlich unklug wäre jedes Mal die ganzen Dreiecke rendern zu lassen und das für jede Kugel, dachte ich mir, zeichne am Anfang das erste Mal alles in eine Displayliste, und zeichne diese einfach an den Stellen, wo sich grad die Kugeln gefinden.

glPushMatrix();
glTranslate(x, y, z);
glCallList(sphere);
glPopMatrix();

So und diesen Ablauf so oft es Kugeln gibt. Ist daran irgendwas auszusetzen ?
Gruß Chris

Code-Walker

Evtl VertexBufferObjekt! Du erstellst dies für jede kugel, und setzt noch ein paar schicke Indices, das reduriert die zeichenzeit um einiges! Zeichne die Kugeln dann eweils mit glDrawElements()

ich kenne mich nicht so gut mit OpenGL aus, bin es nch selbst am lernen, aber ic würd die so machen!

Foxx90 schrieb:

Was ich mache: Ich schreibe grade eine 3D-Simulation in OpenGL. Es geht um kollidierende Bälle die dann sich richtig abstoßen, und noch Gravitationskram...
So, für die komplette Berechnung aller Kugeln, wird relativ wenig Zeit gebraucht.
D.H. ich habe (nur im Rechenmodus, ohne Grafikausgabe) ca 900 fps in einer Dauerschleife (40 Kugeln)... so, sobald ich zeichne, singt die Rate auf 200 fps ab, was immer noch viel ist... Aber es sind im Moment auch nur 40 Kugeln im Einsatz, ich würde das ganze gerne mit vlt 100 bis 200 machen.. Rein rechnerisch auch kein Problem... Nur die Visualisierung ist iwie langsam.
So, vorab erstmal: Ich habe nen eigenen Kugelalgorithmus weil ich mit Shadowvolumen Schatten berechne, deshalb keine gluSphere. So da es ziemlich unklug wäre jedes Mal die ganzen Dreiecke rendern zu lassen und das für jede Kugel, dachte ich mir, zeichne am Anfang das erste Mal alles in eine Displayliste, und zeichne diese einfach an den Stellen, wo sich grad die Kugeln gefinden.

glPushMatrix();
glTranslate(x, y, z);
glCallList(sphere);
glPopMatrix();

So und diesen Ablauf so oft es Kugeln gibt. Ist daran irgendwas auszusetzen ?
Gruß Chris

hättest du was dagegen den quellcode freizugeben?

Foxx90

Ähm, nein im Prinzip nicht, aber was genau wollt ihr sehen ? Alles würde das Forum sprengen xD Den Kugelalgorithmus ? Die Zeichenroutine (Wobei die im Prinzip aus den 4 Befehlen besteht wie oben im ersten Beitrag von mir, nur dann halt in einer Schleife...) ?

Gruß Chris

Powerpaule

Also dein Code ist erstmal gut so
Nun darfst du aber auch von Displaylisten keine Wunder erwarten.

Aus wievielen Vertices bestehen denn deine Kugeln? Und verwendest du Texturen etc...?
Ansonsten sind Shawdowvolumen Schatten auch nicht gerade unaufwendig...
Ab wieviel Kugeln sind denn die FPS so, dass du es fuer zu wenig haelst?

Foxx90

ok, also im Moment ist das ShadowVolume ausgeschaltet aus Testzwecken, Licht ist allerdings an ! Eine Kugel besteht aus 20 Breiten und 20 Längengraden. Dann nochmal mal 2 damit man die Anzahl der Dreicke UNGEÄFHR hat. Also rechnet mal zur Sicherheit mit 800 Dreicke für eine Kugel.
Gruß Chris

PS: Also bei etwa 80 Kugeln kommts ins Ruckeln...

rapso

auf wieviel fps kommst du ohne deine berechnungen, also nur zeichnen.?

Foxx90

Nur um ein paar FPS mehr, stadt 180 vlt 190 ..

Andreas XXL

Ist denn deine kamera so positioniert, das immer alle Kugels zu sehen sind?
Wenn nicht könnte Frustum Culling helfen.

Foxx90

Hmm, ja die Kugeln sind immer vollständig zu sehen, ich habe eine dynamische Kameraklasse geschrieben, damit man sich immer alles aus jeder Position ansehen kann... Naja, vlt ist es einfach normal.

Gruß Chris

Foxx90 schrieb:

Ähm, nein im Prinzip nicht, aber was genau wollt ihr sehen ? Alles würde das Forum sprengen xD Den Kugelalgorithmus ? Die Zeichenroutine (Wobei die im Prinzip aus den 4 Befehlen besteht wie oben im ersten Beitrag von mir, nur dann halt in einer Schleife...) ?

Gruß Chris

nein nein, allgemeines interesse am projekt. also.. ich will alles

hellihjb

Wie erzeugst Du denn die Shadow-Volumes?
Per GPU oder CPU-seitig?
Wenn ersteres: Unternimmst Du irgendwas fuer Vertex-Cache-Effizienz?
Wenn zweiteres: Wie uebertraegst Du die resultierenden Polygone zur Grafikkarte?

Foxx90

1.Ok, nicht so schnell. Also ich denke doch mal, dass ich die Schatten auf der CPU berechne, da ich ganz normale Rechnungen durchführe, die wiederrum ansich ncihts mit der GPU direkt zutun haben. Sollte ich das iwie ändern ?

2.Die Polygon übertrage ich mit GL_TRIANGLE (Wenn es das wars was du jetzt meintest...) Und dann halt für jeden Vertex die Normale ...

@TravisG: Du willst wohl den kompletten Source was ? xD^^

Gruß Chris

PS: Was meinst du mit Vertex Cache ?

hellihjb

da ich ganz normale Rechnungen durchführe die wiederrum ansich ncihts mit der GPU direkt zutun haben

Deine Berechnungen fuehren dazu, dass Polygone zur Grafikkarte geschickt werden.
Viel direkter kann ich mir kaum vorstellen.

Sollte ich das iwie ändern ?

Kommt auf die Gegebenheiten an.
Wenn Deine Geometrie statisch ist und Deine Anwendung den Vertexprozessor nicht auslastet, kann das sinnvoll sein. Der Vorteil waere weniger CPU-Auslastung und weniger Bus-Traffic.
In Deinem Fall aber eigentlich irrelevant.

Die Polygon übertrage ich mit GL_TRIANGLE

dh jeden Eckpunkt "manuell" per glVertex?
An der Stelle koenntest Du mit Vertexbuffern sicher etwas effizienter sein.
Fuer die Kugeln selbst (statische Geometrie) bist Du mit der Display-Liste und Backface-Culling sehr nah an "optimal".

Und dann halt für jeden Vertex die Normale...

Warum braucht Dein Volumen Normalen?

Was meinst du mit Vertex Cache ?

Vertex Cache

Foxx90

@hellihjb : Für Schattenberechnung, und damit OpenGL die Kugeln anständigleuchtet.
Würde ich nicht für jedes Vertex die Normale nehmen, die wiederum "Durchschnittwerte" von den umliegenden Flächen sich. Dann würde die Kugel extrem eckigaussehen. So, und ide meinte mit Berechnungen, die Kollision etc, UND die Berechnenung der Schattenvoulumen (Beleuchtete oberflächen extrahieren, Silhoutte berechnen, dann StencilVolume zeichnen...)

Gruß Chris

hellihjb

Warum braucht Dein Volumen Normalen?

damit OpenGL die Kugeln anständigleuchtet

Damit meinte ich:
Da sich die Vertexdaten fuer die Shadow-Volumes permanent veraendern, sollte man die Anzahl zusaetzlicher Vertexattribute gering halten weil sich damit auch der Bus-Traffic erhoeht.
Dass Deine "regulaere" Geometrie Beleuchtung nutzt hatte ich bereits vermutet

Beleuchtete oberflächen extrahieren, Silhoutte berechnen

Fuer die Silhouette pruefst Du ja vermutlich fuer jedes benachbarte Polygonpaar ob inverse Lichtorientierungen vorliegen (Vektoren rein, Skalarprodukt, Vorzeichentest: sinnvolle Anwendung fuer einen Vertexprozessor).
Ich will Dir jetzt aber nicht erzaehlen, dass Du *unbedingt* Vertex-Shader einsetzen musst, sondern dass wahrscheinlich da der Punkt ist, wo Du optimieren koenntest.
Solang Du aber nur 40 Kugeln darstellen willst und dabei konstante 200fps hast, wuerd' ich da noch keinen Gedanken dran verschwenden.

rapso

hellihjb schrieb:

Solang Du aber nur 40 Kugeln darstellen willst und dabei konstante 200fps hast, wuerd' ich da noch keinen Gedanken dran verschwenden.

Foxx90 schrieb:

Aber es sind im Moment auch nur 40 Kugeln im Einsatz, ich würde das ganze gerne mit vlt 100 bis 200 machen.

hellihjb

Ja, Asche auf mein Haupt: Es waere sinnvoll gewesen, die Fragestellung zu lesen

Foxx90

Ok, also ich habe jetzt den Fehler gefunden, danke für eure Beträge... Es war ein Fehler im Code. Genauergesagt wurde jedesmal beim malen, die Berechnungen für Kantennachbarn der Kugeln vorgenommen, und diese Berechnungen gehören ansich in die OnInitOpenGL Funktion... (JOGL) (Was ja normalerweise nur einmal am Anfang geschehen sollte). Irgendwie ist das wohl da rein geruscht... Jetzt ist es fix, die Visualisierung stellt nun nicht mehr das Nadelöhr da...

Guß Chris

rapso

naechstesmal einen profiler laufen lassen, dann weiss man meist sofort woran es liegt.