Ich werf hier mal eine Frage in den Raum.
OpenGL 3.0 steht ja im Raum und wir sollten dafür auch eine Einführung anbieten. Es sollte diskutiert werden, wem man empfeheln soll OGL3.0 zu verwenden. Blutigen Anfängern? Oder Leuten die bereits mit OGL1-2 gearbeitet haben, also Umsteigern.
Macht es überhaupt sinn mit 3.0 anzufangen ohne den Background zu verstehen?

Wenn das geklärt ist sollte ein Schreiber gefunden werden. Jemand der das Thema möglichst vereinfacht und so einen Einstieg schafft mit schnellen Fortschritten.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Ich denke das Thema OpenGL 3.0 wurde durch Khronos "etwas" entkräftet. Es war ja ursprünglich geplannt, dass mit OpenGL 3.0 ein ganz neuer Kontext auf dem Plan steht der alles verändert und nicht mehr Abwärtskompatibel ist . Also kein Imediate Modus mehr und nur noch Objekte. Fakt ist aber, dass in OpenGL 3.0 lediglich die "Geforce8 Extensions" in den Kern gewandert sind. Vergleichbar mit der Veränderung von 2.0 auf 2.1 (ja das gibts). Nur ein bisschen komplexer (das muss man denen ja zugestehen. Sind mehr als 6 Methoden).

Es gibt eine WGL Erweiterung (WGL_ARB_create_context) mit der man einen Kontext, anhand einer Attributsliste erstellen kann. Unter anderem auch die OpenGL Version die er dann unterstützen muss. Aber so wie ich es verstanden habe ändert das nichts am Funktionsumfang des Kontextes. Sondern das ist lediglich da um einen OpenGL 2.1 Kontex gezielt erstellen zu können. Was aber eigentlich ziemlich behämmert ist, da diese Erweiterung nur verfügbar ist, wenn man einen OpenGL Kontext bereits erstellt hat und dann kann man eigentlich auch die OpenGL Version erfragen. Man braucht also ähnlich wie beim Multisampling ein temporäres Fenster auf dem man einen Kontext erstellen um ihn dann sofort wieder wegzuschmeißen.

Außerdem wurde noch eine Erweiterung namens EXT_direct_state_access veröffentlich. Die vereinfacht das Handling von OpenGL ein wenig. Also die führt ein bisschen das ein was in OpenGL 3.0 eigentlich geplannt war. Mit dieser Erweiterung muss man zum Verändern einer Matrix oder einer Textur nicht erst diese aktivieren sondern übergibt bei LoadIdentity dann den MatrixMode als einen Parameter. Oder die TexturID als Parameter. Aber diese Erweiterung ist erst einmal eine EXT Variante und sie ist ziemlich groß. Also würde ich nicht damit rechnen, dass das bald Flächendeckend umgesetzt wird.

Mit anderen Worten aus meiner Sicht ändert sich nichts.

Ich habe mich nicht ganz so eingehend damit beschäftigt, aber war es nicht so, dass es zwei 3.0 Kontexte gibt? Einen Backward-Kompatiblen und einen der alles, was deprecated ist rauswirft? Oder war das erst mit 3.1 zu erwarten?

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

Ich kann dich beruhigen. Ich verstehe die Dokumentation an vielen Stellen auch nicht. Habe es halt nur so gesehen weil ich in den letzten Tagen mehr mit dem Header zu tun hatte.

Habe aber noch mal geschaut. Und ja stimmt. Auch wenn das in der Dokumentation mehr als nur schwammig formuliert ist. Sollte man mit der Erweiterung WGL_ARB_create_context einen Kontext erstellen, der mindestens 3.0 als Version enthält, dann können Funktionen/Parameter (die zusammengefasst und ziemlich wirr in der Doku enthalten sind) deprecated (veraltet) sein. Die Funktionen existieren mitunter weiterhin und sollten auch normal geladen werden. Nur wenn man sie aufruft und sie veraltet sind liefern sie einen OpenGL Fehler. Allerdings ist diese Übersicht ziemlich wirr und ich traue mir nicht zu sagen was dann deprecated ist und was nicht. Allerdings so ganz neue Kostrukte wie anfangs geplannt mit den Stateobjekten etc. sind nicht neu dazu gekommen. Man darf dann wohl nur das ein oder andere nicht mehr benutzen.

In der Spezification der Erweiterung habe ich auch noch was gesehen was in meinem oberen Post falsch war.

Scheinbar ist es so, dass man OpenGL 3.0 auch nur noch mit dieser Windows Erweiterung bekommt. Der (selbst über die Erweiterung erstellte) klassische Kontext soll dann wohl nicht in der Lage sein 3.0 zu können.

Verstehe ich das also richtig, dass man erst einen 2.x-Kontext erstellen muss, in dem man Abfragt, ob diese neuen Routinen und damit ein 3.0-er Kontext verfügbar ist?!

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

Stammte der Multisamplingcode nicht aus deiner Feder? Da ist es doch aus so, dass man zu erst einen Kontext erstellen muss um die Funktion wglChoosePixelFormat aufrufen zu können. Anschließend hat man ein Pixelformat in welchem Multisampling aktiviert war.

Nur jetzt ist es so, dass man kein Format mehr auswählt sondern den Kontext damit erstellen lässt. Die andere Alternative wäre die, dass Microsoft die OpenGL32.dll anpasst um diese Methode direkt zu unterstützen. Aber ich denke die Chancen dafür stehen vermutlich nicht ganz so gut. Außer vielleicht in Windows 7.

Im Prinzip ist die sache mit dem Kontext so weit entschärft, das man auch einen aufwärskompatiblen 1.x kontext verwenden kann. Die funktionionalität ist die gleiche nur das keine fehler geworfen werden wenn man veraltete funktionen benutzt...

Von daher kann man erst einmal abwarten. Besser einfach den Anhang in der Spezifikation als don't do liste betrachten.

_________________
Lumina plattform unabhängige GLSL IDE

@Flash: wäre es vorher nicht empfehlenswert, die gl-Funktionen im Wiki um die Spalte "eliminiert in der Version" zu erweitern? Eine Liste, was rausfliegt, gibt es ja schon.

Es gibt aktuell 3 Kontexte, den alten 2.x, ein 3.x mit Immidate und ein 3.x ohne.
Weil die Cad Fraktion so auf die Drähnendrüse gedrückt haben.
Aktuell würde ich sagen, ist OpenGL nur für Fortgeschrittene Interessant, weil dort halt ein paar Extensions in den Core gewandert sind und man nun FBO, Texturearrays und passende 4.0 Shader hat. Das ist aber alles eher Handwerkszeug für deferred shading, pssm, HDR und co, also nichts für den einsteiger.
Objektbasiertes programmieren ist zwar in der Regel einfacher zu verstehen aber jemanden zum Anfang mit VBO vertraut zu machen ist wohl ein bischen Hart.
Man muss soviel machen, bevor man was hat und es ist wesentlich empfindlicher gegenüber glBegin/glEnd.
glClearColor und glBegin/glEnd sind so meines Wissens die ersten Schritte eines Anfängers, da sie ja sehr deutliche Ergebnisse mit minimalen Aufwand liefern.

Wenn man allerdings die Tutorialsstrecke ein bischen vorraus plant und z.B. ein kleines Framework baut, was zum anfang die ganze Fenster und OpenGL initialisierung abnimmt, dammit er sich z.B. erstmal auf ein VBO stürzen darf, dann sollte es gehen.
Ich stelle mir das so vor.
Da es schon eine Tutorialstrecke zu OpenGL1-2 gibt, kann man mal in den Startuptuts gucken, die Codeblöcke so ins Framework übernehmen, dass man in den tutorials funktionsweise sich in die Themen arbeiten kann. Wenn es also darum geht ein OpenGL Kontext zu erstellen man dem User durch das Framework zieht und ihn dann z.B. Schritt für Schritt CreateOpenGL3Context() oder GenerateOpenGL3SupportedWindow() durchkaut. So kann man erstmal die Einführung von Kontext und Fenster vieleicht ein Stück nach hinten stellen und dem User erstmal ein Visuelles Erfolgserlebnis mit VBO geben.
Wenn er sich erstmal durch trockenen Stoff arbeiten muss um dann erst 1-2 Tuts später das erste Erfolgserlebnis zu haben ist sehr entmutigend und ich denke auch wenig Sinnvoll.
Aus meiner Sicht will der Neuling ja erstmal reinschnuppern und sehen ob es das richtige für ihn ist und 200Zeilen Code für Fenster und Kontext runter zu schreiben ist nicht der Alltag, die meiste Zeit verbringt man mit Visuellen Feedback basierten OpenGL Funktionen.

1.Kleine Vorschau auf OpenGL(VBO Beispiel,Vertice,Farben)
2.initialisierung von OpenGL(OpenGL Kontext,Renderloop,OpenGL Objekte)
3.irgendwas einfaches, was wie das erste tut einfach auflockert und in kurzen schritten machbar ist
4.die Welt in OpenGL(Pipeline,die einzelnen Matrizen anreissen)
5.siehe 3.
6.Mathematik: Nachsitzen(Matrizen,Vertice,Normals)
7. ...

Also was einfaches, was komplexeres, was einfaches, was komplexeres und das Framework macht das entwickeln der Tuts leichter und ist die Stütze für den Anfänger.

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

Projekte: https://github.com/tak2004

In einem der ersten Tutorials wurde es auch gesagt. Das tolle an OpenGL ist/war, dass man sehr schnell zu einem visuellen Ergebniss kommt. Bei DirectX scheint das anders zu sein (ich habe DirectX nie ausprobiert).
Deshalb denke ich, dass wir irgendwie etwas Schaffen sollten, womit auch ziehmlichen neulingen die Möglichkeit von schnellen Ergebnissen gegeben ist. Dabei sollte man eventuell in dem ersten Tutorial einige Delphifeatures wie z.B. Konstante Arrays und deren Initialisierung erläutern, weil die wohl die einzige einfache Möglichkeit sind, VBOs zu nutzen (oder sehe ich das falsch?).

Ansonsten finde ich TAKs Idee für einen schnellen und leichten Einstieg mit dann mit einem "Sinusartigen" wechsel der schwierigkeiten gut.

Wenn alle Tutorials neu geschrieben werden müssen... Ich wäre gerne dabei, ein bisschen zu helfen, aber leider habe ich im Moment kein Budget für eine OpenGL 3.0 Grafikkarte (gibts sowas überhaupt schon? Braucht man die überhaupt oder reicht eine, die nur die Extensions anbietet, mit denen man sich theoretisch nen OpenGL 3 zusammenbauen könnte?)

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

Die Tutorials die da sind, sind ja gut. Die würde ich so belassen. Ein Framework sollte ursprünglich ja easySDL sein. Wenn man da OpenGL3 als alternative Initialisierung einbauen kann kommt man da bestimmt schonmal ein Stück weiter.

Ich würde sagen, dass der Quickstart um ein Kapitel "Das OpenGL 123" erweitert wird. Dort wird erklärt, was die Unterschiede sind und wo man anfangen sollte (je nach Vorwissen/Einsatzzweck). Von dort aus teilt sich dann der Weg zur Initialisierung auf. Beim OpenGL3er Einstieg sollte dann mit erklärt werden, wie man die bestehenden Tutorials/Codes auf GL3 portiert. Auf die Art bleiben die bisherigen Tutorials bestehen. Dieses Vorgehen würde auch rechtfertigen, dass OpenGL3 eher was für Fortgeschrittene ist.

In einem zweiten OpenGL3 Tutorial sollte dann konkret die Portierung anhand von Beispielen erklärt werden. Man kann auch alles zu diesem Thema in einem Tutorial konzentrieren und macht das OpenGL3 Einstiegstut mehr zur Spielwiese.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Also wenn ich das in der Spezifikation so richtig gesehen habe ist in dem "Deprecation Model" reichlich der fixed-function rausgeflogen. Ich bin mir aber absolut nicht sicher ob ich die Spezifikation richtig interpretiert habe. Aber dann sind auch rotate, scale, ortho, push-, pop-, loadmatrix nicht mehr gültig. Bzw. ein Satz sagt, dass man einen VertexShader benötigt um primitive auszugeben. (Wobei oc2k1 ja gesagt hatte, dass das etwas entschärft wurde.)

Also da würde ich schon sagen, dass der Einsatz unbedingt nur was für Fortgeschrittene ist. Zu mal die Features von 3.0 im Vergleich zu 2.1 auch viel die GF8 Erweiterungen betreffen. Das wird wenn überhaupt nur für wenige Leute wirklich interessant sein. Zu mal man auch bedenken sollte, dass diese Features nicht auf jeder Grafikkarte technisch realisierbar sind. Und ein OpenGL 3.0 Kontext nur dann erstellt werden kann (ohne emulation), wenn diese Features aber unterstützt werden. Also kann man damit Anwendungen schreiben die nur auf wirklich hochgezüchteten Spiele PCs erst lauffähig sind. Das wegen Features die man gar nicht nutzt. Notbookbesitzer werden sich bedanken.

Ich kann mir im übrigen auch gut vorstellen, dass die beiden großen Hersteller die Erweiterungen inklusive 3.0 Core auch in den klassischen Kontext einbauen werden. Zu mindest NVidia dürfte es da sehr leicht haben, da die das ja überwiegend schon alles hatten. Nur eben als eigene Erweiterungen und nicht als ARB Varianten.

Was Tutorials etc angeht würde ich die schon vom Schwierigkeitsgrad her an das anpassen was man auch beim Programmieren leisten muss. Also mit anderen Worten. Wenn derjenige nicht weiß was ein konstanten Array ist und wie man es erstellt, dann sollte er vermutlich zu diesem Zeitpunkt auch kein OpenGL 3.0 benutzen. Denn ich kann mir gut vorstellen, dass ein Großteil damit überfordert sein wird. Da zähle ich mich aktuell so auch drunter, da ich einfach noch nie was mit shadern gemacht habe und die dann ja laut Spec fundamental sind. Allerdings habe ich die Grundlagen und damit ist es bei mir nur eine Fleißübung.

Im übrigen sind die Buffer Objects zu sehr viel mehr im Stande. Zum Beispiel streaming von Vertex-, Texturdaten etc. Besonders wenn es dynamisch wird sollte man aufpassen was man macht um die Asynchronität der beiden PUs nutzen zu können.

PS: Was VBOs angeht habe ich evtl. in ein paar Tagen auch noch einen Ansatz von etwas anzubieten.

Bei PlayStation3 ist es z.B. standard, dass man zu seinem Quellcode einen basic Shader mitliefert.
Okey, nun werden hier wohl eher die wenigsten für PlayStation 3 programmieren aber der Trend geht dahin, alles zu vereinfachen.
Wenn ich mich recht entsinne haben wir darüber auch schon geredet, dass man für das normale durchlaufen lasssen halt den 3 Zeiler Shadercode braucht, der die Transformation macht und ein 3 Zeilen Shadercode, der die Farbe oder Texturfarbe übernimmt.
Das kann man wie die generierten Files aus VS C++/C# oder Delphi sehen.
Sie sind da und wenn man mal was spezielles will, weil man einfach schon weiter ist, dann beschäftigt man sich damit.
In OpenGL 2.x laufen auch nur solche Basis Shader durch, nur dass sie halt im Treiber liegen und nicht in oder bei der Binary.


Man muss das ganze so sehen, die Zeit von dem Plan zur Entwicklung ist schon etwas länger als ein paar wochen.
Die meisten verbringen Monate mit ihren Projekten und in diesen Monaten etabliert sich Hardware recht schnell.
*scherzhaft* Finger hoch wer noch ne GF5 und schlechter hat und nun Finger hoch wieviele es noch vor 1Jahr waren. xD
Man rüstet einfach auf, weil es notwendig ist, oft Vorteile bringt und auch mit der Zeit einfach günstig wird.
FBO's sind wesentlich handlicher als mit mehreren Renderpasses und verschiedenen blendings, Tricks gleiches zu erreichen.
Als Entwickler ist es mir wichtig, eine Gute Software zu liefern und darin ist bei mir nicht enthalten, dass es veraltete Hardware kann sondern Stabiler bugfreier Code. Zugegeben ist es kein Schwarz/Weiß sondern eher eine verschwommende Grenze zwischen veraltet und neuer Hardware aber OpenGL 2.x fähige Hardware sollte heut wirklich erwarten können und in 1 Jahr ist es halt OpenGL 3.x und weil wir schlaue Entwickler sind arbeiten wir mit dem Mitteln, die zum Release Standard sind und nicht zum Entwicklungsbeginn. Von daher zieht die Aussage bei mir nicht.

Ich glaube, dass viele die "Objekt" basierte programmierung in OpenGL 3.x mal ein bischen unterschätzen.
OOP ist übersichtlicher, leichter zu schreiben und einfacher zu warten als Prozedurale Programmierung.
In OpenGL2.x musste man seine Attribute wie Farbe, TexturID und co in eigene Klassen packen und noch zusätzlich verwalten und mit OpenGL3.x fällt dies z.B. weg. Zugegeben habe ich es nicht erwartet gehabt aber in OpenGL3.x gibt es nun Objekte, die mehere VBO's, und Attribute halten können und somit die Arbeit auf den Treibercode auslagert. Man selber hat nur noch seine Liste mit OpenGL ArrayObjects und kann diese bequem verwenden.
Das ist, so wie ich das bisher gelesen habe, quasi die Objekt umsetzung der Displaylisten.

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

Projekte: https://github.com/tak2004

Es kommt einzig und allein darauf an was man macht. Wenn man so wie du in erster Linie nur an Spiele interessiert ist, dann ist es klar, dass man das einsetzt was zum Release eine entsprechende Verbreitung hat. Allerdings bei normalen Anwendungen die lediglich OpenGL benutzen ist das vermutlich nicht so gut. Und ich sehe das aus diesem Blickwinkel. Unter anderem wird die Verbreitung von Laptops auch immer größer. Die können nicht mal eben einen neuen Chip auflöten. Allerdings in Sacred 2 wurden speziell auch solche System bedacht. Dort werden halt einzelne Effekte deaktiviert und es sieht trotzdem noch gut aus. Nicht state of the art aber gut und es läuft vernünftig. Aber das ist eine politische Entscheidung und es kommt darauf an wofür es gedacht ist.

Auch wahr ^^

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

Projekte: https://github.com/tak2004