4. OpenGL Performanceproblem

OpenGL Performanceproblem

  • B

    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 😕

    0
  • C

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

    0
  • H

    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.

    0
  • B

    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?

    0
  • C

    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? 😕

    0

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

    0
  • R
    Mod

    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.

    0
  • C

    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.

    0
  • R
    Mod

    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.

    0

  • 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.

    0
  • B

    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*

    0
  • R
    Mod

    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.

    0
  • B

    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 😞

    0
  • R
    Mod

    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.

    0
  • B

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

    0
Anmelden zum Antworten