OpenGL Performanceproblem

rapso

hellihjb schrieb:

64000 ist bei displaylisten kein gutes limit. einfach soviel in die DL reinstecken wie man auf einmal kann und dann wird man schon sehen was rauskommt.

grundlegend gilt unter opengl auch das "MaxVertexIndex"-limit von direct3d (kann man im DXCapsViewer nachschauen). um unangenehmen ueberaschungen aus dem weg zu gehen, tut man gut daran 16bit indices (fuer gewoehnlich abzueglich ein paar steuercodes) anzunehmen.

nichts fuer ungut, aber um sowas musst du dich nicht kuemmern.
das sollte der treiber intern machen und das mesh fuer sich optimal aufsplitten. blind vermuten bringt da echt nichts, da du sonst zu allen dingen die du in die displaylists stopfst die groesst moegliche dummheit annehmen muesstest und dann gleich selber alles machen kannst.

btw. @Badestrand
zeichnest du jedes dreieck einzeln zwischen glbeing und glend, oder stopfst du soviele wie moeglich zwischen nur einem glbegin und glend?
setzt du texturen usw. zwischendurch immer wieder?

Badestrand

Gut, dann baue ich den Framecounter mal ein! Ich weiß nur nicht genau wie man das macht (peinlich).. Ich zeichne bei jeder Maus-Verschiebungsaktion mit "glCallList(1)". Soll ich also in einer Schleife ständig "glCallList(1)" (und irgendwelche Matrix- und Identity-Sachen) aufrufen und dabei zählen? Ach, ich probier das morgen einfach einmal, aber danke dafür!

rapso schrieb:

deswegen geh systematisch vor. zeichne mal alles ohne das etwas zu sehen ist. zeichne es mal ohne texturen, zeichne es mal im wireframe, zeichne es mal mit culling fuer front und backfaces (hast du das ueberhaupt schon an? )

Hehe, ich hab weder Texturen, noch wireframe oder culling noch backfaces (glaube ich jedenfalls, keine Ahnung was das ist :D). Also Texturen weiß ich natürlich, was das ist, hab aber keine, die Farbe richtet sich nach der Höhe des Geländes.

Und nen Screenshot mache ich auch gerne, grad hab ich was Wichtiges fertiggekriegt; hab die Dreiecke jetzt so, wie du sie hier (ganz unten) vorgeschlagen hattest, hatte nur ein Zacken-Problemchen mit Hügelketten und Tälern, das hab ich eben gerade rausgekriegt *freu*

Ich lade den Sourcecode (MSVC++ 2003) morgen einfach mal hoch, vielleicht kannst du dann auch mal über die Zeichnen-Methode (glLoadIdentity-, gluPerspective-, glMatrixMode-, usw -Aufrufe) drübergucken? Ist ziemlich chaotisch, ich blicke da nicht wirklich durch..

edit:

rapso schrieb:

zeichnest du jedes dreieck einzeln zwischen glbeing und glend, oder stopfst du soviele wie moeglich zwischen nur einem glbegin und glend?

glNewList( 1, GL_COMPILE );
    glBegin( GL_TRIANGLES );
    // Riesige Schleife
    glEnd();
glEndList();

Ich hatte erst jedes Dreieck zwischen glBegin und glEnd, hatte aber das Gefühl, dass das langsamer war

hellihjb

glNewList( 1, GL_COMPILE );

eigentlich ist das so gedacht, dass du dir die id (bei dir "1") fuer eine displaylist von opengl mit glGenLists geben laesst und dir nicht einfach eine ausdenkst...

das sollte der treiber intern machen [...] blind vermuten bringt da echt nichts

und ich haett's nicht erwaehnt, wenn ich das nicht schon mal erlebt haette.

Cpp_Junky

@Badestrand:
Du sagst, du hast das Ganze in eine GUI eingebettet? Vielleicht ist das der springende Punkt?! Was ist das für ne GUI? MFC Anwendung? Wie wird das Rendering darin gesteuert?

Badestrand

hellihjb schrieb:

glNewList( 1, GL_COMPILE );
eigentlich ist das so gedacht, dass du dir die id (bei dir "1") fuer eine displaylist von opengl mit glGenLists geben laesst und dir nicht einfach eine ausdenkst...

Gut, also glGenList um die Listen-ID zu bekommen und wenn ich die Liste neu füllen will, glNewList?

Cpp_Junky schrieb:

@Badestrand:
Du sagst, du hast das Ganze in eine GUI eingebettet? Vielleicht ist das der springende Punkt?! Was ist das für ne GUI? MFC Anwendung? Wie wird das Rendering darin gesteuert?

Stimmt, ist MFC! Das Modell wird am Anfang erstellt und bei jeder Höhenänderung oder Farbänderung neu berechnet. Neu gerendert wird bei WM_PAINT oder wenn das Modell mit der Maus gedreht oder geschoben wird. Aber hast Recht, ich hab noch gar nicht dran gedacht, dass die GUI auch etwas langsam sein könnte (mit den Nachrichten), obwohl ich's grad zu Testzwecken in einer kleinen schmalen WinAPI-Anwendung laufen lasse - da fällt mir ein, dass in der MFC-Anwendung ja zwei Modelle nebeneinander angezeigt werden

Cpp_Junky

Und ist da ein spürbarer Unterschied zwischen WinAPI und der MFC Anwendung?

hellihjb

Das Modell wird am Anfang erstellt und bei jeder Höhenänderung oder Farbänderung neu berechnet

und wie oft passiert das so durchschnittlich?
wenn du deine geometrie haeufig veraenderst, solltest du doch vbos erwaegen.

Badestrand

hellihjb schrieb:

Das Modell wird am Anfang erstellt und bei jeder Höhenänderung oder Farbänderung neu berechnet

und wie oft passiert das so durchschnittlich?
wenn du deine geometrie haeufig veraenderst, solltest du doch vbos erwaegen.

Das passiert eigentlich recht selten, etwa alle 3 Minuten oder so (oder was ist 'häufig'?)

Cpp_Junky schrieb:

Und ist da ein spürbarer Unterschied zwischen WinAPI und der MFC Anwendung?

Ja, das könnte aber auch daran liegen, dass in der MFC-Anwendung ja zwei der Modelle nebeneinander liegen. Könnte man denn das MFC-Nachrichten-System irgendwie optimieren?

Cpp_Junky

Badestrand schrieb:

... Könnte man denn das MFC-Nachrichten-System irgendwie optimieren?

Kommt drauf an wie du das Rendering auslöst und was das für ein Fenster ist. Wenn dein RC an einem Standard MFC Control hängt, solltest du dessen Paint Nachrichten überschreiben, damit nicht vor jedem Frame auch noch das olle Windows-Fenster neu gezeichnet wird.

hellihjb schrieb:

Das Modell wird am Anfang erstellt und bei jeder Höhenänderung oder Farbänderung neu berechnet

und wie oft passiert das so durchschnittlich?
wenn du deine geometrie haeufig veraenderst, solltest du doch vbos erwaegen.

Sollte man nicht gerade dann besser normale Vertex Buffer nehmen? Die VBOs müssen doch bei jeder Änderung neu übertragen werden oder nicht?

hustbaer

Man sollte immer besser VOBs verwenden, ganz egal ob statischer oder dynamischer Inhalt.

rapso

Cpp_Junky schrieb:

Sollte man nicht gerade dann besser normale Vertex Buffer nehmen? Die VBOs müssen doch bei jeder Änderung neu übertragen werden oder nicht?

sobald du etwas zeichnest, wird es eh zur graka uebertragen. deswegen:

hustbaer schrieb:

Man sollte immer besser VOBs verwenden, ganz egal ob statischer oder dynamischer Inhalt.

wenn man hingegen weniger ahnung hat von ogl, bieten sich displaylisten an, weil darin mehr als nur die vertex optimierungen gemacht werden.

Cpp_Junky

Achso *niemitvbogearbeitethat* Ich hatte VBOs immer so verstanden, das man sie vorab "kompilieren" muss und sie anschliessend unveränderbar im VRAM verbleiben, während normale Vertex-Arrays lediglich aus dem "lokalen" RAM gelesen werden und somit jederzeit angepasst werden können.

rapso

Cpp_Junky schrieb:

Achso *niemitvbogearbeitethat* Ich hatte VBOs immer so verstanden, das man sie vorab "kompilieren" muss und sie anschliessend unveränderbar im VRAM verbleiben, während normale Vertex-Arrays lediglich aus dem "lokalen" RAM gelesen werden und somit jederzeit angepasst werden können.

vielleicht verwechselst du das mit displaylists. die werden compiliert und werden unveraendert im (V)Ram verbleiben.

hustbaer

rapso schrieb:

Cpp_Junky schrieb:

Sollte man nicht gerade dann besser normale Vertex Buffer nehmen? Die VBOs müssen doch bei jeder Änderung neu übertragen werden oder nicht?

sobald du etwas zeichnest, wird es eh zur graka uebertragen. deswegen:

hustbaer schrieb:

Man sollte immer besser VOBs verwenden, ganz egal ob statischer oder dynamischer Inhalt.

wenn man hingegen weniger ahnung hat von ogl, bieten sich displaylisten an, weil darin mehr als nur die vertex optimierungen gemacht werden.

Das ist rüchtüg.
Allerdings kann man IIRC ja auch VBOs mit display lists kombinieren. Oder täusche ich mich da jetzt?

Trotzdem würde ich jedem Anfänger empfehlen gleich mit VBOs anzufangen, da man mit display lists irgendwann ansteht. Bzw. auch weil display lists in OGL 3.0 (hoffentlich) einfach nichtmehr da sein werden.

Badestrand

Ich hab jetzt LOD und VBOs noch nicht implementiert, ich denke, ich habe ein generelles Problem. Mein Bild wird momentan dargestellt durch 59.000 Dreiecke und läuft nur mit 16 FPS. Mag vielleicht mal jemand drübergucken? Ich hab den Sourcecode nun immerhin halbwegs aufgeräumt, sollte jedenfalls lesbar sein.
Was mir noch eingefallen ist: Jeder Punkt jedes Dreiecks hat auch eine eigene Normale, drückt das evtl die Performance?

Der Sourcecode ist jedenfalls hier: *klick*

rapso

laeuft eigentlich recht fluessig, wie kann ich die fps anzeigen lassen damit ich die framerate sehe?

was mir auffaellt ist dass du InvalidateRect aufrufst um das zeichnen aufzurufen, dieser callback kann bei windows ein wenig dauern. versuch stattdessen gleich die renderfunktion aufzurufen.

Badestrand

Danke erstmal für's anschauen!

rapso schrieb:

laeuft eigentlich recht fluessig, wie kann ich die fps anzeigen lassen damit ich die framerate sehe?

Die FPS-Rate sollte eigentlich in der Konsole erscheinen, war erstmal einfacher als Schrift in OGL

rapso schrieb:

was mir auffaellt ist dass du InvalidateRect aufrufst um das zeichnen aufzurufen, dieser callback kann bei windows ein wenig dauern. versuch stattdessen gleich die renderfunktion aufzurufen.

Stimmt, das hatte ich völlig übersehen! Allerdings wird InvalidateRect ja nur beim Verändern der Sicht aufgerufen, das Standbild hat aber trotzdem nur die paar FPS

edit: Hey cool, ohne InvalidateRect läuft das Bild-Verändern wirklich eine Ecke schneller Aber wie gesagt, das Standbild macht mir Sorgen

rapso

Badestrand schrieb:

Danke erstmal für's anschauen!

rapso schrieb:

laeuft eigentlich recht fluessig, wie kann ich die fps anzeigen lassen damit ich die framerate sehe?

Die FPS-Rate sollte eigentlich in der Konsole erscheinen, war erstmal einfacher als Schrift in OGL

kenn ich, deswegen nutze ich immer: SetWindowText
ich werd dann noch mal schauen.

[edit]

glMaterialfv( GL_FRONT_AND_BACK, GL_DIFFUSE, p.col.arr );

kommentier das aus, dann wird es schnell. dieses flag verursacht dem optimizer im treiber kopfschmerzen.
versuch das lieber mit

glColor4ubv...

zu loesen.

geht bei mir ohne diese zeile von 16 auf 88fps.

Badestrand

Juchu, danke dir tausend mal!! Darauf wäre ich nie gekommen! Ist dann jetzt auch schnell genug