Geschwindigkeitsoptimierung beim Zeichnen von Displaylisten

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.