Ich habe mal in die "OpenGL Programming Guide Ninth Edition" reingeguckt und das erste Beispiel ausprobiert. Und habe es mit Erfolg mit Lazarus zum laufen gebracht.
Da ist mir schon aufgefallen, das die Buffer für die Vektoren mit anderen Kommandos ins VRAM geladen werden, als mit OpenGL3.3
Beim zweiten Beispiel, noch nicht probiert, geht es um Uniforms. Und dies wird schon mit UBOs gemacht, Gut hat man schon Vorkenntnisse mit OpenGL3.3.
So wie es aussieht, ist der Einstieg recht Hürdenhaft, aber mit Vorkentniss mit OpenGL3.3, sollte dies gut zu meistern sein.
Wie ihr schon sagtet, ist nachher auf Vulkan umzusteigen dann auch einfacher.
Noch eine Frage. Dazumal wurde mir OpenGL3.3 empfohlen, das dies ein Generationswechsel ist. Man trennte sich von glbegin und co. Ist dies bei OpenGL 4.5 etwas der gleiche Fall.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Wenn ich mich noch recht entsinne, dann ist bei 4.5 die alte API nicht aufrufbar. Man erzeugt mit der alten API ein alten Context und mit dem lädt man die neue API und erzeugt, dann ein neuen Context und wirft den alten weg. Mit 5 sollte das noch geändert werden, da es aber an den Windows/X11/Wayland API Teil hängt, gab es da keine Anstrengung mehr eine allgemeine Context erzeugung für alle Systeme zu etablieren. Mit Wayland kann man meines Wissens straight auf 4.5 gehen. Bei Vulkan gibt es meines Wissens nur den einen API definierten Weg, ein Context zu erstellen und damit ist auch der Teil Platformunabhängig. 4.5 hatte den Fokus auf die aufhebung der starren Pipeline und vollständigen Objekt basierten ressourcen. In 3.3 kann man einige Objects nur über Extensions/ARB nutzen. Ich hatte als letztes 4.5 genutzt und mir mal Vulkan angeguckt, dass war recht übersichtlich, was da noch neues hinzu kommt. Wenn man sich mit den Memory Extension von NV und AMD beschäftigt hat, dann ist sogar Mutex, Memory management kein neues Thema mehr. Der schlimmste Schritt ist meiner Meinung nach UBO und die damit verbundenen Shader Änderungen. Wenn man dann seine Datenstruktur dem Shader erklären muss, die richtigen Datentypen, alignments und bit-order mit einmal um die Ohren geworfen bekommt. Sobald das solide sitzt ist der rest recht übersichtlich.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Der schlimmste Schritt ist meiner Meinung nach UBO und die damit verbundenen Shader Änderungen. Wenn man dann seine Datenstruktur dem Shader erklären muss, die richtigen Datentypen, alignments und bit-order mit einmal um die Ohren geworfen bekommt. Sobald das solide sitzt ist der rest recht übersichtlich.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
Nein UBO haben sich seit 3.1 https://registry.khronos.org/OpenGL-Refpages/gl4/html/glUniformBlockBinding.xhtml nicht verändert. Allerdings das Drum herrum. Shader und dann gab es noch Indirect Buffer, womit man die Statechanges los wurde. Also hast du noch ein Draw command und die ganze binding/state changes passieren GPU seitig. Das ist die Ultimative Performance und teilweise auch einfacher vom Code her. Data-Driven vom feinsten
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2622 Wohnort: Berlin
Programmiersprache: Go, C/C++
https://www.khronos.org/opengl/wiki/History_of_OpenGL#OpenGL_4.6_(2017) Also Multidraw-Indirect rendering hatte ich noch verwendet, als Extension aber die anderen Änderungen sind auch super nice Das man Fehler abschalten kann, finde ich sehr spannend, da muss ich mal nach den Performance unterschieden googeln. *Hyped*
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Ich hatte gerade nochmal geguckt, weil mir der Name Indirect Buffer nicht mehr eingefallen ist und es scheint eine OpenGL4.6 Version zu geben. https://www.khronos.org/files/opengl46- ... e-card.pdf Davon hab ich garnix mit bekommen ^^
Dies war mir schon länger bekannt. Ich habe nur auf die 4.5 reagiert, weil es dazu montan mehr Dokus gibt. Recht komplexes PDF.
Kann ich die Funktionen auf meinem Link alle ohne Probleme verwenden, ohne das ich etwas veraltetes erwische ? Ich vermute ja, weil mal zB. ein veraltetes "glbegin" nicht mehr findet.
OpenGL 4+ bietet auch bei der Shader-Einrichtung Vorteile. Der Code dafür ist echt kompakt geworden, gegenüber älteren Versionen. Die Fehlerabfrage für Syntaxfehler in den Sourcen kann man sich auch sparen, da die Fehler beim OpenGl-Debug ausgeben werden.
Code:
function Initshader(VertexS, FragmentS:string): TGLuint;
Mitglieder in diesem Forum: 0 Mitglieder und 13 Gäste
Du darfst keine neuen Themen in diesem Forum erstellen. Du darfst keine Antworten zu Themen in diesem Forum erstellen. Du darfst deine Beiträge in diesem Forum nicht ändern. Du darfst deine Beiträge in diesem Forum nicht löschen. Du darfst keine Dateianhänge in diesem Forum erstellen.