Hallo Leute!
Ich habe eine Klasse zur Benutzung von Vertex Buffer Objects (VBOs) erstellt. Mein Problem: Wenn ich VBOs benutze, um Arrays aus Vertices zu rendern, ist das bedeutend langsamer als die Benutzung von Displaylisten. Vielleicht könnte ja jemand einmal den Code überfliegen und mir sagen, wo die Geschwindigkeitseinbuße liegt. Das wäre echt nett :) Ich denke, dass das Problem wahrscheinlich in den Prozeduren "FillBuffer" oder "Render" liegt. Codebasis für die Codes bzgl. des VBO ist das VBO-Tutorial hier im Wiki.



Einmalig wird das Objekt instantiiert und mit "FillBuffer" dann mit Daten gefüllt. Danach wird einfach nur noch mit "Render" gerendert.

Wenn "FillBuffer" direkt Vertices verlangt, anstatt Dreiecke wie jetzt, ist es auch nicht schneller. Irgendwo muss ein Konzeptfehler von mir sein.
Falls jemand was für sein Projekt nützliches finden sollte, kann er es behalten :)

Danke!

Da deine Daten aus einem zusammenhängendem Buffer kommen, würde ich glBufferData zur Übergabe benutzen, anstatt der for-Schleife. Und da du deine Daten anscheinend im nachinein nicht änderst, dann das ganze als GL_STATIC_DRAW_ARB ablegen.
Das Füllen alleine dürfte nicht die Performance beeinflussen, da es ja Initialisierungsarbeit ist, esseidenn du tust mittem im Rendern immer mal neue VBOs anlegen. Dann macht es natürlich was aus.



Ich würde das BindBUffer direkt reinschreiben, oder zumindest inline machen.

Insgesamt würde ja VBO vs DL heir shcon ab udn an diskuttiert. Und bei statischer Geometrie geht wohl nichts wirklich schneller als die Listen in OGL.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Ach ja und man sollte glDrawRangeElements nutzen, da ist die Chance höhe das die GraKa optimieren kann.

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Ja, danke für die Antwort! Ich benutze jetzt als Alternative auch ein Objekt für Displaylisten. Bei den VBO's:



Obigen Befehl benutze ich ja, um Speicher zu reservieren. Und schreib dann später die Vertices mit der for-Schleife dort hinein.

Sollte ich jetzt folgenden Code anstatt der for-Schleife benutzen? Gelangen die Daten dann immer noch in den VRAM?



Hilft das bei der Geschwindigkeit? Achja, und was heißt eigentlich inline? :)

Du schreibst nach dem Binden des Buffers nur



Dadurch werden die Daten automatisch in dein VBO kopiert. Das Mappen ist dann nicht mehr notwendig, das brauchst du nur, wenn du "per Hand" im VBO rummehren willst.

inline bedeutet, dass an die Stelle des Funktionaufrufes direkt vom Compiler der Quellcode der Funktion eingesetzt wird. Also sowas wie die Makros in Assembler.
Dadurch sparst du dann an dieser Stellen den Function Overhead. Normalerweise bedeutet inline, dass der Code größer wird. Da deine Methode aber nur 1 Zeile enthält, nämlich widerrum nen Funktionsaufruf, kannst du nur gewinnen wenn du inline machst^^

_________________
__________
"C++ is the best language for garbage collection principally because it creates less garbage." Bjarne Stroustrup

Eine Funktion hat normalerweise etwas Overhead weil es einen SRJ (SubRoutineJump) benötigt. Dazu müssen noch die Variablen kopiert werden und ähnliches.
Wenn hinter der Funktion aber inline steht wird diese bei einem Aufruf nicht aufgerufen sondern einfach an die entsprechende Stelle des Codes kopiert, was Geschwindigkeit bringt (aber dafür grösseren Code, nur der ist eh egal).
Ist mit Delphi in den neueren Versionen möglich.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

Also ich weiß nicht ob Borland das wieder eingebaut hat aber die Hilfe von dem Delphi 7 sagt hier folgendes.

Was aber nicht ganz stimmt, denn sobald ich inline benutze bekomme ich einen Kompilerfehler.

Aber im Endeffekt ist es auch ziemlich egal. Funktionsoverhead ja. Das Stimmt. Aber wenn diese Funktion 2-200 mal pro Sekunde aufgerufen wird dann macht das überhaupt nichts aus. Spannend wird es wenn an der 200 noch 2-4 Nullen anhängen. Aber sonst gibt es ganz andere Stellen auf die man achten sollte.

DisplayListen: Innerhalb einer DisplayListe werden normal auch nur VBOs benutzt. Von daher sollte das Ergebniss bei idealen Bedingungen eigentlich gleich sein. Dass der Treiber es mit DisplayListen zwar trotzdem irgendwie immer noch besser hinbekommt irritiert mich persönlich auch ein bisschen. Ich vermute da einfach mal, dass es spezielle Konstrukte gibt bei denen die Grafikkarten intern besonders gut optimieren können und dadurch massiv an zeit einsparen können. Wie Pallaeon sagte. glDrawRangeElements. Dieses benötigt aber einen zusätzlichen Speicherbereich.

Ich muss aber gestehen, dass meine letzte Benutzung von VBOs mittlerweile auch schon locker 2 Jahre zurück liegt. In der Zwischezeit hat sich bei den Karten ein bisschen was getan.

Ja, das sagt mir die Delphi Hilfe auch - bei Delphi 5 Prof.
Wenn ich "inline" als Direktive hinter die Funktion setze(in der Implemation und in "Definition" in Klassenobjekt) gibt er mir einen Kompilierungsfehler zurück. Mit Lazarus kompiliert er aber den Code.

Ok, ich denke, ich werde es einfach mal mit glDrawRangeElements beim Render probieren und das Binden des Puffers direkt reinschreiben.

Das reservierte wort inline und die inline direktive sind etwas verschiedenes. Früher konnte man asm-code mit inline einbinden. Die inline direktive teilt delphi mit, dass die funktion inline einzubinden ist, was jedoch nur unter bestimmten Voraussetzungen und in neuen Delphis (7 ist afaik zu alt) funktioniert.

_________________