Grundsätzlich gefällt mir die Struktur von OpenGL 3 sehr viel besser als die von 1 und 2. glBegin und die Statemachine bin ich gerne los. Die haben imo keinen vorteil gegenüber VBO(notfalls in Software, was immernoch nicht langsamer als glBegin sein dürfte) und Objekten. Die fehlende Unterstützung für alte Karten ist jedoch imo problematisch. Am liebsten wäre es mir wenn man für alte Karten pseudoshader erzeugen kann, wobei der "Fragmentshader" eine Beschreibung der Einstellungen für Multitexturing&co ist, und der "Vertexshader" eine Beschreibung für T&L.
Die anderen Änderungen müssten so weit ich das sehe ja unabhängig von der Grafikkarte sein.

_________________

Mit OpenGL 3.0 war auch geplant, die fixe Pipeline zu entlasten, indem GLSL basierte Vertex-,Fragment- und Geometrieshader die Pipeline teilweise ersetzen.
Bisher war es ja so, das man durch die Statemachine massive viele standardcodefetzen mitgelierfert wurden und die dann zu einer Pipeline zusammengesteckt wurde. Nun war die rede, das man dann Teile der Pipeline durch GLSL ersetz und damit den Treiber wieder stark verkleinert und vereinfacht.
Also States in den GLSL code verlagert und somit keine States mehr sind, sondern vom Programmierer entwickelte Codefetzen.
Nachteil wäre, man muss nun in GLSL bewandert sein und man kann GLSL nicht mehr einfach so den Artist in die Hand drücken, da er nun viel zu viel Macht bekommen würde. Lösungen wie bei Unreal3 mit dem zusammenklicken von materials und die automatische generierung von shadercode daraus wären sehr praktisch.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

ich persönlich finde es eher schade, dass das jetzt alles komplizierter wird... gegen vertexarrays habe ich zwar gar nichts, aber warum soll man, um ein quadrat zu beleuchten, 100 zeilen shader schreiben, wenn es doch jetzt auch ohne geht?

zumal ich schon zu doof bin, shader in einem programm zu verwenden (ja, das kompilieren funktioniert immerhin). da helfen auch die beiden tutorials hier überhaupt nicht.

und wozu soll ich mir eine klasse zusammen bauen, um ein quadrat rendern zu können!?

nein, ich bin tatsächlich nicht sonderlich erfahren, aber warum muss alles komplizierter werden!?

btw: es wurde gesagt, dass sich OGL3.0 an fortgeschrittene richtet. meiner meinung nach ein völlig falscher ansatz, denn dann gibt es irgendwann keinen "nachwuchs" mehr - und keiner will mehr opengl. armes linux.

tz tz tz

Du hättest dir den Thread evtl. ein wenig genauer durchlesen sollen, OpenGL 2.x wird ja paralell weiter existieren. Und da heute alle Neuerungen im Shaderbereich liegen (siehe z.B. Geometryshader) kann man die feste Pipeline (die es ja als solche schon lange nicht mehr in dedizierter Hardware gibt) rauswerfen und eine eine shaderzentrische API (GL 3.0) erschaffen.

Wer dann wie du weiterhin Sachen aus der festen Pipeline nutzt bleibt bei GL2.x

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Hallo Ireyon,
so schlimm wird es nicht werden. Eine "sanfte Einführung" für Anfänger wird es immer geben, genauso wie es Leute geben wird, die sich genau darum kümmern.

Und was Linux betrifft: Linux kann von einem starken konkurrenzfähigen OpenGL nur profitieren. Im Gegenteil, es wäre sogar schlecht für Linux, wenn OpenGL in der Entwicklung zurückbleibt. Genau das ist was Linux eigentlich noch fehlt: eine moderne schnelle schlanke Grafik-Library, nicht ein Ding von Vorvorgestern.

Ermutigende Grüße
Traude

Auserdem sollte es ja kein problem sein bei den Einteiger Turtorials erstmal die Shader mitzuliefern und später in Turtorials für Fortgeschrittene zu erklären was der Code wirklich bringt, oder?

Hallo,

falls OpenGL 3.0 wirklich nur noch mit Shadern arbeitet, wäre es ganz hilfreich, wenn man ein Programm hätte, was aus einer Folge von alten OpenGL-Befehlen gleich den passenden Shader-Code generiert.

Viele Grüße
dj3hut1

Macht euch mal nicht soviele sorgen um die Einführung in OpenGL3.0.
Wichtiger ist eigentlich nur, dass soviel wie möglich implementiert wird und nicht wieder die hälfte an Features auf der Strecke bleibt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

@Sascha Willems

ich habe mir den thread schon durchgelesen.

aber wenn OGL3 dann mal irgendwann eingeführt wird und irgendwann auch jeder rechner das unterstützt (mir faellt ein, meiner kann nur 2.0, nichmal 2.1), würde ich schon gerne auch damit umgehen können.

zum thema "schlanke API": je 'schlanker' die api ist, desto mehr muss man in aller regel selber dazuimplementieren. und was an glBegin() so schlimm sein soll, begreif ich nich. ich komm damit eigentlicgh gut klar.

Du kommst damit klar, aber der Treiber nicht. Vorhin war mal ein schönes Zahlenbeispiel, dass bei MesaGL der Code für glBegin und glEnd alleine 30% des ganzen Treibers ausmacht.

wo ist problem dabei?

besser ordentlich glbegin als 100 zeilen shader für ein dreieck.

Nun, das glBegin und die Shader haben ja nix miteinander zu tun.

Das Problem bei glBegin/glEnd ist so wie ich das bisher verstanden habe, dass im Treiber aus den Befehlen eine Art Funktionsscope wie auch ein begin und end in Pascal es bewirkt, erzeugt werden muss. Dazu kommen die ganzen Fehlerabfragen, weil ja einige Befehle zwischen glBegin und glEnd nicht erlaubt sind. All das kostet Zeit und Code. Dazu müssen die Vertices zwischen glBegin und glEnd erstmal gecacht werden, weil man ja schlecht die einzeln zur Graka schicken kann ohne der zu sagen, was sie eigentlich damit anstellen soll (also bei GL_TRIANGLES immer alle drei Vertices abschicken).

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Das ist wohl "leicht" übertrieben. Du wirst nur zum Rendern eines einfachen Dreieckes u.U. weit weniger Zeilen brauchen als bisher mit glBegin...glEnd. Wie ich hier schonmal geschrieben hat kann man für solche einfachen Sachen ja eine Konstante deklarieren die deine Vertices enthält, und diese übergibts du dann direkt an ein VBO, VA, etc. (je nachdem wie GL3.0 aussieht ist dass dann nur eine Zeile). Es wird dich keiner zwingen Shader zu verwenden, aber wenn du Beleuchtung usw. willst kommst du ja selbst heute nicht um Shader herum, die per-Vertex-Beleuchtung von OpenGL ist ein Relikt aus der Steinzeit und wird zuercht entfernt. Sich seine eigene Beleuchtung im Shader zu schreiben ist da viel besser und flexibler. Wer sich ein wenig mit 3D-Grafik auskennt hat die Shadersyntax schnell drauf und kann innerhalb kürzester Zeit eigene Beleuchtungsmodelle implementieren.

P.S. : Selbst für ein komplexes Beleuchtungssystem wird man sicherlich keinen 100-Zeilen Shader brauchen. Ausserdem gibts u.a. von 3DLabs ein Tool (ShaderGen wenn ich recht entsinne) dass dir aus Einstellungen für die feste Funktionspipeline passende Shader erstellt. Die sind zwar nicht optimiert, aber perfekt um in die Materie einzusteigen.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

ShaderGen scheint nicht mehr zur Verfügung zu stehen: http://developer.3dlabs.com/downloads/shadergen/index.htm

@Traude: Kann es sein, dass der ShaderGen, den du meinst, jetzt hier ist: http://3dshaders.com/home/index.php?option=com_weblinks&catid=14&Itemid=34

_________________
Aktuelles Projekt: Gael - Development Blog
Website: LightBlackSoft.com