Ich mache mir die vergangenen Tage vermehrt Gedanken darüber wie OpenGL eigentlich funktioniert.

Speziell geht es mir darum, wie und wann die Matrizen und andere Uniforms in den Shader gelangen. Bislang arbeite ich nur mit Displaylisten also auch mit Shadern < 1.5 .
Ich kann mir nur einen Moment vorstellen in dem die Matrizen übertragen werden: glBegin. Liege ich da richtig? Das würde zumindest den starken Performanceverlust erklären, den man hat wenn man viele glBegin/glEnds falsch in einer Schleife durchläuft.

Ziel des Ganzen ist es, den ganzen deprecated Mist über Bord zu werfen. Wäre auch dankbar für ein paar Tipps wie man sowas am Besten umsetzt... eine erste Überlegung war "einfach" die glTranslate, glBegin, glVertex, glEnd, .... Geschichten nachbauen mit eigenen Matrizen und VBOs und alle überflüssigen Uniforms wie Licht und Material weglassen bzw. durch eigenes ersetzen.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Vergleiche einfach mal die alte Renderingpipeline:

http://wiki.delphigl.com/images/archive/b/b4/20120810094228!Pipeline.png

mit der neuen:

http://wiki.delphigl.com/images/b/b4/Pipeline.png

Die neue sieht wesentlich aufgeräumter aus als die neue, oder? Das liegt daran, dass alle früher "fest verkabelten" Funktionen rausgeschmissen wurden (also z.B. Immediate-Mode, etc.). Die wurden eh schon seit geraumer Zeit nur von der Grafikkarte emuliert, z.B. das Lighting wird einfach von der Grafikkarte als Shader ausgeführt, während es früher fest verkabelt/implementiert(?) war.

_________________
offizieller DGL Compliance Beauftragter
Never run a changing system! (oder so)

Bin auch noch am umstellen, behalte aber aus Faulheit viele alte Sachen bei.

Hier ein guter Artikel darüber, wie man die Matrizen, die ab späterer Versionen nicht mehr im Shader sind, wieder in den Shader bekommt :
http://www.swiftless.com/tutorials/open ... rices.html

Dann kann man natürlich alle Displaylisten durch VBOs ersetzen, wo man dann für jedes Attribut alles selbst alloziern muss.
Dann werden alle glBegin/glEnd durch glDrawElements, glDrawArrays etc ersetzt.

glScale(x,y,z) -> vertex.x*=x; vertex.y*=y; vertex.z*=z;
glTranslatef(x,y,z) -> vertex += vec3(x,y,z);
glRotate weiss ich grad nicht, bitte ergänzen.

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Danke erstmal für die Antworten.

Ich denke das Beste wird sein, erstmal die Matrix-Funktionen nachzubauen: glTranslate, glPushMatrix, etc.....
Dann kann ich das bisherige Verhalten nachbilden und muss nur den ShaderManager davon überzeugen die Matrizen per Uniform zu übergeben und der Mesh-Klasse das Binden der VBOs beibringen.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next

Hi,
Also der Vertexshader wird für jeden Vertex, auf den Du ihn anwendest neu ausgeführt,
d.h der Shader kann sich nichts merken, Du kannst also im Shader nicht irgendwelche Matrizen auf den Stapel legen und Sie später für einen anderen Vertex hernehmen, der Shader muss für jeden Vertex alle benötigten Matrizen parat haben, und diese Matrizen müssen mit den Vertices in der korrekten Reihenfolge multipliziert werden, so viel zu Push- und PopMatrix.
Und wie gesagt, für glTranslate, glScale brauchst Du keine Matrix.
Für eine Translation des Vektors V um 1 auf der x Achse beispielsweise schreibt man in glsl einfach
V.x+=1;

_________________
"Pixel, ich bin dein Vater."
-Darf Shader

Ich glaube ich habe mich falsch ausgedrückt. Es geht mir nicht um die Shader.
Mir geht es darum, meiner Engine die richtige Struktur zu verpassen.

Momentan sieht es so aus, dass einfach je nach Bedarf ein Shader gebunden wird, hier und dort werden DisplayListen aufgerufen und mit glTranslate (etc) transformiert.
Natürlich könnte ich einen Context mit Compatiblity erstellen und beim binden eines Shaders mittels glGet die Matrizen auslesen, aber das scheint mir alles nicht zielführend.
Wahrscheinlich läuft es doch wieder auf das Implementieren eines SceneGraph hinaus.

_________________
Es werde Licht.
glEnable(GL_LIGHTING);
Und es ward Licht.

Zitat aus einem Java Buch: "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do it blows your whole leg off"

on error goto next